Image de retard de l'émetteur

Ceci n'est pas vraiment un problème de rétrocompatibilité, mais il était présent pendant l'accès anticipé. Nous avons donc jugé bon de l'expliquer. Les émetteurs ont une image de retard, car, lorsque l'objet est cloné depuis la référence, il a besoin d'une image pour que la logique contenue puisse se lancer et pour qu'il soit certain que tout fonctionne normalement.

Par exemple :

Imaginez que vous avez un interrupteur et une lame rotative. L'interrupteur enclenche la lame rotative. Lorsque vous sélectionnez cet engin en tant que référence cible d'un émetteur, la lame rotative existe toujours dans la scène en tant qu'objet de référence pour l'émetteur, mais elle est désormais désactivée.

Lorsque vous émettez un objet, le jeu effectue littéralement un clonage de la référence. Vous avez donc désormais une copie de l'interrupteur et de la lame rotative, mais la lame est désactivée (l'interrupteur est inactif). L'émission d'objets a lieu dans l'image après le code qui envoie des signaux à travers les câbles, donc si nous devions montrer les objets émis sur l'image lors de laquelle ils étaient émis, vous verriez une lame immobile sur une image, puis elle se mettrait à tourner plus tard sur l'image suivante une fois que le signal a suivi le câble depuis l'interrupteur. Afin d'éviter des problèmes de ce type (et des problèmes encore plus compliqués impliquant plusieurs gadgets, barres de temps, etc.), nous ne montrons pas les objets sur la première image lors de laquelle ils sont émis. Ils ne génèrent pas de physique sur cette image et ils n'utilisent pas de logique (comme des zones de déclencheur, raycasts, etc).

La seconde image est légèrement plus intelligente, car lorsque l'objet apparaît, si l'émetteur est aussi en mouvement, alors le retard de l'image est visible parce que l'objet apparaît derrière l'émetteur (imaginez des balles tirées par un vaisseau). Afin de compenser cela, nous déplaçons les objets émis au dernier moment à l'endroit où ils auraient été émis si l'émetteur émettait lors de cette image ! Toutes les vitesses sont alors calculées à nouveau.

Dans « Wildfire » le personnage perd deux vies lorsqu'il meurt. C'est parce que le personnage réapparaît depuis un émetteur. La logique du personnage émis n'arrive pas à communiquer avec la première image et force le système à le tuer une seconde fois.

Barres de temps émises :

Nous n'avons pas encore d'exemple de cette éventualité dans le contenu créé par la communauté, mais nous en avons eu un de notre côté et c'est plutôt similaire à ce problème de retard de l'image. C'est aussi le meilleur exemple pour visualiser le comportement de cet émetteur. Un gadget (ex. : une fonction NON) sur la première image d'une barre de temps émise n'arrivera pas à déclencher quoi que ce soit.

Si vous faites face à ce problème, la solution la plus simple est de retirer la fonction NON de la barre de temps afin qu'elle puisse déclencher tout événement logique dès que la logique devient active. S'il faut que votre déclencheur soit une pulsation, vous devrez peut-être ajouter un manipulateur de signal.

Infos dans un cercle

Le guide des utilisateurs de Dreams est en cours de constitution. Gardez un œil sur nos annonces, car nous ajouterons progressivement de nouvelles ressources d'apprentissage et de nouveaux articles.