Pourquoi enlever la poussière de redstone de mes blocs de commande ?

Question

Chaque fois que je montre mes engins à mes amis, ils me disent toujours que je devrais enlever la poussière de redstone. Ils disent que cela cause du lag et que la redstone peut être imprévisible, mais je n'ai jamais eu ce genre de problème.

Même si c'était le cas, je devrais simplement ralentir un peu l'horloge que j'utilise et ajouter des comparateurs ou des répéteurs pour que cela fonctionne. De plus, si je n'utilise pas de poussière de redstone, comment suis-je censé activer des choses comme les pistons et les lampes de redstone ?

Si j'ai besoin de poussière de redstone pour faire fonctionner mes blocs de commande, pourquoi me demande-t-on de m'en débarrasser ? Quelle est la raison logique de cette décision ?

Answer 1

Vos amis ont raison, la poussière de redstone est diabolique et doit être évitée à tout prix lors de la fabrication de blocs de commande. La poussière de redstone provoque un décalage et peut être imprévisible. Il existe un bon article de blog Il est difficile d'expliquer pourquoi, mais il suffit de dire que pratiquement tous les experts en cartographie limitent l'utilisation de la poussière de redstone à des cas très spécifiques, et qu'elle n'est jamais utilisée sur des lignes à haute fréquence.

Alors, que devriez-vous utiliser à la place ? Pour une horloge, utilisez un Horloge 20Hz . Mieux encore, commencez à utiliser la version 1.9 et utilisez des blocs de commande répétitifs. Pour allumer un appareil redstone, utilisez setblock pour placer un bloc de pierre rouge ou une torche au point d'activation. Ceci est particulièrement utile lorsque vos blocs de commandement sont éloignés de tout engin en pierre rouge (comme ils devraient l'être).

Les seules pierres rouges que vous devriez avoir dans votre dispositif de bloc de commande sont les blocs de pierres rouges (pour activer les blocs de commande), les comparateurs (pour tester la réussite d'un bloc de commande, mais même ces derniers ne sont pas nécessaires ; utilisez la fonction stats ) et, dans de très rares cas, un répéteur. Parfois aussi, un bouton ou un interrupteur, mais cela devrait être donné. Mais c'est pour la version 1.8, et dans la version 1.9, tout le jeu du bloc de commande change. La version 1.9 vous permettra de supprimer encore plus de redstone, au point que vous n'en aurez plus besoin (pas même d'un interrupteur ou d'un bouton) pour faire quelque chose d'utile. Encore une fois, vous aurez besoin d'être capable d'interfacer avec des dispositifs de redstone de temps en temps, mais comme je l'ai dit plus haut, cela devrait être fait avec quelque chose comme un setblock commandement.

En fin de compte, vous devriez faire de votre mieux pour séparer votre matériel de redstone et votre matériel de bloc de commande. Il fut un temps où ce n'était pas possible, mais c'était il y a très longtemps, lorsque le bloc de commande a été introduit pour la première fois. Les nouvelles commandes ont rendu possible la séparation des blocs de redstone et de commande, et avec les nouvelles fonctionnalités de la 1.9, cela devient encore plus facile à faire ; vous n'avez plus besoin de penser à comment construire une horloge de 20Hz, l'ordre d'exécution est trivialisé en placement de bloc, et l'exécution conditionnelle est intégrée. La poussière de redstone est très utile pour fabriquer des objets intéressants en survie, mais elle n'a pas sa place dans les blocs de commande du mode créatif.

---

Minecraft v1.13 a encore changé la donne. Désormais, vous n'avez même plus besoin de blocs de commande dans votre monde, vous pouvez utiliser des fonctions à la place et des étiquette pour qu'ils s'exécutent soit à chaque tic, soit au chargement du monde. (Il est vrai que certaines de ces fonctions étaient disponibles dans les versions précédentes, mais la version 1.13 était une mise à jour majeure des commandes, ce qui constituait une raison impérieuse d'en transférer le plus possible vers les fonctions).

