Une condition else serait très pratique.
Exemple:
if La Variable ID de l’objet machin = 2
{
actions
}
elseif(Elle est = a 3)
{
actions
}
else
{
Sinon…
}
ça évite d’exécuter 2 évènements au cas ou l’ID change de 2 a 3.
Et pour le else ça permet de conserver l’objet de qui l’on parle.
Et aussi de re-crée un évènement avec les conditions inverses.
Si je dit:
La variable machin de l’objet machin != 1
ça prends tous les objets.
Ici ça n’en prends qu’un seul, d’ou l’utilité, ça rends les actions locales, et c’est ce qui est difficile a faire actuellement…parce que a moins d’utiliser pleins de boucles et de tests pour la majorité des tests on tombe en global ou bien le test ne correspond pas.
Bref, voila
Merci
Facile…
Faire un style d’évènement “else” disant que si ses sous-évènements sont faux, exécuter l’action de l’évènement “else”
En plus ce serai pratique pour faire des test dans un jeu
Si l’un des sous-évènement de “else” est bon, alors renvoyer la valeur disant que else ne sera pas exécuté…
Si aucun des sous-évènements est vrai, dire d’exécuter else…
Après tu adapte les objets, tu ne les gardes en mémoire seulement si l’évènement auquel il appartient est bon
(après je n’ai peut-être pas compris tes questions )
Oui, mais attention parce que le but 1er de else est justement de garder les objets concernés, donc de ne pas avoir a faire des tests impossibles
Donc, faut bien intégrer ça correctement
Je sais très bien comment créer un évènement du type “If/Else”, il faudrait juste un évènement avec des actions supplémentaires correspondantes au “else”. Le problème est ça :
Prenons un exemple :
Si je vous dis :
Conditions : La souris est sur BoutonQuitter
Actions : Faire =1 à l'animation de BoutonQuitter
Sinon :
Actions :Faire =0 à l'animation de BoutonQuitter
Vous aller me dire : Facile, il suffit de tester la condition, si elle est vraie on exécute l’action, sinon on fait l’autre. Très bien, imaginons.
Maintenant si je vous dis :
Conditions : L'objet Méchant a sa variable Alerte = à 1.
Actions : Faire =1 à sa variable Bouger
Sinon :
Actions : Faire =0 à sa variable Bouger
Imaginons qu’il y ait 3 méchants, dont 2 avec la variable Alerte à 1.
La condition est vraie n’est ce pas ? Dans ce cas, il n’y a aucune raison d’exécuter les actions écrites après sinon n’est ce pas ?
Pourtant, je suis sur que ce que vous pensiez, c’est que les objets méchants qui ne remplisse pas la condition aurait leur variable 0 mise à 1.
Ici, pour que ça marche, il faudra que la condition soit fausse, c’est à dire que AUCUN méchant n’ait sa variable à Alerte à 1.
( Au passage Dayvid, tu t’es rendu compte que tu viens de répéter inutilement ce que Crone123 a déjà écrit et que tout le monde a déjà en tête ? Et les ET/OU qui permettent de relier logiquement des conditions n’ont rien à voir avec des if/else qui touchent à la structure d’un programme. )
Mais c’est ça qui est chiant justement.
Devoir créer 2évènement avec 2conditions.
Le truc c’est:
Mon tas de conditions = respectée → Action effectuées
Sinon (else)
->Mon tas d’actions.
J’ai pas a re-faire des tests pour savoir quel objet c’est, si j’ai 20objets, ils font pas tous la même chose, c’est le B-A-BA un else.
Je le sais je répondais au problème posé par 4ian, et je suis d’accord avec toi mais quand bien même c’est pratique de rajouter un évènement comme un else (moi je préfèrerai un switch tant qu’à faire, c’est plus facilement modulable que if else), peut être que l’incorporer au logiciel n’est pas aussi simple.
Dans le cas de ton if else, comme je viens de le dire, selon moi un switch est mieux :
Combien de switch voulez vous : “On Entre le nombre de switch”
“paf” ça nous mets tout les switch qu’on à plus qu’a paramétrer, et le default (si on met 1 switch et le default, ça revient à faire if else, mais si il doit y avoir if elseif elseif elseif elseif elseif else, je pense qu’un switch est mieux )
C’est pour ça que je parle d’identifiant unique, ça demanderai plus de travail quand on parle d’un objet car du coup c’est un peu comme si on travaillai en permanence avec un “pour chaque objet” sauf que on pourrait aussi faire “pour cet objet précis” → par exemple on crée plusieurs PNJ mais chacun à des actions paramétrée à l’avance et pas en fonction de variables.
Se sont encore une fois des choses réalisable actuellement via les évènements mais d’une façon trop complexe pour quelque chose qui se retrouve utilisé fréquemment !
Et à la longue ça use !
En fait il faudrait presque avoir les évènements en double, les évènement “simple”(objets sans id, et actions associés, ce que l’on a actuellement) ET les évènements plus complexe (avec id) permettant des choses compliqué plus rapidement (if else / switch / création de même PNJ mais différents, etc…)
Sinon dans le cas précis du if else, prendre en compte chaque objet indépendamment les uns des autres (comme un pour chaque objet) mais du coup le else s’appliquera à tout les objets
Un cas fréquent:
Si la souris est sur l’objet machin, et que le bouton truc est appuyé:
Si la variable machin est 0 la mettre a 1 et faire mon tas d’actions
Si la variable est a 1 la mettre a 0 et faire mon tas d’actions.
Résultat:
En 1clic j’effectue les 2évènements, et c’est chiant de devoir rajouter une variable ou un chronomètre pour ce genre de détails…
Je sais bien, mais le problème, je l’ai déjà exposé plus haut. Mais j’en reparle juste après justement :
Des identifiants unique ne résolvent pas le problème. Le problème est comment traiter les objets concernés et non concernés par les conditions quand on fait les actions du “else” ?
→ Est ce que je teste toutes les conditions ou est ce que je m’arrête dès qu’il y a une condition de fausse ?
→ Est ce que je garde les objets concernés par les conditions pour les actions du “else” ?
Reprenons mon exemple : ( J’insiste, lisez le, car je pense que ça montre bien le problème, et c’est ça qu’il faut résoudre. )
Si je vous dis :
Conditions : La souris est sur BoutonQuitter
Actions : Faire =1 à l'animation de BoutonQuitter
Sinon :
Actions :Faire =0 à l'animation de BoutonQuitter
Vous aller me dire : Facile, il suffit de tester la condition, si elle est vraie on exécute l’action, sinon on fait l’autre. Ok je note.
Maintenant si je vous dis :
Conditions : L'objet Méchant a sa variable Alerte = à 1.
Actions : Faire =1 à sa variable Bouger
Sinon :
Actions : Faire =0 à sa variable Bouger
Imaginons qu’il y ait 3 méchants, dont 2 avec la variable Alerte à 1.
La condition est vraie n’est ce pas ? Dans ce cas, il n’y a aucune raison d’exécuter les actions écrites après sinon n’est ce pas ?
Pourtant, je suis sur que ce que vous pensiez, c’est que les objets méchants qui ne remplisse pas la condition aurait leur variable 0 mise à 1.
Ici, pour que ça marche, il faudra que la condition soit fausse, c’est à dire que AUCUN méchant n’ait sa variable à Alerte à 1.
Et je vois pas où des identifiants vont aider à résoudre ce problème…
Mon dieu, non. Les évènements doivent pour s’adapter à la complexité que l’on veut.
En programmation, j’ai pas besoin d’un “if/else” simple et d’un “if/else” compliqué. Donc dans Game Develop, on doit avoir le même niveau de simplicité, et on s’en éloigne avec ça.
Ben:
Pour les objets, dans le cas de “Méchant”, tu répète pour chaque “Méchant” (et tu effectue ce qu’il faut…)
Et si on ne veux pas prendre les objets précédemment pris en compte, il faudrait une action/condition (mais qui se place dans les 2…) “ne plus prendre en compte” l’objet “machin”, et c’est bon
Comment Game Develop devine qu’il doit répéter ça pour chaque Méchant et pas pour les autres objets ?
D’ailleurs, je peux rajouter une autre condition qui n’a rien à voir avec les méchant. Il n’y a aucune raison qu’elle soit répétée plusieurs fois pour chaque méchant :
Conditions : La variable Truc est = à Random(10)
L'objet Méchant a sa variable Alerte = à 1.
Actions : Faire =1 à la variable Bouger de Méchant
Sinon :
Actions : Faire =0 à la variable Bouger de Méchant
J’ai même rajouté une expression aléatoire ici. Si on répète les conditions pour chaque méchant, un nombre aléatoire différent va être testé pour chaque. C’est vachement dangereux, le développeur s’attend à ce que la condition soit testé une et une seule fois.
)
ET