comportements

hello

sur le forum clickteam je discute avec une personne s'etonnant que dans le mfa foint, les comportements de chaque "actif" soit identiques alors que leur code est présent dans "comportement"

effectivement si le fait de mettre le code dans "comportement" permet de differencier les actifs un peu comme grace a une boucle, je comprends mieux l'interet des comportements , ce que je n'avais jamais saisi jusqu'ici!!

cela dit il reste une énigme, pour moi le mfa se comporte normalement mais pas pour lui car dans comportements il y a une condition :

si posy actif > 500 : désactive groupe principal (et le dèplacement en y est géré dans le groupe principal) , pour lui seul l'actif arrivant a y=500 devrait etre affecté et les autres devraient continuer de descendre puisque leur groupe principal ne devrait pas etre desactivé

pour moi comme il n'y a qu'un seul code, le fait de le desactiver suite a une condition vraie sur un des actifs impacte le code en lui meme donc tout les actifs (cela dit si ce qu'il affirme est possible ce serait génial!)

quelqu'un peut m'éclairer svp?

https://drop.infini.fr/r/fTw0zvbdbm#P3s2JP6jLhbzMK9BEEdoNpBrmfs2ReacP6nzqpN6LoE=

Je pense que cela vient d'une mécompréhension de la notion de groupe/ensemble dans Fusion. Le groupe, qu'il soit déterminé par un groupe d'évènements ou un qualifieur, vise tout ce qui se rapporte au-dit groupe, où que ce soit dans le reste du programme. Alors que seuls les objets mentionnés dans les conditions d'évènements seront les seuls affectés s'ils répondent aux conditions. A mon sens, le programme est juste bizarrement conçu, avec une gestion inutile du groupe d'évènements. Je me suis permis de refaire le programme à ma façon pour obtenir le résultat attendu. Illico, j'ai viré le groupe d'évènements, changé la condition, et rendu inactif le changement de la valeur modifiable A à zéro (vu que ça ne sert absolument à rien). La seule ligne dorénavant utile dans l'éditeur de comportements de l'actif pourrait d'ailleurs être basculée dans l'éditeur d'évènement principal, pour plus de lisibilité, ce qui ferait juste deux lignes pour ce programme :
- début de scène : valeur aléatoire de A d'Actif
- si Y d'Actif < 400, fixer position Y à Y + val A d'Actif
J'ai du mal à comprendre où est le soucis, d'ailleurs, car c'est à mon avis d'un niveau ultra basique en fait.

http://www.yazorius.com/forsiggits.mfa (modifié dans comportement d'Actif)
http://www.yazorius.com/forsiggits2.mfa (sans comportement d'Actif, au plus simple, donc)

Bien souvent, lorsque Fusion ne se comporte pas comme on l'attend, c'est juste qu'on n'a pas compris l'utilisation précise d'une fonction.

Je me permets aussi de revenir sur un détail : non, le code écrit dans le comportement d'un objet de permet pas de distinguer un objet précis parmi plusieurs copies. Il sert juste à river un code dans un objet, et donc de pouvoir copier l'objet en intégralité (sprites, qualifieurs et comportements dédiés) pour le coller dans une autre scène/application sans avoir à réécrire le code qui le concerne. J'ai du coup fait une autre version du programme, avec l'ajout de trois Actif2 superposés à chaque Actif dont je teste la condition de position dans le comportement d'Actif, afin de détruire Actif depuis le comportement (sans pour autant le mentionner dans les conditions) : tous les Actifs sont alors détruits sans distinction, preuve que ce qui les différenciait venait bien de la mention dans les conditions d'évènements, et non via le code écrit dans le comportement plutôt que dans le corps principal du programme.

http://www.yazorius.com/forsiggits3.mfa (test de position via Actif2 dans le comportement d'Actif)

merci! tu confirmes bien ce que je pensais sur le fait que le code dans le comportement ne distingue pas les actifs concernés

effectivement il est tres simple de modifier ce petit programme mais pour cette personne l'interet etait (je ne sais pour quelle raison) de pouvoir inhiber le code entier d'un actif et d'un seul, en utilisant les comportements et un groupe...