Aide à la différenciation des Actifs Dupliqués.

Et surtout il n'y a aucun moyen de savoir dans quel ordre les événements sont exécutés.

Je commence de mieux en mieux à saisir pourquoi tu dis toujours ça Patrice :p

Récemment j'ai même compris que objet X au dessus de objet Y est différent de objet Y au dessus de objet X

Hyper important !!!!

Je ne suis pas vraiment d'accord avec toi Graboide. Si c'est en effet extrêmement fastidieux de copier du code dans plusieurs scènes, ça n'est pas inévitable.
Cela n'est pas inhérent au RPG, c'est le cas de tous les jeux. Cela fait partie du design. La première question qu'un programmeur doit se poser quand on copie du code, c'est si l'on peut factoriser comme tu  l'as dit. Si c'est valable pour le code, c'est valable pour les scènes. Si l'on doit copier beaucoup de code dans plusieurs scènes, c'est qu'il faut qu'une seule scène. Un exemple vraiment représentatif est le jeu open source de Nifflas The Great Work qui est disponible sur le site de clickteam.

Personnellement pour Cardinal, je n'utilise aussi qu'une seule scène pour toutes les zones combats. La seule exception que j'ai faite, c'est pour les sons/musiques puisqu'ils sont présents dans toutes les scènes.

Cela devrait aussi être valable pour un A-RPG.

Quant au comportement, l'idée aurait été bonne si cela avait été la transposition de la programmation orienté objet mais cela donne juste du code perdu difficilement utilisable.

utiliser une seul scène pour un A-rpg reviendrai a créer un éditeur de niveau, la encore fusion est pas doué car les décores coller a partir d'actif ne peuvent pas être en collisions rectangulaire il mange de la ressources et naturellement il mange déjà plus, j'ai vu qu'ils avaient corriger justement ce problème décores coller a partir d'actifs qui font ramer dans un des derniers patch, bon moi c'est trop tard j'avais abandonner mon éditeur a cause de sa, sur android ça rame alors que la meme scene a l'identique directement depuis l’éditeur de fusion et super fluide :/.

Vous aurez beau essayez de me convaincre mais je continue a la dire l'éditeur de scene et pas valable pour un A-rpg ou les ennemis ce retrouvent obligatoirement dans plusieurs scènes, donc on ne peu pas mettre la partie combat sur une scène et le reste sur une autres, le code doit être copier coller sur toutes les scènes quand il y en a trop c'est impossible a géré d'une complexité hallucinante, on est pas les seul a procédé comme ca, sur le fofo anglais certains le font car ils le disent aussi copier coller un code sur toutes les scènes et une horreur, j'ai mêmes vue ca dans les point négatifs de fusion 2.5 dans un test, le TOP serais de pouvair inserer l'editeur d'evenement d'une scene dans une autres scene pour réglé ce probleme ... on peu ?

OUI ! :) creez un actif nommé le événements mettez le en global, inserez tout vos codes dans un comportement de cette actif et hop on a un éditeur avec tout dedans (pour ceux qui aime pas mélanger) et qu'ont peu copier coller dans les scènes voulu, il suffira de changer une ligne dans le comportement de l'actif événements pour que ça ce répercute a toutes les scènes, c'est la ou fusion est magique il y ont pensés ! :) et si ils ont créez les comportement je suis sur que c'est pour évité d'avoir a copier un code partout et le rechanger partout, avec cette methode vous aurez le meilleur des deux tout le code dans un seul endroit (moi j'aime pas) et pouvoir le modifier sur toutes les scène souhaité.
Ca fais des années que je boss sur android et ios, et j'ai jamais u de meilleur résultat que depuis que j'utilise les comportements, ils sont mal aimés mais laissez leur une chance ^^ car c'est incroyablement plus puissant que l’éditeur de scène, et l'editeur globale j'en parle même pas lui je me demande pourquoi il existe.

Optimisation toute bêtes avec les comportements , a l'arc je tir une fleche, le code qui interagi avec la fleche et dans un comportement de cette fleche, ben si pas de flèche pas de codes, si ennemis pas présent dans la scène pas de code, si les buissons sont pas présent pas de code non plus etc ... au final on gagne des lignes sans rien faire, et ça on peu qu'avec les comportements, Ou en fermant des groupe en vérifiant le nombre d'objet ( trop contraignant pour moi) puis ca rajoute des lignes.

Comme dit Pat chacuns sont truc mais je rejoint djipi ;) .

Pas sûr pas sûr...

Ce serait bien d'avoir l'avis de Falco, qui, me semble t'il, est de créer justement un éditeur entier de niveau : "Link Creator".

