Bug GamePads ou autre chose?


#1

Je suis tombé sur un os aujourd’hui. J’ai mis du temps avant de comprendre et de reproduire sur une nouvelle scène ce comportement étrange avec l’extension GamePads. Le code 1 est une reproduction du code qui ne fonctionne pas lorsqu’on appuie sur le bouton du gamepad. Les codes 2 et 3 des variants qui fonctionnent normalement.

Code 1: Si on passe la souris sur l’objet text DialogueOk, l’objet text DialogueOk se cache bien. Si on appuie sur le bouton B du pad il ne se passe rien. Pour être plus exact, si on ajoute plusieurs actions, toutes les actions s’exécutent normalement sauf l’action de cacher l’objet text DialogueOk. Par exemple si on demande de cacher un groupe d’objets dans lequel figure l’objet text DialogueOk tous les objets seront cachés sauf DialogueOk.

Code 2: Comportement normal. Si on passe la souris sur l’objet text DialogueOk, l’objet text DialogueOk se cache. Si on appuie sur le bouton B du pad l’objet text DialogueOk se cache.

Code 3: Comportement normal. Si on passe la souris sur l’objet text DialogueOk2, l’objet text DialogueOk se cache. Si on appuie sur le bouton B du pad l’objet text DialogueOk se cache.


#2

Essaie sans la condition OR. :slight_smile:


#3

C’est ce que j’ai fais en utilisant la solution 2 et en séparant complètement les inputs GamePads.
Mais c’est bien un bug on est d’accord ? Ou un truc m’échappe ?
Je n’ai pas vu le code du moteur mais je ne vois pas pourquoi la 2 et la 3 fonctionnent et pas la 1. Dans la 3 il y a bien la condition OR et ça fonctionne.


#4

C’est une spécificité du OR, mais oui, je trouve ça contre-intuitif aussi, et je me suis arraché les cheveux dessus. :sweat_smile:


#5

C’est surtout un soucis de sélection des instances de l’objet j’imagine.
Les conditions lorsqu’elle contiennent un objet et que la condition est vraie alors toutes les instances de l’objet seront utilisé dans les actions.

Ici avec le cas n°1, le OR fait bien sont rôle mais à un effet de bord sur les actions.

Il vérifie si la condition de la souris est sur un objet, c’est non donc il n’inclut pas d’instance pour les futur actions.
Pour la condition de la touche du gamepad il ne vérifie pas d’objet mais la condition est vraie, donc il ne passe aucune instances aux actions.
Les actions elle s’éxécute correctement.
Tu le vois en mettant par exemple un changement de couleur sur le fond de la scène, le changement de couleur se fait.

Il nous faut donc mettre à disposition des actions les instances de l’objet dialogueOK.
Une action existe pour ça. Pick all instances of
Voici ce que ça donne,

Je suis d’accord ce n’est pas logique du point de vue utilisateur.
@4ian il y aurait pas une amélioration à faire avec le OR ?

Ou j’ai un soucis dans l’extension Gamepad, mais franchement j’ai pas vu de truc spécialement chelou.


#6

Exact.

Si le bouton B du gamepad est pressé et qu’il n’y a aucun object sous la souris, alors les actions sont lancées (condition “bouton B” valide) et l’action “Hide” s’appliquent sur les objets sous la souris, à savoir aucun. (*)

Si le bouton B du gamepad est pressé et qu’il y un object sous la souris, alors les actions sont lancées (les deux conditions sont valides) et l’action “Hide” s’appliquent sur les objets sous la souris.

Si le bouton B du gamepad est PAS pressé et qu’il y un object sous la souris, alors les actions sont lancées (la deuxieme condition est valide) et l’action “Hide” s’appliquent sur les objets sous la souris.

La règle est : dès que vous mentionnez un objet dans une condition, alors cette condition va filtrer cet object pour les prochaines conditions (et actions).

(*) je suis d’accord que ça reste potentiellement suprenant. Mais ça a plus de sens si vous mélangez des conditions dans un “OR” qui s’appliquent tous à des objets. Dans ce cas, il faut que les objets soit filtrés, sinon vous risque de vous retrouver a appliquer des actions à TOUT les objets de la scène, alors que c’est juste que la condition était fausse… pas top ! :slight_smile:

Exemple:

Condition OR #1: Cursor is on RedObject
Condition OR #2: Cursor is on BlueObject
Action 1: Delete RedObject
Action 2: Delete BlueObject