Les blocs de commande seront toujours nécessaires dans certaines circonstances très étroites (l'exécution conditionnelle dans certains cas est toujours difficile en utilisant uniquement des fonctions), mais en dehors du prototypage, je recommanderais d'utiliser des fonctions au lieu de blocs de commande pour la plupart des besoins. Il y a de nombreuses raisons de le faire, mais parmi les principales raisons que je vois, il y a les suivantes :

• Réutilisation et déduplication du code
• Maintenabilité
• Facilité de lecture

Il faut cependant garder à l'esprit qu'un certain nombre de commandes ont été supprimées/remplacées dans la version 1.13, comme la commande stats mentionnée ci-dessus (la nouvelle version faisant partie de la commande execute est en fait beaucoup plus facile et intuitive maintenant). La puissance des commandes s'est considérablement accrue depuis l'introduction du bloc de commandes en 1.4, mais Redstone n'a connu que des améliorations incrémentales. La plupart des améliorations dans redstone ont été apportées par l'ajout de blocs visant à éliminer le besoin de commutateurs BUD (ces blocs étant le détecteur de lumière du jour et les blocs d'observation). À part cela, il n'y a pas grand-chose de nouveau dans redstone, alors que les commandes ont évolué presque à chaque version.

Answer 2

Voici mon point de vue sur la question, avec d'autres raisons et d'autres "meilleures pratiques".

Pourquoi ne faut-il utiliser que des blocs de commande ou des fonctions, et non pas redstone ?

• Tout d'abord, il n'est pas nécessaire d'utiliser la pierre rouge. Une fois que vous savez comment faire les choses de manière "correcte", il est généralement plus facile de tout faire comme ça.
  A titre d'exemple, écrire execute if entity @e[type=sheep] run say hi en un seul bloc de commandes est plus facile que d'utiliser un bloc de commandes avec des execute if entity @e[type=sheep] un comparateur et un autre bloc de commande avec say hi et s'assurer que le comparateur s'éteint avant d'exécuter les commandes une seconde fois.
  La méthode avec deux blocs de commande était utilisée jusqu'à la version 1.7.10 (en 2014) avec /testfor et certaines personnes considèrent encore les commandes comme un système distinct qui consiste à "vérifier quelque chose ou à faire quelque chose, mais pas les deux en une seule commande". Cela a cependant changé au fil du temps, en particulier avec la version 1.13. Jusqu'à la version 1.12.2, il restait quelques cas où l'on avait besoin de la redstone (ou du moins c'était extrêmement compliqué sans), maintenant on n'en a plus besoin.
• Préserver le contexte d'exécution et améliorer la fiabilité : Il y a longtemps, il était courant de faire des choses comme /testfor @p[c=10] pour vérifier la présence d'un joueur dans un rayon de 10 pâtés de maisons et ensuite, connecté à un comparateur, /tp @p <coords> . Le problème est que le joueur le plus proche de ce deuxième bloc de commandement peut très bien être quelqu'un d'autre. Il est également arrivé que la condition ne soit pas correctement remplie et que vous téléportiez accidentellement la mauvaise personne. Et pour être sûr de ne pas le faire, il faut saisir deux fois tous les arguments du sélecteur. La condition peut également changer pendant le délai du comparateur.
  En utilisant correctement les commandes de la version 1.13+, vous pouvez combiner la vérification et l'action comme suit : /execute as @p[distance=..10] run tp @s <coords>
  Ici, vous avez réutilisé le contexte d'exécution "agir en tant que joueur le plus proche dans un rayon de 10 pâtés de maisons" pour la fonction /tp et elle a été appliquée instantanément. _{^{(Oui, je me rends compte que cet exemple simple pourrait fonctionner sans <code>/execute</code> mais cela ne fonctionne pas pour les <strong>nombreux </strong>d'autres cas).}}
  Grâce aux fonctions, vous pouvez même conserver un contexte d'exécution pour plusieurs commandes, quoi que vous fassiez entre-temps. De cette façon, vous pouvez facilement faire un tas de choses sur la même condition ou au même endroit, même si, par exemple, ce qui a référencé cette position à l'origine a disparu depuis longtemps.
