Calculateur de ticks Minecraft

Dans Minecraft, vous pensez parfois la durée en secondes, alors que le jeu compte des ticks en arrière-plan. Une porte redstone se ferme deux étapes trop tôt, une ligne de hopper se vide plus lentement que prévu, ou vous saisissez un nombre dans la commande /time set, mais le soleil ne s’arrête pas à l’endroit voulu. Le problème n’est généralement pas que le jeu est cassé ; c’est plutôt que vous considérez le temps réel, le game tick et le redstone tick comme une seule et même chose. Cette confusion est fréquente, surtout chez les joueurs qui débutent avec la redstone.

Le temps du jeu ne s’écoule pas comme des secondes

Le rythme de base de Minecraft repose sur les game ticks. Dans le jeu vanilla, la vitesse cible est de 20 game ticks par seconde. Autrement dit :

$$
1 \text{ seconde} = 20 \text{ game tick}
$$

Un game tick correspond aussi à 0,05 seconde.

$$
1 \text{ game tick} = 0{,}05 \text{ seconde}
$$

Sur le papier, c’est très simple.

Si vous saisissez 60 secondes, cela donne 1200 game ticks. 1 minute donne également 1200 game ticks. 10 minutes donnent 12000 game ticks. Le fait qu’un cycle complet de jour Minecraft dure 24000 ticks devient aussi plus clair ainsi ; dans un monde fonctionnant à 20 TPS, 24000 ticks correspondent à 20 minutes dans la vie réelle.

Quand les TPS baissent, les choses changent. 1200 game ticks durent 60 secondes à 20 TPS. Si le serveur descend à 10 TPS, ces mêmes 1200 ticks s’étalent cette fois sur 120 secondes en temps réel. Ce que vous observez en jeu en vous demandant « pourquoi c’est en retard ? » ne vient parfois pas du circuit, mais de la charge du serveur.

La formule principale pour calculer une durée est la suivante :

$$
\text{Game Tick} = \text{seconde} \times \text{TPS}
$$

L’inverse s’écrit ainsi :

$$
\text{seconde} = \frac{\text{Game Tick}}{\text{TPS}}
$$

Pour le vanilla, on prend généralement 20 comme valeur de TPS. Si le serveur est laggy et que vous essayez de comprendre le temps d’attente réel, il faut entrer les TPS tels quels ; sinon, votre calcul reste théorique.

Cette distinction devient particulièrement pénible dans les farms automatiques et les circuits redstone. Un montage qui fonctionne correctement en solo peut se comporter plus lentement sur un serveur fréquenté. Le jeu demande toujours le même nombre de ticks, mais il traite simplement ces ticks plus lentement.

Le redstone tick parle une autre langue

Dans Minecraft, le mot « tick » seul est un peu piégeux. Quand quelqu’un dit « mets un délai de 10 ticks », il faut d’abord comprendre s’il parle de game tick ou de redstone tick. Côté redstone, 1 redstone tick est considéré comme 2 game ticks. À vitesse vanilla, cela fait 0,1 seconde.

$$
1 \text{ redstone tick} = 2 \text{ game tick}
$$

$$
1 \text{ redstone tick} = 0{,}1 \text{ seconde}
$$

10 redstone ticks font 20 game ticks. Mais 10 game ticks ne font que 5 redstone ticks.

$$
\text{Game Tick} = \text{Redstone Tick} \times 2
$$

$$
\text{Redstone Tick} = \frac{\text{Game Tick}}{2}
$$

Si vous confondez les deux, le timing du circuit est décalé d’un facteur deux. Dans les portes à pistons, les verrouillages d’item sorter et les chaînes d’observers, cette différence se voit immédiatement. La porte se bloque là où elle devrait se fermer, le piston n’attrape pas un bloc, ou le sorter laisse passer trop d’items. Ensuite, on accuse le câblage. Parfois, le câblage est innocent.

Le délai du repeater se traite donc séparément. Un repeater peut fournir un délai de 1, 2, 3 ou 4 redstone ticks. Si vous voulez un délai plus long, vous placez des repeaters les uns à la suite des autres.

Supposons qu’un délai de 46 game ticks soit demandé. On le convertit d’abord en redstone ticks :

$$
46 \text{ game tick} \div 2 = 23 \text{ redstone tick}
$$

Pour construire 23 redstone ticks avec des repeaters, il faut 5 repeaters complets réglés sur 4-tick, et il reste 3 redstone ticks.

$$
23 = 5 \times 4 + 3
$$

La configuration se lit donc ainsi :

5 x 4-tick + 1 x 3-tick.

C’est aussi ici que la logique d’arrondi vers le haut intervient. Si le calcul ne tombe pas exactement sur un redstone tick, il est plus sûr de compléter à la valeur supérieure plutôt que de fournir un délai trop court. Après tout, il n’existe pas de demi-réglage de repeater. C’est soit 2 ticks, soit 3 ticks. Rien entre les deux.

L’expression pratique utilisée côté repeater est la suivante :