Tant que la souris est sur un objet rouge et un objet bleu, tout est logique : les deux sont effacés. Tout va bien.
Maintenant, imaginez que la souris est sur un objet rouge uniquement (donc la première condition est valide, mais la deuxième est fausse). Grace au “OR”, les actions sont lancées (tout va bien). L’action 1 est lancée, l’objet rouge qui est sous la souris est supprimée (tout va bien).
L’action 2 est lancée et la BAM, tous les objets bleus de la scène sont supprimés !! => ça serait contre intuitif. Plus que l’histoire du gamepad. Car ça voudrait dire que GDevelop a vu que la condition est fausse et donc s’est dit “bon du coup les objets bleus leur condition était fausse, bah tant pis je vais appliquer les actions sur tous !”.

Après, il y a peut etre moyen d’expliquer ça plus en détail directement dans la description de la condition “OR” ?


#7

Ok, j’y vois plus clair maintenant.

Si je résume, on manipule des objets dans l’interface graphique et GDevelop choisi automatiquement quelles instances seront manipulées dans les actions avec une règle de base simple : “si on mentionne un objet dans une condition, alors cette condition va filtrer cet objet pour les prochaines conditions et actions”. Tant qu’il y a des conditions simples la règle fonctionne bien et en effet après avoir lu le wiki “concepts de base” sur la partie évènements, j’ai pas eu souvent à me poser la question des instances. Depuis des mois d’utilisation GDevelop se comporte comme je pensais qu’il le ferait. Soit il prend les instances vérifiant la condition soit il prend toutes les instances. Il en découle un gain de temps énorme et une grande facilité d’utilisation et c’est exactement pour ce genre de truc qu’on utilise GDevelop.

Par contre quelques conditions ou usages ambiguës posent problème. En gros tous les usages ou les conditions ne sont assez explicites ou documentées et ou le résultat dépend de la construction interne du moteur de GDevelop.

Par exemple pour la condition “OR”, je comprends le pourquoi de l’exemple précédent ou tous les objets bleus de la scène sont supprimés.
Mais les voir tous supprimés ne m’aurait pas choqué plus que çà. Si la condition OR#1 est vrai et OR#2 faux, la souris est sur un objet rouge mais pas sur un bleu, j’aurais très bien pu imaginer que GDevelop exécute les actions de la condition “OR” comme si la condition OR#1 était seule, c’est à dire comme si on avait l’évènement suivant :
Condition OR#1: Cursor is on RedObject
Action 1: Delete RedObject
Action 2: Delete BlueObject

C’est ce que je pensais avec mon cas 1 et le GamePad.
A ce que j’ai compris de votre réponse, GDevelop est fait pour éviter au maximum d’exécuter des actions sur tous les objets, ce qui est logique. Mais du coup si on en dit pas plus sur comment GDevelop va traiter les instances, on a parfois des surprises comme ici avec le OR et ce n’est pas la seule fonction dans ce cas. Parfois il faut tester le code avant d’être certain de ce qui va se passer.
Si je prends le même exemple mais avec la fonction invert condition avec laquelle j’ai luté aussi, avant de tester je ne savais pas ce que GDevelop allait faire dans ces 2 cas : (instances prises ensemble ou une par une pour l’invertion ?)

Cas 1: (Pas de OR, juste 2 conditions dans l’évènement)
Condition #1: Invert condition + Cursor is on RedObject
Condition #2: Cursor is on BlueObject
Action 1: Delete RedObject
Action 2: Delete BlueObject

Cas 2 sans 2ème condition:
Condition #1: Invert condition + Cursor is not on RedObject
Action 1: Delete RedObject
Action 2: Delete BlueObject

Je comprends mieux aussi une fois quand j’avais un OR avec 4 invert-condition à l’intérieur. Je me demandais pourquoi ca ne fonctionnait pas comme je le voulais. Je m’étais dit qu’il valait mieux simplifier tout ça et faire quelques copié-collé plutôt à la place. Tu m’étonne, encore une chance que j’ai pas insisté :joy:

Donc une simple description plus complète sur le traitement des instances pour certaines conditions comme le OR ou invert-condition serait top :slight_smile:
Un peu comme vous avez expliquez comment utiliser les forces instantanées ou permanentes avec le trigger once. Du coup dans mon exemple 1 avec le gamePad je saurai plus vite qu’il faut que j’ajoute le “Pick all instances” et hop plus de problème.