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é 
Donc une simple description plus complète sur le traitement des instances pour certaines conditions comme le OR ou invert-condition serait top 
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.