$$
\text{Repeater Redstone Tick} = \left\lceil \frac{\text{Game Tick}}{2} \right\rceil
$$

On trouve ensuite le nombre de repeaters 4-tick :

$$
\text{Nombre de répéteurs à 4 ticks} = \left\lfloor \frac{\text{Redstone Tick}}{4} \right\rfloor
$$

Le délai restant est obtenu avec un calcul modulo :

$$
\text{Restant} = \text{Redstone Tick} \bmod 4
$$

En redstone, ces petites différences peuvent parfois devenir importantes. Surtout dans les systèmes rapides à pistons, un signal qui arrive « un tick plus tard » peut décider si toute la construction fonctionne correctement ou non. C’est l’un des côtés impitoyables du jeu.

Pourquoi les valeurs de /time set semblent-elles étranges ?

Une journée Minecraft dure 24000 game ticks. Le mouvement du soleil, le cycle jour-nuit et la commande /time set fonctionnent tous sur cette ligne. Quand vous écrivez 6000 dans la commande, il est midi. Autour de 12000, c’est le coucher du soleil. 18000 peut être vu comme minuit.

Mais la logique de l’horloge ne commence pas comme dans le monde réel au premier regard. Le tick 0 est lu dans le jeu comme environ 06:00. C’est pourquoi 6000 ticks correspondent à environ 12:00. 18000 ticks se placent autour de 00:00.

Le calcul du tick dans la journée regarde le reste de la valeur saisie par rapport à 24000 :

$$
\text{Jour Tick} = \text{Game Tick} \bmod 24000
$$

Ainsi, même si vous écrivez 25000 ticks, le jeu le lit comme le 1000e tick du nouveau jour. Car après 24000, le cycle recommence.

Le calcul approximatif utilisé pour l’équivalent horaire est le suivant :

$$
\text{Heure} = \left\lfloor \left(\frac{\text{Jour Tick}}{1000} + 6\right) \bmod 24 \right\rfloor
$$

Pour les minutes, la valeur de tick restante est multipliée par 0,06 :

$$
\text{Minute} = \text{round}((\text{Jour Tick} \bmod 1000) \times 0{,}06)
$$

Pour 6000 ticks, le calcul donne environ 12:00.

$$
\left(\frac{6000}{1000} + 6\right) \bmod 24 = 12
$$

Les créateurs de cartes utilisent beaucoup cela. C’est aussi utile pour prendre des captures d’écran. Parfois, même la direction de l’ombre change toute la scène ; ceux qui prennent des photos en jeu le savent, la lumière du matin et celle de midi ne donnent pas la même impression.

Cette courte liste est facile à retenir :

Écrire 24000 ou 0 revient au même dans la plupart des cas. Le jeu ramène le cycle au début.

Attendre à la vitesse d’un hopper est un autre problème

Le hopper est l’une des pièces les plus discrètes de Minecraft, mais aussi l’une de celles qui créent le plus souvent des goulots d’étranglement. Il lui faut 8 game ticks pour transférer un item vers un autre inventaire. À 20 TPS, cela fait 0,4 seconde.

$$
1 \text{ transfert par hopper} = 8 \text{ game tick}
$$

$$
1 \text{ transfert par hopper} = 0{,}4 \text{ seconde}
$$

La vitesse de transfert d’un seul hopper par minute se calcule ainsi :

$$
\text{Item / Minute} = \frac{\text{TPS} \times 60}{8}
$$

Si les TPS valent 20 :

$$
\frac{20 \times 60}{8} = 150
$$

Un seul hopper transporte donc environ 150 items par minute.

Prenons un lot de 400 items. On trouve d’abord son équivalent en ticks :

$$
400 \times 8 = 3200 \text{ game tick}
$$

Puis on le convertit en secondes :

$$
\frac{3200}{20} = 160 \text{ seconde}
$$

160 secondes font 2 minutes et 40 secondes.

Ce nombre peut sembler petit, mais il ne paraît pas si petit quand vous attendez devant le coffre pendant que la farm fonctionne. Surtout si le système produit 300 items par minute et que vous essayez de tout récupérer avec un seul hopper, l’engorgement est inévitable. Les items s’accumulent, puis une file d’attente de hopper se forme, puis vous commencez à voir des items au sol.

Voir des items au sol est la façon dont le système de stockage dit : « je n’arrive pas à suivre ».

Il ne faut pas faire une erreur dans le calcul des hoppers : cette vitesse concerne un seul hopper. Si plusieurs lignes fonctionnent en parallèle, le débit augmente. Si la chaîne de hoppers est très longue, chaque transfert ajoute son propre délai. S’il y a un canal d’eau, une ligne de droppers, un chest minecart ou un système de transport moddé, le sujet change. Ce calcul sert surtout à lire rapidement le comportement vanilla des hoppers.

Les TPS influencent ici aussi le temps réel. Alors que 400 items sont transférés en 160 secondes à 20 TPS, ce temps passe à 320 secondes à 10 TPS.

$$
\frac{3200}{10} = 320 \text{ seconde}
$$