• Protection contre les manipulations : Les joueurs survivants peuvent librement interagir avec la pierre rouge, ils peuvent la casser, en placer de nouvelles (un répétiteur peut même activer des choses à travers un mur de roche), modifier les paramètres du répétiteur, etc. L'eau ou la lave peuvent également faire disparaître accidentellement vos pierres rouges, les TNT peuvent les faire exploser, etc. Même si vous placez vos blocs de commande et vos pierres rouges dans une boîte en roche, des joueurs intelligents peuvent y pénétrer en utilisant, par exemple, des portails du Néant ou des fruits chorus.
  Tout cela ne s'applique pas si vous n'utilisez que des blocs de commande. Même si vous donnez à un joueur Survival un bloc de commande avec une commande pré-écrite à l'intérieur, il ne pourra pas le poser. Minecraft a mis en place de nombreuses mesures de sécurité pour empêcher les joueurs Survival d'interagir avec les blocs de commande de quelque manière que ce soit.
  Si vous utilisez des fonctions, vous êtes encore plus en sécurité, car même les joueurs créatifs ayant accès aux commandes ne peuvent pas les modifier, seules les personnes ayant accès aux fichiers du serveur peuvent le faire.
• Partage et sauvegardes : Les blocs de structure ont facilité la copie de zones d'un monde dans un autre ou la sauvegarde de zones, mais c'est plus facile si vous n'avez pas à tenir compte de l'étage pour la redstone et de tout l'espace supplémentaire qu'elle prend. C'est aussi un effort considérable que d'intégrer une zone dans un fichier de structure. Si vous utilisez des fonctions, vous disposez d'un dossier unique ou d'un fichier ZIP que vous pouvez copier n'importe où, ce qui vous permet de créer des sauvegardes en une seconde ou de partager le fichier sur l'internet. Le destinataire peut alors simplement placer le fichier au bon endroit, (re)démarrer Minecraft ou exécuter /reload et l'installation est terminée. Si vous voulez mettre votre engin à la disposition de personnes qui n'ont pas accès aux fichiers du serveur (comme sur Realms), vous pouvez utiliser un créateur automatique à une seule commande comme celui qui est lié ici si vous avez tous vos commandements dans une seule chaîne de blocs de commandement. Cela ne fonctionne pas si redstone est impliqué.
• Récursion : Les fonctions permettent la récursivité et donc les boucles, ce qui signifie que vous pouvez exécuter instantanément autant de répétitions de commandes que vous le souhaitez. Cela est utile de bien d'autres manières que vous ne le pensez, par exemple vous pouvez faire raycasting sans entité fictive . Il est possible de le faire avec des blocs de commande, comme le montre l'exemple suivant cette vidéo par Slicedlime mais cela demande beaucoup de travail et d'espace supplémentaires.
• Laps de temps et bogues sur le serveur : https://bugs.mojang.com/browse/MC-81098 L'activation et la désactivation de Redstone dust provoque un grand nombre de blocages de mises à jour. A tel point qu'une grande zone de poussière de redstone est le moyen le plus courant de construire des "machines à lag", et ce depuis des années. En outre, les blocs de commande répétitifs, et plus encore les fonctions, sont spécialement optimisés pour le type de choses pour lesquelles ils sont utilisés, ce qui n'est pas le cas de la redstone.
  Il y a également plusieurs bugs avec redstone. Ceux-ci ne devraient pas avoir beaucoup d'importance si vous n'utilisez qu'un seul comparateur ou quelques répétiteurs, mais ils peuvent en avoir. En particulier, l'ordre de mise à jour à peine prévisible de redstone peut causer des problèmes.