Joue t'il à un cache-cache facétieux avec son code ou est-ce que tout ce trouve dans l'éditeur d'événement... 

J utilise pas d éditeur de niveau et je peu prouvé ce que je dit , dans une des dernière maj la clickteam elle même le dit qu' il y avait des problèmes de performances avec les decores coller .

J ai essayé des tas de choses ce qui me convient le mieux c est ca et je suis pas le seul .
Si le cache cache vous gêne mettez tous dans un seul actif global vous aurez un code répercuté partout , j ai un actif météo qui gère la.météo mon code météo et dedans dans une maison je le met pas et j ai pas de météo, si j ai besoin de changer un truc je vais pas me prendre la tête à fouille dans toutes les scènes.
Parce que avec 100 groupes dans l éditeur je joue pas à un cache cache ? C est tellement plus simple de clicker sur une icône météo :/.

C est ma méthode et je l aime :P,  et pir je la conseil à qui veut optimiser son jeu et le rendre facile à évoluer, les comportements c est l avenir de fusion et je vais encore plus loin fusion sans les comportements c est comme une pizza sans olives !
J embrasse les comportements et je mettrais jamais une ligne de code dans l.éditeur de scène il.et même inutile ^^.

Plus sérieusement j ai déjà tout expliquer je vais pas me répéter mais dans mon cas personnellement c est la seul solution optimal possible jamais il y aura mieux .
J utilise l éditeur de scène seulement pour les scènes unique car c est vrai c est plus lisible , par exemple l écran titre ou le menu mais c est tout.

Pour les decores pas en collision rectangle à partir d actif qui les colles j avais fais la demande sur la bugbox mais il y a pas u de retour dommage, en plus un éditeur de niveau oblige un tableau ressources encore manger, c est dommage car c est beaucoup plus rapide avec un éditeur !

Mais dans un éditeur de niveau encore une fois quand tu ajoute un ennemi par exemple une fois créer dans fusion à partir du tableau que l.éditeur aura généré , ben c'est vachement mieux de lui mettre un behavior (comportement) si tu en a 1000 tu va créer 1000 groupes ? C est fou on a des fonctions qui permette d optimiser son code ....

Chacuns sa façon de procéder mais faut pas pointer du doigt les.gens différents ;), utilisé les comportements ne fais de.nous des débutants ;), on y vois nos intérêts c est tout

utiliser une seul scène pour un A-rpg reviendrai a créer un éditeur de niveau,

C'est exactement cela. Que Fusion manque d'optimisations au niveau d'Android, qu'ils ont d'ailleurs largement améliorées, je suis d'accord. L'objet Tilemap serait un excellent moyen s'il était disponible sur Android. Plus besoin de copier les scènes.

Que tu ais utilisé les comportements pour contourner un manque d'optimisations et les limitations de Fusion montrent que tu as de l'astuce. Cela ne veut pas dire que c'est une bonne idée de design de la part de Clickteam.

Utiliser un objet pour contenir tout ton code revient à faire un éditeur d'événement puisque le code est copié à la fin de l'éditeur d'événement. Rendre cet objet global revient à faire un éditeur global. Si l'éditeur global ne fait au final pas la même chose qu'un objet global avec son comportement contenant tout le code, c'est plus un bug qu'une différence fondamentale entre les deux.

Pour ton dernier exemple avec flèches, ennemis, buissons, ... je ne vois pas comment ton code peut ne pas être casse-gueule si les objets interagissent entre eux. Ce qui est très souvent le cas. Si tu as du code dans ton comportement de flèche qui réagit avec tel type d'ennemi. Tu vas devoir jongler entre chaque bout de code en ouvrant/fermant les comportements de chaque objet. Et l'événement de collision entre la flèche et l'ennemi, tu le mets dans le comportement de la flèche ou de l'ennemi? Suivant ton choix tu auras un problème avec l'un ou avec l'autre.
Et cela devient encore plus casse-gueule quand on sait que chaque comportement n'est pas lié à une instance d'objet mais bien à tous. Si tu as 5 flèches par exemple, penser qu'utiliser la variable A de cet objet utilisera pour chaque instances la valeur correspondante est faux. C'est complètement contre intuitif par rapport à la programmation classique. On en revient à faire des événements codés pour être sûr de bien boucler sur l'ensemble des instances (manuellement ou avec l'itération automatique de Fusion complètement cauchemardesque).