Le nombre de ticks en jeu est le même, mais le temps d’attente réel double. C’est parfois pour cette raison que l’on demande sur un serveur : « le hopper est cassé ? » Il n’est pas cassé, le monde est simplement devenu plus lourd.

Quel mode utiliser, et quand ?

Si vous avez une question du type « combien de secondes ? », une conversion simple suffit. Par exemple, si vous dites « la porte doit se fermer après 5 secondes », 5 secondes font 100 game ticks.

$$
5 \times 20 = 100 \text{ game tick}
$$

Savoir cela suffit pour les command blocks ou les tâches de délai simples.

Si vous construisez un circuit redstone, regardez le délai des repeaters. Car ce que vous placez dans le jeu n’est pas une seconde, mais un réglage de repeater. Un délai de 2 secondes fait 40 game ticks, donc 20 redstone ticks.

$$
2 \times 20 = 40 \text{ game tick}
$$

$$
40 \div 2 = 20 \text{ redstone tick}
$$

20 redstone ticks peuvent être construits avec 5 repeaters réglés sur 4-tick.

Pour le temps Minecraft, il faut une valeur /time set. Si vous voulez « qu’il soit midi », utilisez 6000 ; si vous voulez « qu’il soit minuit », utilisez environ 18000. Ici, on ne parle pas de secondes, mais de position en ticks dans la journée.

Côté hopper, la question est tout autre : « En combien de temps cette quantité d’items va-t-elle circuler ? » Il est plus logique d’entrer le nombre d’items et de voir la durée. C’est particulièrement utile pour comprendre si un seul hopper suffit à la sortie des farms automatiques.

Le choix de l’unité est important. Game tick, redstone tick, secondes, minutes, transfert de hopper et journée Minecraft peuvent sembler être différentes faces d’une même chose, mais ils servent à prendre des décisions différentes dans le jeu. Vous pouvez voir les secondes comme le temps humain, le game tick comme le temps du jeu, et le redstone tick comme le temps du circuit.

C’est un peu approximatif, mais ça fonctionne.

Si le calcul est juste, pourquoi le jeu se comporte-t-il différemment ?

Même lorsque le calcul en ticks est correct, le résultat en jeu peut ne pas correspondre exactement. Il y a plusieurs raisons à cela.

La première est le TPS. Si le serveur ne fonctionne pas à 20 TPS, le temps réel s’allonge. Le temps que le jeu dise « 1200 ticks sont passés », vous avez peut-être attendu plus de 60 secondes dans le monde réel. Le calcul de commande, de redstone ou de hopper n’est pas faux ; il se termine simplement plus tard.

La deuxième est le chargement des chunks. Si un chunk n’est pas chargé, certains systèmes qui s’y trouvent ne fonctionnent pas comme prévu. Ligne de hoppers, farm, redstone clock : tout dépend du fait que le monde reste actif. Un montage laissé loin de vous ne continue pas toujours à fonctionner comme vous l’imaginez.

La troisième est l’ordre des mises à jour redstone. La redstone n’est pas seulement un calcul de durée. La provenance du signal, le bloc qui se met à jour en premier, l’orientation du repeater, le comportement du comparator, ce que le piston détecte et à quel moment : tout cela entre en jeu. Parfois, 4 ticks est la bonne valeur, mais l’agencement du circuit est mauvais.

Il existe aussi des différences entre Java et Bedrock. Même si la plupart des rapports de temps de base semblent identiques, les différences de comportement redstone entre versions peuvent créer des problèmes. Il n’est pas surprenant de regarder un circuit Java sur YouTube, de le reproduire exactement dans Bedrock, puis de constater qu’il ne fonctionne pas.

À ce stade, le calculateur ne fait pas de magie. Il vous donne proprement la partie liée au temps. Le reste dépend de l’agencement physique du jeu.

Quelques petites habitudes utiles

Commencez par préciser de quel « tick » il s’agit. Game tick ou redstone tick ? Faire un calcul de circuit sans poser cette question, c’est un peu comme placer des blocs sans mesurer.

Dans les longues lignes de hoppers, ne vous fiez pas à la vitesse d’un seul hopper. Si une farm produit plus de 150 items par minute, une seule ligne finira par se bloquer. Faut-il deux lignes, un flux d’eau, un dropper clock ? Cela dépend de la conception.

Pour les commandes /time set, au lieu de mémoriser tous les nombres, retenez quelques repères principaux : 0 le matin, 6000 midi, 12000 le soir, 18000 minuit. Le reste se règle à l’œil. Minecraft est aussi un peu un jeu d’estimation visuelle, après tout.

Pour le délai des repeaters, penser en blocs de 4-tick facilite les choses. Convertissez d’abord le délai en redstone ticks, puis divisez-le en groupes de 4. S’il reste 1, 2 ou 3, ajoutez un repeater de plus à la fin.

N’oubliez pas complètement les TPS non plus. En monde solo, l’hypothèse de 20 TPS suffit la plupart du temps. Si les choses deviennent étranges sur un serveur, vérifier d’abord les TPS est plus judicieux. Avant de démonter la ligne redstone, donc.