[Map Making] Longs délais - garanti sans vidéo

Si vous avez déjà fait des maps aventures, vous vous êtes probablement déjà confrontés au problème des longs délais en redstone. Et dès qu'on commence à mettre un paquet de repeater à la suite, on commence à se dire que ce n'était peut être pas la bonne solution.
Voici différentes solutions permettant de palier à ce soucis:

Les hopper-clocks
- Modèle by Etho (réalisable en survival)
Ce modèle est aussi utilisé comme horloge très basse fréquence. Il se base sur le temps que met un hopper à transférer son contenu dans un autre bloc (ici, un hopper). En fonction du nombre d'objet dans le hopper, on obtient un délai différent.



Tout les pistons sont des pistons collants dans le cas des horloges. Pour un simple "delayer longue durée", vous pouvez utiliser des pistons normaux.
Base de calcul: 150 objets (2 stacks + 22 objets) transférés valent 2 minutes (ou une minute actif et une minute inactif)

- Modèle by MrSourceCoded (créatif+1.8 seulement)
Le principe est le même que pour l'horloge d'Etho sauf qu'on utilisera un seul objet. On préfèrera modifier le temps que met un hopper pour transférer un objet dans un autre hopper en utilisant la commande blockdata.
La commande doit être exécutée à chaque fois que l'item entre dans le hopper:



Un comparateur sur la doite émettra un signal tout les X temps en fonction de ce que vous entrez
Commande:

Code (cpp):

/blockdata x y z {TransferCooldown:Temps en game tick}

Rappel: 1200 game tick = 1 minute

Les fallingSands
- Modèle by Mlakuss (créaftif seulement)
Le principe consiste à faire apparaître un bloc de sable ayant le même ID qu'un bloc de redstone dans une toile d'araignée. En fonction de la hauteur dans la toile, le sable tombant mettra plus ou moins de temps à traverser la toile.
Si on souhaite stopper ce timer, un /kill fait l'affaire (1.8 seulement pour stopper)



Ici, j'ai mis dans le bloc /summon FallingSand ~ ~0.5 ~2 {cf ci-dessous}. Après activation, le bloc arrivera au niveau du repeater de droite environ 12.5 secondes après (équivalent à 32 repeaters pour comparaison). Je peux changer le 0.5 de la commande pour faire des délais grimpant jusqu'à 23 secondes (produit en croix, toussa toussa).
Un délai de 23 secondes, c'est peut être peu, mais je trouve ce système très pratique pour les dialogues dans les maps aventure: avec un même "module" on peut modifier le délai juste en changeant un nombre dans une commande et le texte dans le chat apparaît durant 9 secondes. Largement suffisant donc.
Exemple avec Kyurle, le dialogue du roi (les fichiers audio font aussi rarement plus de 23 secondes quand il s'agit de dialogues):



Une série de blocs de commande sous les toiles d'araignée permet de réinitialiser le module suivant pour que le circuit puisse resservir plusieurs fois et que le dialogue ne se déclenche pas deux fois.
En plus c'est clean et je peux facilement retrouver où je dois modifier la commande au besoin.

Commandes:

Code (Command Block):

/summon FallingSand x y z {Time:1,Block:"minecraft:redstone_block",TileID:152} //Commande valable en 1.7 et en 1.8
/kill @e[type=FallingSand] //Commande valable en 1.8 seulement

Utilisation du scoreboard
Quand on arrive à des délais très importants ou très précis, le scoreboard est peut être la meilleure solution.

Horloge à durée pré-déterminé via le scoreboard.
Si vous souhaitez faire un timer de 8, 10 ou 15 minutes par exemple, voici une solution qui devrait vous convenir.
On va commencer par créer une horloge "unitaire" qui déterminera la précision de votre timer.
Horloge d'une seconde
Maintenant, on va créer un objectif dans le scoreboard:

Code (Command Block):

/scoreboard objective add timer dummy

Dans l'horloge on va placer les commandes suivantes:

Code (Command Block):

/scoreboard players remove #T timer 1
/scoreboard players test #T timer 0

On place un comparateur en sortie du second et un inverseur poir avoir ceci:

J'ai relié la sortie de l'horloge à l'entrée pour qu'elle se désactive quand elle n'est pas utilisée.

Pour démarrer le timer, il ne reste plus qu'à faire

Code (Command Block):

/scoreboard players set #T timer <durée>

Puis on envoie une impulsion dans le circuit.
Exemple pour faire ça facilement:

L'unité de la durée dépend de ce que vous avez mis comme horloge. Pour une horloge d'une seconde, la durée est en seconde.
Dès que la torche s'allume, c'est que le timer est arrivé au bout.

Avec des objets au sol
Lorsque vous jetez un objet au sol, celui-ci met précisément 5 minutes avant de disparaître.
En utilisant ce principe, il est donc possible de créer des systèmes s'activant toutes les 5 minutes... au avec des durées customisées si vous avez accès aux commandes !

Pour modifier le temps que met un objet pour disparaître, il faut utiliser le tag "Age". Un objet disparaît dès qu'il vaut 6000 (5 minutes en partant de 0). Il est possible, lorsqu'on fait apparaître un objet de choisir la valeur dans Age et même de mettre des valeurs négatives (attention cependant à ne pas mettre en dessous de -32768 sans quoi votre objet ne disparaîtra jamais ou alors instantanément).

Code (cpp):

/summon Item ~ ~1 ~ {Age:x}

Exemple pour 10 minutes:

Code (cpp):

/summon Item ~ ~1 ~ {Age:-6000}

 

Ajout d'un timer modulable via le scoreboard

 

Yep, pour avoir exactement une seconde, faut fair une horloge "basique", il y en a une sur les deux derniers screens.
En l'isolant, ça donne ça:

La boucle va changer d'état toutes les 0.5 secondes (0.4 pour le delayer + 0.1 pour le comparateur), soit une passage de 0 à 1 toutes les secondes. Ne pas oublier de passer le comparateur en mode soustraction (clic droit dessus).

Edit: j'ai déjà mis un exemple d'horloge d'une seconde dans l'OP, suffit de cliquer dessus pour la voir.

 

Non. Si les games ticks sont ralentis, il n'existe aucun moyen de contrer ça... sinon modifier les circuits de redstone pour que ça laggue moins (c'est actuellement mon job sur une grosse map, le chrono d'une minute en durait 3.. on est passé à 1.5 minute après moultes optimisations).
Tip: les /setblocks et /fill en boucle causent beaucoup de soucis (pour les horloges, il faut bien penser à tout mettre dans le noir où à éclairer à fond). Viennent ensuite les /replaceitem.

 

Oui, à condition que le /blockdata soit effectué à chaque fois que le comparateur s'allume.
Le TransfertCooldown n'est valable que pour le prochain objet qui sera envoyé par le hopper.