oki mrci

Tuto de très grande qualité, je t'en remercie et j'ai envie de m'y mettre aussi grâce à toi !!! J'espère être à la hauteur

Petit conseil entre pros wired parce que je vois que tu t'y connais, je te conseille d'utiliser ":pyramide close" pour cacher tes pyramides en vidéos

Aussi je te conseille de mettre des dalles magiques pour pas que le pathfinding des joueurs soit cassé

@Zertyazertyu Merci beaucoup pour tes conseils sa me fait super plaisir de te motiver fonce ?

Ajoutez une condition "position des portes ouvertes" sur le déclencheur 0.5s pour éviter de fermer les portes toutes les 0.5s pour rien

@Moh je doute que ce type de système soit utilisé dans un appart blindé de wireds, il faut savoir correctement doser complexité du système et confort de l'utilisateur, pour deux mobis le lag généré est insignifiant, cette correction doit être de l'ordre de l'optionnel voir ignorable
Pour un système de 5 wireds, venir expliquer la raison de pourquoi ajouter ce 6eme décalerait le viseur sur un autre publique, qui sait déjà faire ce type de builds
Parce que ton court texte n'explique même pas pourquoi en quoi on doit éviter la répétition de la fermeture de ces portes, et je suis presque sûre que tu ne sais pas fondamentallement toi non plus, à part "bah ça bouge sans cesse", certains systèmes n'ont pas besoin de ce type de limiteur qui serait strictement inutile dans certains cas

Mais bon, pour te donner raison, ce 6eme wired serait en effet utile mais seulement sur de très gros apparts
( à condition bien entendu que le rétro dispose de la commande :wired ou autre alternative et que cette dite commande ne laisse pas le serveur envoyer les packets d'update animation des wireds en eux même, auquel cas ajouter cette condition serait peut-être pire pour certains rétros et certaines conditions bien que sur city le bénéfice puisse exister dans de mêmes conditions, méthode à ne privilégier à l'aveugle que sur city ET sur de gros systèmes )

le lag pourrait commencer à se percevoir au bout d'un certains nombres de portes, bien que là l'exemple se repose sur une seule. Les joueurs doivent être conscient des effets qu'ils engagent lors d'un déclenchement et l'aspect pédagogique du tuto ne doit pas se reposer sur un exemple pour les plus intéressés 

Je veux dire par là que l'ajout de telle condition diminue/ne change rien/augmente le lag est bien plus dur à déterminer que ce que tu crois, ce n'est pas juste "du bon sens" qui aidera, si tu prones le partage de connaissance tu dois cependant avoir conscience non seulement de cette dite connaissance mais aussi de quand partager celle ci, parce qu'entre montrer un système à 5 wireds et expliquer à l'utilisateur l'importance de la diminution des packets ainsi que son repérage, c'est deux histoires radicalement différentes, où l'un est consistant sur quasiment tous les rétros, l'autre est bien plus difficile à déterminer ( cf les petites lignes de mon précédent commentaire )

Avant de faire lag son appart, l'utilisateur devra posséder dans les 50 portes coulissantes soit environ 100 mobis actifs par gametick dans le même appart ( vaguement testé sur un PC de moyenne qualité, c'était une limite arbitraire fixée pour déterminer si un de mes apparts allait lag ou non ), ce qui ne risque probablement pas d'arriver, et je ne parle bien que de city, où sur d'autres rétros pour le même système tu auras plutôt (edit 250 - 100 donc 150) mobis actifs par gametick, (edit 300 - 100 donc 200) en ajoutant cette dite condition, ce conseil serait donc contre productif dans la mesure où tu n'expliques pas toi même pourquoi précisément ajouter cette condition

Sur city tu peux l'ajouter aveuglément sans impact significatif sur des systèmes anécdotiques, mais puisque c'est un système anécdotique alors la pertinence d'ajouter cette condition diminue grandement
Ce type de détail ne doit être évoqué que lorsque l'utilisateur a déjà un bon niveau en wired, parce que c'est littéralement un petit détail, qui ne fera que compliquer la vie des novices pour un résultat que très peu différent, un novice ne fait que très rarement l'équivalent de 50 portes coulissantes dans un même appart
Tu comprends mieux mon intervention ?

