Euh j’ai la nouvelle version de gd et c’est bête comme question mais je n’ai pas trouvé ou l’on peut changer le type d’évènement: ET/OU
Merci d’avance 
On ne peut plus mettre de “OU”, il y avait des erreurs potentielles au niveau de la sélection des objets. Les jeux qui utilisent des évènements en “OU” sont toujours fonctionnels, même si il faut songer à passer à autre chose.
Ben 
C’est nul alors 
Pourquoi ne pas le laisser 
C’est très utile 
Ou au moins le laisser en extension 
Mais il faut le laisser:
Sinon c’est plus du langage de programmation quoi
Quand tu code toi y a toujours "et"et “ou”
Bien ou pas si il y avait un bug ça ce corrige mais moi j’en ai besoin:
J’ai par exemple des endroits dans mon jeu ou si la variable machin est a ça ou ça ou ça ou ça (17fois pas exemple ça arrive)
Je ne veut pas faire 17 évènements qui disent la même chose 
“Ou” c’est très comme condition
Et je le dit franchement il faut le laisser 
Si tu as un évènement avec plein de ou, tu as très vraisemblablement besoin de passer tous les objets dans un groupe.
Non seulement c’est sémantiquement mieux, car ça t’oblige à donner un nom au groupe qui caractérise l’utilité de ces objets, et en plus tu réduit la longueur de l’évènement.
Tu peux aussi utiliser une variable intermédiaire pour avoir un seul évènement qui exécutera les actions. Là aussi, choisir un bon nom de variable permettra de rendre tes évènements plus clair en montrant l’utilité de l’évènement.
Si tu ne peux pas faire ça, tu peux toujours séparer l’évènement en plusieurs.
Oui mais non :
Et crois moi, je préfère dix fois enlever maintenant cette fonctionnalité mal programmée, quitte à embêter un peu, que de me retrouver avec plein de posts plus tard comme quoi la sélection d’objet avec la condition OU est mal foutue, alors que c’est un truc de base, que c’est un scandale, que c’est horrible, et que corriger ça rendrait les anciens jeux incompatibles.
J prévois pour l’avenir un système de sous conditions qui permettrait la création de ET/OU à l’intérieur des conditions. Ce sera alors mieux pensé et encore plus flexible que les OU actuels qui s’appliquent à toutes les conditions.
Tu peux toujours l’utiliser en copiant-collant un évènement qui utilise des “OU”. Mais je ne te le recommande pas du tout. Si je l’ai enlevé, c’est pour que ce ne soit plus utilisé, et pour qu’il n’y ait pas de problème le jour où cette fonction ne marchera réellement plus du tout, et qu’elle sera remplacée par autre chose.
oula … la un bon point du gamd develop est partie !
Je vois mal comment remplacer certain truc maintenant …
si tu veux mettre perdu si le temps est à 0, si il y a une collision avec mur ou si le zoom est > à 2 tu fait comment ?
Tu relis ça :
Et tu peux donc faire par exemple :
si le temps est à 0 → Faire =1 à la variable “Phase2”
si il y a une collision avec mur → Faire =1 à la variable “Phase2”
si le zoom est > à 2 → Faire =1 à la variable “Phase2”
Si la variable “Phase2” est = à 1 → Faire tes actions
ceci vas être plus dur a programme aussi
il faudra pense a faire justement c’est variable a la place de OU/ET
pour ceux qui on du mal avec les variables, il font être servi 
sinon je tir mon chapeau car je connait un autre logiciel concurrent qui lui est payant et ne propose pas le quart de ce que game develop propose
Bravo et bonne continuation
J’ai toujours eu des difficultés avec les “ou”, il y avait sûrement quelque chose qui n’allait pas.
Pour les test de variables on peut se débouiller :
par exemple au lieu de mettre si x=2 ou x=3 ou x=5 on peut mettre
si (x-2)(x-3)(x-5)=0 
Il y n’a pas non plus forcément besoin de variable si on utilise des groupes quand il s’agit d’objets par exemple.
Personnellement, j’ai très peu utilisé les OU dans les quelques jeux que j’ai fait, voir pas du tout, je ne pense pas que ce soit si handicapant. Par contre, le fait qu’il y ait des erreurs au niveau de la sélection des objets lors de l’utilisation des OU aurait fini par être handicapant pour le logiciel.
Ben les groupes j’en ai 5 par scènes
Moi je n’utilise pas ça pour les groupe mais pour la valeur d’une variable
Mais par contre si pour la prochaine version l’on pouvais intégrer ça directement dans les conditions ce serait bien
PS:Ne croyez pas que je fait tous et n’importe quoi j’ai bien compris l’utilité des groupes et ça fait des mois que je les utilises mais la j’ai vraiment besoin de et et ou:
[attachment=0]etou.png[/attachment]
j’avais pas assez de place pour tout prendre mais j’ai cette image la X2 pour une seule capacité et je l’ai encore X17 vu qu’il y a 17 capacités
Ce ne serais pas trop cool a faire en evenements de “et”.
Voila j’espère que vous avez compris pourquoi j’en ai vraiment besoin
Tu peux aussi remplacer A ou B par non(non A et non B)
On peut activer le contraire d’une condition, mais pas d’un évènement entier, ce n’est donc pas faisable.
On ne pourrait pas faire
1er événement : si non A et non B alors x=1
2e événement : si x!=1 alors …
Si, c’est juste qu’on repasse par une variable intermédiaire.
Je suis un peu abasourdi, comme mes camarades. 
Je veux bien croire qu’il y ait des problèmes avec la fonction “ou”… Néanmoins, c’est frustrant de la voir disparaître. On va être obligé de multiplier les événements, si l’on doit réécrire les événements pour chaque cas de figure… (et il faudra sans doute aussi ajouter plus de commentaires pour noter les événements qui sont complémentaires, si l’on veut s’y retrouver). L’exemple de Crone illustre tout à fait cela ; quand on regarde ses événements, on comprend tout de suite comment ils fonctionnent : on voit que l’attaque d’un monstre de type Eau2 est plus ou moins efficace suivant le type de son adversaire. En revanche, si Crone est désormais obligé de décomposer ses sous-événements en 17 petits morceaux, visuellement ce sera moins clair pour le programmeur.
Toi 4ian, comme tu le dis, tu te sers très peu des conditions en “ou”, tu n’en perçois peut-être pas tout l’intérêt. Mais moi, comme Crone, je travaille sur des jeux de stratégie au concept plutôt élaboré, et il y a souvent des situations qui conduisent au même résultat (par exemple, il peut y avoir plusieurs conditions de victoire ou de défaite, dont une seule a besoin d’être validée pour déclarer la victoire ou la défaite).
Et puis surtout, Game Develop va perdre en intuitivité. Je pense qu’il faudra inscrire une note dans l’aide à ce sujet, en particulier à l’attention des programmeurs : pour une personne qui a des habitudes en programmation, et qui découvre Game Develop, ça va sans doute lui faire un choc de s’apercevoir qu’il n’y a pas moyen d’utiliser “ou” dans les conditions, et qu’il faut écrire les différentes alternatives dans des événements séparés. Nous, on connait le logiciel, et ça nous choque déjà… Ce que je veux dire, c’est que la dualité ET/OU est l’un des plus rudimentaires fondements de la logique. Et ça n’exite plus dans Game Develop… Après ça, va demander aux gens de faire preuve d’esprit logique dans la création de leur jeu ; il faut déjà leur expliquer que la logique de fonctionnement de Game Develop ne relève pas de l’exercice de la logique la plus orthodoxe…
Car c’est là qu’on s’aperçoit de plus en plus que Game Develop est un logiciel qui a une logique qui lui est bien spécifique. Par exemple, en langage C, quand on écrit une fonction, elle exécute l’action une seule fois (sauf si on crée une boucle avec un système d’incrémentation pour lui faire répéter l’action plusieurs fois). En revanche, dans Game Develop, si on écrit simplement une action sans préciser de condition (par exemple “créer un objet”), le logiciel “comprend” qu’il faut créer cet objet indéfiniment (ce n’est pas forcément évident ni spontanément logique au premier abord). Moi, au début, j’avais eu du mal à intégrer cela : je perdais beaucoup de temps à me débattre avec cette logique étrange pour éviter d’avoir des infinités d’objets ou des variables malaisées à faire varier. Ensuite, on a une condition “toujours” qui ne sert à rien, et dont l’inverse n’a aucun sens. Aussi, on a parfois bien du mal à savoir comment distinguer une “variable de la scène” et une “variable globale” ; et en parlant de “variable globale”, je me demande quel sens cela peut bien avoir de “forcer en global” une “variable globale”… Il y a encore plusieurs exemples d’étrangetés du même genre que j’ai remarquées, et qui ne me reviennent pas en tête sur l’instant. Et maintenant, donc, on perd l’usage de la fonction “ou”…
Naturellement, je t’en parle sans animosité, 4ian ; si tu penses que supprimer les conditions de structure en “ou” est préférable, tu as certainement tes raisons, et je suis disposé à croire qu’elles sont très fondées. C’est simplement pour dire que Game Develop n’est pas toujours facile à prendre en main. Et ce n’est pas nécessairement le manque d’esprit logique de l’utilisateur qui pèche. Il faut savoir s’habituer à la logique particulière du logiciel. Il m’est souvent arrivé de rester bloqué un long moment pour parvenir à faire réaliser au logiciel une fonction en apparence toute bête (je travaille généralement sur des projets de jeu dans lesquels les actions sont ponctuelles et ne se répètent pas, ou alors sur des événements qui doivent se succéder dans un ordre précis mais dont l’exécution ne doit pas dépendre d’un chronomètre).
C’est pourquoi, je suggère que, pour la prochaine version, plutôt que de songer à intégrer plusieurs nouvelles fonctionnalités, il serait peut-être judicieux d’étoffer un peu plus les fichiers d’aide, et d’ajouter quelques autres mini-jeux d’exemples, qui aident généralement bien à la compréhension : il y a sans doute plusieurs concepts qui mériteraient d’être décrits plus en détail.
Voilà ; c’était encore une grosse contribution de ma part, et encore un long texte. Et c’est aussi vraisemblablement le dernier avant un moment : je vous avais prévenu que j’allais déménager, la date est maintenant très proche, et je ne vais plus pouvoir venir sur le forum pendant plusieurs semaines certainement. Au revoir à tous, à plus tard.
J’espère que tu ne resteras pas absent trop longtemps Voyageur, tes textes détaillés et bien argumentés nous manqueront.
Je n’ai sans doute pas tout à fait compris la logique de GD mais il me semble que lorsque le programme arrive à la fin, il reprend au début. A part les actions protégées par “au lancement de la scène”, nous sommes dans une boucle infinie.
Quant aux “ou” je ne les utilisais pas non plus car je ne comprenais pas comment ils fonctionnaient.
Ben c’est simple:
Plutot que de faire:
4evenement “et”:
-Ma varible tatata = machin faire truc
-Ma varible tatata = chose faire truc
-Ma varible tatata = quoi? faire truc
-Ma varible tatata = cornichon faire truc
Si fait un évènement “ou”:
-Ma varible tatata = machin
ou
-Ma varible tatata = chose
ou
-Ma varible tatata = quoi?
ou
-Ma varible tatata = cornichon
Faire truc
c’est un switch en php en fait
Ce que je veux dire c’est que dans la plupart des langages de programmation, on évalue les deux conditions, puis si le ou est inclusif on applique la règle :
vrai ou vrai = vrai
vrai ou faux = vrai
faux ou vrai = vrai
faux ou faux = faux.
Or d’après les différents essais que j’ai pu faire il semblerait que GD ne procède pas de cette façon, mais plutôt :
il évalue la 1ère condition, si elle a la valeur vrai, l’action est exécutée.
Si elle est fausse il évalue la seconde et
- si elle est vraie, il exécute l’action
- si elle est fausse, il ne l’exécute pas.
Mais je me trompe peut-être… C’est pour cela que je dis “je ne comprends pas comment ça fonctionne.”
4ian nous renseignera peut-être.
Mais pour résoudre ton problème, les “ou” ne sont pas nécessaires. Une condition du genre “la variable tatata a-t-elle l’une de ces valeurs” : (machin; truc; chose; cornichon) suffirait et poserait moins de problèmes je crois.
Ca ma l’ar d’une série de IF et de Else.
Je m’explique :
Les conditions sont commandées par des IF (donnant en exemple : SI objet A et objet B sont en collisions).
et bien cela agit comme ca :
condition 1
vrai :
[list]faire action
faux :condition 2
[list]vrai :
[list]faire action
faux :condition 3
[list]vrai :[list]
faire action
faux :etc…
[/list:u][/list:u][/list:u][/list:u]
[/list:u]