• Édition plus facile : Dans un fichier de fonction, vous voyez toutes les commandes (ou un grand nombre d'entre elles) d'un seul coup d'œil. Vous n'avez donc pas besoin d'ouvrir et de fermer l'interface graphique de dizaines de blocs de commandes et de vous déplacer dans le monde pour finalement trouver ce que vous cherchez. Vous pouvez également utiliser toutes les fonctionnalités d'un éditeur de texte, comme rechercher+remplacer, annuler, etc.
  Si vous souhaitez insérer une autre commande entre deux dans une chaîne de blocs de commande, le plus simple est de déterminer les coordonnées du premier et du dernier bloc à déplacer et la nouvelle position, en utilisant la commande /clone … replace move avec ceux-ci (une mauvaise manipulation peut écraser des éléments que vous souhaitiez conserver), placez un nouveau bloc de commande entre les deux et ouvrez son interface graphique. Dans une fonction, il suffit d'appuyer sur la touche Entrée.
• Chargement de morceaux : Si vous voulez que les commandes soient toujours exécutées, vous devez placer les blocs de commande dans les chunks de spawn ou dans une zone que vous gardez chargée en utilisant /forceload . La première option prend de l'espace à l'endroit le plus important du monde, la seconde cause du lag supplémentaire pour garder une zone chargée dont vous ne vous souciez pas de toute façon. Si vous utilisez également de la redstone avec vos blocs de commande, vous pouvez rencontrer des problèmes avec cette redstone qui réagit différemment lorsque les morceaux se chargent dans un ordre différent, avec un timing différent, etc. C'est surtout un problème dans les versions 1.14 et supérieures.

Comment faire mieux ?

• Si vous pouvez utiliser des fonctions, vous devriez le faire. La barrière à l'entrée est certes plus élevée pour les fonctions, car il faut d'abord créer un datapack. Ma solution est de toujours partir d'un squelette de datapack que j'ai créé il y a longtemps et que j'ai depuis copié très souvent comme point de départ pour mes datapacks. Vous pouvez télécharger ici un tel datapack factice : https://drive.google.com/file/d/15Gzp4dqyCfbQ_iGObfwKApxft6TLX8Zt
  Il suffit de placer ce datapack dans saves/<world>/datapacks dans votre dossier Minecraft et ouvrez ce monde. Maintenant, le serveur envoie "empty" à chaque tick, parce qu'il y a une balise de fonction qui exécute une fonction à chaque tick, dont le contenu est seulement " say empty ". Vous pouvez supprimer la fonction de cette balise ou en ajouter d'autres, vous pouvez modifier la fonction, en créer de nouvelles, etc. La structure des dossiers est déjà présente, ainsi qu'un fichier pack.mcmeta fichier.
• Si vous ne pouvez pas utiliser de fonctions, vous devez utiliser un bloc de commande répétitif, suivi de blocs de commande en chaîne. Leur action est très similaire à celle d'une fonction. Si vous utilisez plusieurs chaînes répétitives indépendantes, l'ordre dans lequel elles sont exécutées les unes par rapport aux autres peut être imprévisible.
  Bien sûr, vous pouvez également utiliser un bloc de commande d'impulsion avec un bouton, il n'y a rien de mal à utiliser un tel composant redstone si vous avez l'intention de l'utiliser manuellement de toute façon, c'est juste l'utilisation des anciennes "horloges de remplissage" ou des horloges redstone normales, des comparateurs au lieu des blocs de commande conditionnels et ainsi de suite qui est découragée.

FAQ

Comment utiliser des blocs de commande conditionnels dans une fonction ?

Vous pouvez utiliser /execute store success pour vérifier si une commande a réussi, comme ceci :

/execute store success score #dummy scoreboard_name run …

Cette commande enregistre le nombre de succès de la commande après " run "dans le tableau d'affichage nommé " scoreboard_name "pour le faux joueur " #dummy ". Ce faux nom de joueur commence par un dièse, de sorte qu'il n'apparaîtra pas dans la barre latérale lorsque vous définirez un tableau d'affichage à cet endroit.

Vous pouvez ensuite exécuter une commande en fonction de cette condition :

/execute if score #dummy scoreboard_name matches 1.. run …

Cette commande ne sera exécutée que si le score est égal ou supérieur à 1, donc seulement si la première commande a réussi. La raison pour laquelle il faut également vérifier si les chiffres sont plus élevés est que /execute store success peut, dans certains cas, renvoyer plus de 1. Il semble que ce soit actuellement le cas. cassé Mais une fois ce problème résolu, il est bon d'être déjà prêt.

Comment retarder ou ralentir les commandes en boucle sans répétiteurs ?

J'ai déjà rédigé une autre question-réponse à ce sujet : Comment retarder ou ralentir les commandes ?

La partie la plus simple de cette réponse est, si vous avez accès aux fonctions, d'utiliser /schedule ( archives ).

Plus d'informations

Slicedlime a d'excellentes commandes et une série de tutoriels de création de cartes, dont la plupart sont toujours d'actualité, même plus de 5 ans plus tard :
https://www.youtube.com/playlist?list=PL4ZS2guXqa_g1NI8t0djmrRtOaZ6brg46
https://www.youtube.com/playlist?list=PL4ZS2guXqa_j854EGAO3NSqiaaxMHQdSD
https://www.youtube.com/playlist?list=PL4ZS2guXqa_j1z9i74V8KavMLzG1yTxFq

Bien sûr, la syntaxe des commandes a beaucoup changé dans la version 1.13, vous devez donc faire attention aux principes de ces tutoriels, et non aux commandes exactes.