L'idéal serait de faire des comportements ce qu'ils devraient être, c'est à dire de la vrai programmation objet. Chaque comportement a ses paramètres (objets externes) et réagit indépendamment pour chaque instance de l'objet. En gros ce qu'on appelle une méthode de classe en programmation de base.

T inquiet pas pour mon code pas casse gueule du tout, ça fais un moment que j utilise les comportements je suis bien rodé, je range tout très bien je trouve ça plus clair qu' avant faut juste osé ce lancer :), je suis d accord sur le reste.
Exemple la.flèche gère les collisions sa vitesse sa direction etc ...
Les ennemis eux un comportement collision dans ce comportement je met l épée la.flèche les griffes etc ... C est ma façon de faire je m y retrouve super bien avant je jongler dans les groupes j aimais pas , puis c était lourd je trouve d'àvoir les.groupe de.tout le.monde alors que.je demande que les.présents un peu comme.si mes potes laissaient leurs vestes à la maison :P alors qu' ils ont qu' à les laissaient sur le moment ( je sais mes exemples sont pas top)

Les comportements j aime aussi car j ai juste à le copier coller sur un autres objet pour qu' il réagisse de la même manière ca me fais pense à de la poo.

Et je ne connaissais pas l objet tileset c est quoi cette choses ?!

Éditeur globale = inutile car :
Dossier ne s enregistre pas
Ordre des objets ne s enregistre pas
Pas fractionnable genre une partie pour tel scène !
Un objet globale avec comportement à pas ces default , donc déjà ça revient pas au même.du tout . Tu peu créer deux objets globale pour fractionner ton code car encore une fois tu as peu être pas.envie d avoir du code inutile et lourd.avec des boucles.dans des.scènes qui s en.servent pas :(.
Il suffira de copier le bon objet sur les bonne scène et ton code est divisé et globale , optimiser .

Et dernier point qui a dit que les comportements divisé les instance ?... Les mêmes règles que sur l éditeur de scène s applique on utilise des boucles,  et d ailleurs le.titre du topic le dit X).

Tu crois que c est couchemardesque mais tu trompe essayez avant de jugez , c est pas parce que vous, vous y arrivez pas que tous le.monde n en ai pas capable, puis de toute façon un arpg sur Android c est la seul solution simple, après on par dans des truc répétitif lourd, source de.bug énormes .

Je vous les dit je ne changerai pas d avis car.J était comme vous je trouvais ça horrible c est d ailleurs la dernière solution que j ai utilisé , et finalement la bonne, j ai essayer éditeur globale mais le.manque de rangement ma.trop compliquer la tâche, j ai essayer l éditeur de.scène mais copier le code partout aaaaahhhhh !
J ai essayer l éditeur de niveau maison c était super ! Vraiment ! Mais rame sous Android dégoûté !
https://m.youtube.com/watch?v=N7Nq3oqLJSo
Puis j ai réfléchit et j ai dit mais si je met mes objets en globale et un behavior ?! Oua j allais quitter mmf pour unity connaissant très bien le c# mais ça tout changer !

Voilà c est ma méthode je la garde si ca plaît pas rester avec vos méthodes , on trouvera toujours des default à chaques méthodes chacun la sienne mais arrêtons de pointer du doigt ce sera une discution éternelle  sinon.

Pour ma part elle me convient bien aussi. Je trouve de bosser comme celà bien pratique.

Mais comme le dit Patrice , à chacun sa méthode ^^ Si la personne se sent à l'aise avec l'une ou la multitude d'autre, il ne faut rien changer^^

Je vais commencer par la fin de ton message graboide pour qu'il n'y ait pas de malentendu. Je ne cherche pas à te convaincre de changer de méthode mais à expliquer que ce qu'a fait Clickteam avec les comportements est contraire à toutes les notions de poo et n'est pas à recommander à d'autres, d'autant plus si on utilise Fusion pour apprendre à programmer. Le premier principe qui n'est pas applicable est la notion d'héritage, qui se retrouve à travers les qualifieurs. Sans possibilité de les utiliser dans les comportements, on perd 80% si ce n'est plus du potentiel de factorisation d'un langage de poo. :(
Une autre chose qu'on apprend très vite en tant que programmeur, c'est que si on doit copier-coller son code plusieurs fois, c'est qu'il faut factoriser ou que l'on a fait une erreur de design. Ça n'est pas seulement moi et mon expérience personnelle qui parlent, c'est une règle de l'art en programmation.
Que Fusion copie automatiquement les événements avec les comportements ou qu'il faille le faire manuellement ne change pas le problème.
Reprenons l'exemple de la flèche en la généralisant à un ensemble de projectiles. Si tu as une pierre, une flèche, une boule de feu qui ont tous une trajectoire semblable, tu dois copier-coller le code qui gère la trajectoire dans les comportements pour chaque projectile.
Encore une dernière chose, si on n'utilise jamais l'éditeur d'événement, comment fait-on pour créer des objets dynamiquement? Ils se créent eux-même?
Ou ce sont d'autres objets qui les créent et dans ce cas là on se retrouve avec une interdépendance qui n'a pas lieu d'être?

Là où je te rejoins, c'est que l'éditeur d'événement pour tout faire est très lourd et on est obligé de bien séparer son code proprement et avec discipline (groupes d'événements ou autres).