edit : ce forum reprend la mise en forme lorsque tu copies/colles tes textes, utilise ctrl + shift + V pour coller un texte sans mise en forme, à cause du thème sombre qui modifie une police d'écriture noire en une police d'écrite blanche, je vois ton texte blanc sur fond blanc

Cool ça !

Quand on dit :wired les packets animations sont envoyés ok ? Mais est ce que les images sont chargées car nous les voyons pas ? Je doute que l'envoie de packets soit plus génératrice de lag que des images qui chargent (tout est relatif au nombre d'instructions envoyées et au nombre d'image bref) bien qu'ils ne devraient pas avoir lieu. Et si c'est le cas j'insinue donc que sur city vouloir limiter ses répitions de positions de mobiliers pour limiter le lag serait donc contre productif car une condition charge des images dans son coin ?

merci mec ça me sauve la vie pour mon super marché que j'ouvre demain 

Tu ne connais définitivement pas comment ça marche
L'image ne se charge qu'une seule fois sur le client et c'est bien l'entité qui génère le plus de lag que l'image en elle même qui elle n'est que simplement dessinée
Lorsqu'un packet est envoyé pour activer l'animation d'un mobi, c'est l'entité qu'est traitée dans son ensemble et la présence de l'image est quasi nulle
Tu peux faire le test par toi même, pose un grand nombre de mobis aux images gigantesques et fais les bouger, une fois l'image chargée une seule fois, le mouvement de ces mobis ne générera pas plus de lag que des pyramides invisibles cachées ( edit : en excluant les backgrounds qui ont un comportement très différent des mobis classiques )

Quand on dit :wired, seuls les packets pick item sont envoyés
Lorsque tu entres dans un appart avec :wired d'activé, un grand packet "objects" est envoyé au client, contenant tous les objets de ton appartement, tout objet figurant dans la liste des "wireds" ne sera pas inclu dans ce grand packet "objects" et donc ni l'image ni l'item ne sera chargé dans le client
Cependant le serveur ( en fonction du rétro ) enverra, ou non, toute modification faite par ton système, lorsque tu ouvres une porte coulissante via wired, ce n'est pas l'image qu'est envoyé au client mais un bout d'information qui demande au client de déplacer le mobi, l'image n'est qu'une quantité fixe de donnée tandis que "déplacer le mobi" lui est un ordre à traiter, l'ordre à traiter a davantage plus de chance de générer du lag que de redessiner l'item sur le client à une nouvelle position ( edit : pour te donner un exemple, un appart fixe à 5000 mobis va dessiner 5000 mobis à chaque nouvelle frame, un appart à 5000 mobis qui se déplacent va dessiner 5000 mobis à chaque nouvelle frame, si on ignore tout le reste et qu'on ne prend en compte que le dessin de ces 5000 mobis, déplacement ou non, le lag généré sera strictement identique, c'est bien les fonctions d'update position/état de l'item qui générera ce lag ), c'est d'ailleurs à ça que sert le modificateur animation mobi, l'image existe toujours mais le packet ordonnant l'animation de déplacement du mobi lui n'existe plus, non seulement ce modificateur peut servir pour certains déplacements dont tu ne souhaites pas que l'utilisateur y voit son déplacement, mais aussi parce que ce modificateur diminue par deux la quantité d'instructions que ton client va recevoir, en temps normal le client reçoit la nouvelle position du mobi en tant que première instruction ET l'instruction de l'animation du mobi vers sa nouvelle position, en estimant que ces deux instructions génèrent autant de lag, le modificateur diminuera le lag d'un tel système par deux