Et je ne connaissais pas l objet tileset c est quoi cette choses ?!

L'objet Tilemap permet de gérer de manière performante une map de tiles (décors). La gestion de la mémoire est quasi optimale, peut-être gérée en temps réel, autorise l'animation des tiles... Que du bon. Par contre, comme je l'ai dit, cet objet n'a pas été porté sur d'autres plateformes que Windows. Mais sur le principe, c'est l'outil de factorisation ultime. En très peu de ligne d'événements, disons une vingtaine, et une seule scène on peut réaliser un moteur de A-Rpg du même type qu'Essia.

Et dernier point qui a dit que les comportements divisé les instance ?... Les mêmes règles que sur l éditeur de scène s applique on utilise des boucles,  et d ailleurs le.titre du topic le dit X).

C'est bien ça le problème. En poo, une méthode de classe ne gère pas toutes les instances mais bien uniquement l'instance créé. 

Tu crois que c est couchemardesque mais tu trompe essayez avant de jugez , c est pas parce que vous, vous y arrivez pas que tous le.monde n en ai pas capable, puis de toute façon un arpg sur Android c est la seul solution simple, après on par dans des truc répétitif lourd, source de.bug énormes .

C'est bien ce que j'ai fait. Avec Cardinal, je me suis dit que les comportements représentaient l'équivalent des méthodes de classe et j'ai commencé par ça. Mais quand j'ai vu qu'ils géraient toutes les instances et qu'il n'y avait pas d'héritage possible, j'ai tout de suite arrêté.

Tout cela peut en effet paraître très critique et je ne veux pointer du doigt personne, ni aucune méthode. Je trouve au contraire que cette discussion est très intéressante parce qu'elle représente pour moi le plus gros problème de Fusion. Comme je l'ai expliqué pour les comportements, ceux-ci auraient été une solution idéale s'ils respectaient les principes de base de la poo. Tout le code dans l'éditeur d'événement n'est pas non plus une solution idéale puisqu'il ne devrait pas avoir à gérer le comportement local de chaque objet.

Au début, j'utilisais également les comportements. Mais j'ai très vite compris que ça n'est pas la meilleure solution. En plus ils engendrent trop de bug sur le long terme et vérollent le MFA irrémédiablement. Par exemple l'appli se met à planter sans raison. Idem pour les objets globaux ou les événement globaux.

Pour moi, la meilleure solution reste la scene unique. Même pour un A-rpg. Je me crée un éditeur de niveau et chaque map se charge à partir d'un tableau de donnés. Puis cela active ou désactive les groupes d’événements en fonction de leur utilité ou pas dans ladite map en cours, pour alléger le code.

Il n'y a aucun problème problème de performance si on se démerde bien. Il est évident qu'il ne faut pas une scène de 50000x50000.
La scene doit faire la taille de la fenêtre visible à l'écran, par exemple 800x600. Le scrolling n'est pas un véritable scrolling mais un ensemble d'objets qui se déplacent , donnant l'illusion d'un scrolling. Les objets ne doivent pas être collé en décors. On utilise exclusivement des objets actifs, plus malléable. Tout objet en dehors du champ de vision doit être détruit. On ne crée les objets qu su'il sont visible à l'écran. Ce qui fait que l'ont doit tourner à 1000 objets maximum.

Encore une fois éditeur de.niveau sur fusion = rame sur Android, sinon oui c est la meilleur solution, et les comportement ne font pas planter j ai jamais.u de.cas de plantage à cause de comportements, et malgrés les très nombreuses lignes que j ai je m y retrouve mieux faut.juste savoir utiliser les comportements.
Chacun ca méthode arrêtez juste de nous descendre sans raisons... 
Ce débat sera éternelle laissez nos behavior tranquille.
De toute.façon je le redis encore et encore arpg Android il y a que ça de viable à moins de faire un truc d.une.lenteur extrême avec un éditeur de niveaux.

J utilise aussi les groupes mais excusez moi ce retrouver avec 100 groupes dans une scène c est un peu comme si tu coder tout un site sur une seul et.unique page .
Les scènes on juste l avantage des qualifier c est frustrant de pas pouvoir les utiliser mais c est mon choix

Par contre ç est vrai que les behavior seraient vraiment bien si ils géraient chaque instance indépendamment , peu être fusion 3?
La c est plus une autre façon de ranger son code oui "ranger" et de le partager entre scènes qu' autre choses

Encore une fois, le but n'est pas de descendre ta méthode graboide. Je trouve ta méthode de contournement des limitations de Fusion astucieuse.
C'est l'implémentation de Clickteam que je trouve complètement bancale pour les comportements et pas en accord avec ce que l'on trouve dans la poo classique.

Je suis plutôt d'accord avec toi sur les performances sur Android. Par contre sur Windows, il existe toutes les solutions pour faire un A-Rpg sans comportement donc on ne peut pas généraliser.

Oui mais moi tous les matins je trempe mon comportement dans mon chocolat ^^.
C est sur que devoir faire des boucle dans un comportement que l on pourrai croire indépendant pour chaque duplications déroute beaucoup, et même ca peu induire en erreur un debutant! Peu être qu' ils corrigeront ca dans fusion 3:). Après c est une histoire d habitude, on ce fais à tout, personnellement si je faisait un projet que Windows j utiliserai mon éditeur, mais garderai les comportements pour les actifs créer depuis le tableau car:

Si j ai 300 scènes avec des événement qui lui sont propre, imaginons 5 groupe par scènes , ça me fais déjà 1500 groupes dans la scène qui charge le niveau.
+ mes groupe pour mes ennemis + les groupes des moteurs.

Alors mon éditeur utilisait les comportement c était le top car un mix des deux

Puis-je avoir un exemple de ce qui rame sous Android ? Car je n'ai jamais constaté de problème de performance sur un Nexus 5 avec un éditeur de niveau.

Noooonnnn il a relancé le débat nooooooooonnnnnnnn  :'(

Ouais il a osé, je vais faire court, un des dernier patch le dernier même je crois corrigerai le problème, les décores coller à partir d actifs sont plus lent en plus de ne pas avoir de collision rectangulaire, résultat c est beaucoup plus lent, le même niveau fais avec un éditeur maison sera plus lent .
C est nouveau débat!
Après libre a vous de me croire mais c est la vérités.

Ne t’énerve pas, je te crois Graboide  ;)

Perso, je n'utilise jamais les décors. Je fais tout en full actif. Je n'utilise pas "coller à partir d'actif". Après si tu tiens absolument à utiliser des objets de décors, libre à toi.
Mais on n'est plus à l'époque de TGF où les objets actifs étaient limité à 150. Et ce n'est pas les quelques variables en mémoire que vont prendre en plus les objets actifs par rapport aux objets de décors, qui vont ralentir une application. Pour peu que l'on désactive la détection fine sur les objets actifs qui n'en n'ont pas besoin.
Ce qui fait ramer sur plateforme mobile c'est surtout le canal alpha sur les images.

je suis pas enervé lol j'était au travaille je faisais vite  :O  ;D ;D ;D dsl si je t'es mal répondu c'est pas voulu ;)
full actif même pour les décores ?!

tu m’intéresse la, tu veut dire qu'un actif qui et collision box et pratiquement identique qu'un décore? je l'ignorais completement
a quoi sert décores actif maintenant ? je pensais que c'était une histoire d'optimisation, autant utilisé un actif a la place :(

ça voudrai donc dire qu'il y avait vraiment un gros problème avec les décores coller a partir d'actif, et c'est pour ça que le passage de mmf2 a fusion 2.5 a été une cata pour mon éditeur, le bug est apparu la et que je suis passer du coter obscure des comportements  :jesors

ça me donne envie de refaire mon éditeur  ...

mais quand même full actif ? j'ai environ 1000 décores dans une scène ça me fais vraiment flipper 1000 actifs .

Graboide... De toute ma vie de Clickeur, je n'ai utiliser aucun, mais dans aucun de mes jeux l'objet décor...

Trop limité à mon goût ^^

et mes les gars je suis un vieux moi, avant il fallait les utilisé a fond je date de tgf !
j'ignorai çà moi !
Vous m’apprenez un truc la ! donc ca servait vraiment a que dal de coller mes actifs en décore ! du coup effectivement j'aurai pu me passer en grande parti des comportements :/, car j'aurai continué mon éditeur ! je vais peu être même le reprendre.
merci les gars !