Cependant, en fonction du rétro, cacher les wireds ne va pas empêcher au serveur d'envoyer au client les instructions d'animation mobi, le client possède déjà toutes les images déjà chargées ( même potentiellement chargées en cache donc encore moins impactant ), c'est bien l'ordre de l'animation qui générera du lag, bien que le wired soit caché, le client traitera entièrement la demande d'animation
Et toujours en fonction du rétro, certains rétros ont eu l'excellente idée de ne pas envoyer le packet d'animation de déplacement du mobi au client si le mobi n'a pas de nouvelle position depuis la dernière fois, auquel cas cette condition n'a VRAIMENT aucune utilité quoi qu'il arrive, et ce rétro en question n'a pas eu l'idée justement de bloquer l'envoi des packets pour les wireds cachés, ce qui fait qu'ajouter une nouvelle condition sur cette pile est la pire idée possible sur ce rétro

C'est vraiment pas une question d'images à charger
J'ajoute à ça que, si tu consultes le titre de la vidéo et le contenu des précédentes vidéos, cette vidéo est destinée à un autre rétro que city, auquel cas ton conseil n'aura aucune valeur

Pour résumer de manière un peu plus claire :

Lorsque tu ouvres ton catalogue, que tu entres dans ton apparts ou que tu lances ton jeu, le client va recevoir des fichiers swf ( contenant l'image des mobis/tout autre objet ), ces fichiers swf une fois reçu ne seront pas ré envoyés par le serveur, les images seront donc "définitivement chargés" dans le client tant que le jeu n'a pas été relancé et/ou tant que le cache n'a pas été vidé ( c'est d'ailleurs pour ça qu'en cas de mise à jour, le serveur ne va pas envoyer les updates en croyant que ton client les possède déjà, d'où l'utilité de vider son cache )

Le jeu interagit avec le client au travers de petites informations ( bien moins lourdes que des images en général ), l'image d'un item étant déjà chargé sur ton client, tout ce qui compte au niveau des performances c'est seulement la réception de ces dites petites informations ( qu'on appelle des packets )

Que l'image soit présente ou non, ce qui compte réellement c'est l'objet en lui même et à quelle fréquence il est traité
Et c'est là le souci, comment savoir si ton objet est traité ? Si l'ajout d'une condition va effectivement limiter la quantité de traitements et non pas en ajouter ?

Si les images sont chargées dès le début quand on entre dans un appartement, pourquoi j'ai l'impression que modifier la position d'un mobis bug moins que changer l'état d'un mobis ? car d'après ce que tu dis que ce soit un changement d'état ou un changement de position seule l'instruction d'un appel de packet change sans qu'il y'ait d'impact sur le chargement d'image

Est ce que c'est simplement une impression ou est ce que tu l'as testé ?
Si tu venais à tester ça, crées deux apparts avec exactement les mêmes mobis et exactement les mêmes wired ( à l'exception de l'effet ), bien entendu avec énormément de mobis et regarde sur plusieurs fois lequel te fera crash le plus rapidement ( c'est un test au pif mais si tu ne vois aucune différence significative alors il n'y a aucune raison de penser que l'un lag plus que l'autre )

Cependant si tu as déjà testé ça et que je dois vraiment y répondre, je répondrais : sans doute parce que lors du changement de l'état du mobi, non seulement tu charges une nouvelle image sur ton client mais en plus tu demandes le changement d'état de ton mobi ( en supposant que l'image de l'état suivant n'a pas été chargé par ton client précédemment, ce qui me parait improbable puisque le serveur n'envoie pas un mobi image par image mais bien son entièreté d'un coup il me semble )
Mais une fois l'entièreté des états du mobi chargé sur ton client, déplacement ( sans animation de déplacement ) et changement d'état provoquera plus ou moins la même quantité de lag

edit : si tu ne crois pas en ma parole, je t'invite à vérifier ça par toi même, en ouvrant l'outil de travail de ton navigateur et en cliquant sur l'onglet "network", recharge ta page et connecte toi au rétro, tu verras le serveur t'envoyer ces dits swf, et d'autres fichiers, tu peux ainsi fouiller le contenu d'un swf pour voir ce qu'il contient et tu y verras l'entièreté de ses images, ensuite tu observeras si ce même swf est ré envoyé à chaque update mobi/chaque ré entrée dans l'appart, tu verras que non