[MàJ] Minecraft 1.13: Les commandes, /execute, sélecteurs, etc.

La version 1.13 sera définitivement la version qui casse tous, en particulier toutes les commandes. Mais c'est une décision assumée par Mojang, et Dinnerbone explique très bien ce choix: La version Minecraft 1.13 sera la version ou les ID seront supprimer. Dès lors de nombreuses commandes seront, de fait, cassé (suppression des datavalue, donc changement dans les paramètres). Donc quoi qu'il arrive la 1.13 devait casser de nombreuses commandes. C'est pourquoi Dinnerbone a choisit d'en profiter pour revoir toutes les commandes et les améliorer: Oui ça va tout casser, mais normalement plus rien ne sera cassé dans les futures versions de Minecraft ! Ça sera un moment difficile pour les mapmakers, mais normalement c'est a dernière fois qu'il devront tout refaire.


Si ce n'est pas déjà je vous invite a voir (ou revoir) nos précédents articles concernant les changements apportés aux commandes:

• Minecraft 1.13: Commandes, sélecteurs, data pack, etc.
• Minecraft 1.13: Nouvelles syntaxes des commandes
• Minecraft 1.13: L'assistant de commandes

Suppression des DataValues, la suite
Les DataValues étant désormais supprimé, Dinnerbone a continué de modifier les commandes prenant en paramètre des DataValues ou des tag NBT:

/clear
Ancienne syntaxe:
/clear [<target>] [<item>] [<data>] [<count>] [<nbt>]
Suppression des paramètres data et nbt:
/clear [<target>] [<item>] [<count>]

/give
Ancienne syntaxe:
/give <players> <item> [<count>] [<data>] [<nbt>]
Suppression des DataValues, la suite
/give <players> <item> [<count>]

/replaceitem
Ancienne syntaxe:
/replaceitem block <pos> <slot> <item> [<count>] [<data>] [<nbt>]
Suppression des DataValues, la suite
/replaceitem block <pos> <slot> <item> [<count>]

Ancienne syntaxe:
/replaceitem entity <target> <slot> <item> [<count>] [<data>] [<nbt>]
Suppression des DataValues, la suite
/replaceitem entity <target> <slot> <item> [<count>]



Suppression de /toggledownfall
La commande /toggledownfall n'a plus vraiment d’intérêt sachant qu'il existe depuis un moment maintenant la commande /weather qui fait la même chose (en mieux).



Fusion des commandes /tp et /teleport
Dans la version 1.12 /tp et /teleport sont 2 commandes distinct. Certes elles ont un fonctionnement similaires, mais la syntaxe est légèrement différent, ainsi que leur éxécution.
Je ne peux que vous invité a lire les fiches de ces 2 commandes pour mieux comprendre leur fonctionnement respectif:

• Fiche de /tp
• Fiche de /teleport

Prenons l'exemple suivant (pris sur les fiches ci-dessus), que fait cette commande ?
/tp Notch ~ ~10 ~
/teleport Notch ~ ~10 ~
Les 2 commandes sont correcte, elles fonctionneront, mais ne feront pas la même chose.

/tp Notch ~ ~10 ~ ==> Téléporte le joueur 'Notch' 10 blocs plus haut.
/teleport Notch ~ ~10 ~ ==> Téléporte le joueur 'Notch' 10 blocs au dessus de la personne qui tape la commande.

Autrement dit, le tilde de la commande /tp est relatif à l'entité de destination, alors que pour la commande /teleport (comme dans toutes les autres commandes du jeu), le tilde est relatif au l'entité qui tape la commande.
C'est pourquoi Dinnerbone a supprimer la commande /tp, elle est remplacé par la commande /teleport (le /tp fonctionnera toujours, mais il sera un simple alias de /teleport).

Pour avoir a nouveau l'ancien comportement il faudra utiliser la commande /execute:
/execute as Notch then teleport @s ~ ~10 ~
Certe la commande est beaucoup plus longue que l'ancienne commande /tp, mais selon Dinnerbone celle-ci est beaucoup plus logique, et donc plus simple a comprendre.



Les sélecteurs:
Les sélecteurs ont déjà était grandement améliorés (ajout des paramètres multiples, des sélection par tag nbt, etc.). Mais ce n'est pas fini, Dinnerbone a encore annoncé de nouveau changement.

• Les intervales:

Le premier est une nouvelle révolution pour les sélecteurs, une nouvelle syntaxe permettant d'indiquer des intervalles.
Si on souhaite sélectionner tous les joueurs avec un niveau d'XP entre 5 et 10 ?
Avant il fallait faire :
@p[lm=5,l=10]

Désormais un seul paramètre permet de le faire simplement:
@p[level=5..10]

Si on ne souhaite pas de min ou de max, c'est le même principe:
@p[level=..10]
@p[level=5..]

Tous les paramètres avec un "min" ou "max" sont concerné, (level, scoreboard, rotations, etc.).

• "limit":

Le paramètre de sélecteur "c" a été renommé en "limit". Ce paramètre indique le nombre d'entité a sélectionner.
Mais contrairement à "c", "limit" n'accepte pas de valeur négative. Une valeur négative permettait de sélectionner les entité les plus éloigné. Pour cela un nouveau paramètre a été créer: "sort".
"sort" peut prendre les valeurs suivantes:
- "sort=nearest": sélectionne les entités les plus proche (valeur par défaut pour tous les sélecteurs sauf @r)
- "sort=furthest": sélectionne les entités les plus éloigné (l'équivalent de la valeur négative de "c")
- "sort=random": sélectionne les entités par ordre aléatoire (valeur par défaut pour le sélecteur @r)
- "sort=arbitrary": sélectionne les entités sans les classer, c'est l'option la plus rapide mais on ne doit l'utiliser que si l'ordre des entités n'a aucune importance dans la commande.

• Paramètres renommés:

De nombreux paramètres de sélecteurs ont été renommés, en générale par un nom plus long mais plus explicite:
- "m" devient "gamemode"
- "l" et "lm" deviennent "level"
- "r" et "rm" deviennent "distance"
- "rx" et "rxm" deviennent "x_rotation"
- "ry" et "rym" deviennent "y_rotation"
- "c" devient "limit"



Retour de la commande /execute
Dans notre précédente news nous vous annoncions la suppression de la commande /execute, remplacé par les commandes /as, /at, /offset et /detect. Retour en arrière pour Dinnerbone, la commande /execute restera dans Minecraft 1.13, mais sa syntaxe sera totalement différente de ce que nous connaissons actuellement.

La cause de ce revirement de situation: la suppression des commandes /testfor, /testforblock et /testforblocks. Dinnerbone pense qu'il serait plus simple d'inclure ces commandes de test dans la commande /execute, mais la syntaxe actuelle ne permettait pas cela. Il a donc ajouter 2 nouveaux paramètres à /execute: "if" et "unless".
Ainsi, la commande /as devient:
/execute as ...
La commande /at devient:
/execute at <entité> ...
La commande /offset a été remplacé par:
/execute at <x> <y> <z>
Et /detect est remplacé par la condition if.

Ainsi nous devrions avoir les syntaxes suivantes:

• /execute as <entity> <command> runs <command> ==> Exécute en tant que l'entité, mais sans prendre sa position
• /execute at <entity> <command> runs <command> ==> Utilise la position de l'entité pour exécuter la commande, mais sans changé l'entité source
• /execute at <x y z> <command> runs <command> ==> Exécute la commande en utilisant la position indiqué
• /execute (if|unless) block <x y z> <block> <command> ==> Exécute la commande if (ou l'inverse) le bloc à la position indiqué <x y z> correspond au bloc indiqué <block> (équivalent de la commande /testforblock)
• /execute (if|unless) blocks <begin> <end> <destination> (all|masked) <command> ==> Exécute la commande si (or l'inverse) la region entre <start> et <end> est identiqué à la destination <destination> (équivalent de la commande /testforblocks)
• /execute (if|unless) entity <entity> <command> ==> Exécute la commande <command> si (ou l'inverse) l'entité <entity> existe (ou si le sélecteur retourne une ou plusieurs entités) (équivalent de la commande /testfor )

Mais ce nouveau système alourdit la syntaxe, par exemple:
L'ancienne commande:
/execute @e ~ ~ ~ detect ~ ~ ~ stone 0 say Stone!
devient:
/execute as @e execute at @s execute if block ~ ~ ~ stone say Stone!
3 fois le mot "execute" dans la même commande, ça fait beaucoup.

Des voix ont commencé à se lever contre ce changement, et Dinnerbone à proposer un nouveau changement:
"as", "at", "if bloc", "if blocks" et "if entity" ne seront toujours pas des commandes, mais le mot "execute" ne serait plus obligatoire. En d'autre terme, la commande execute serait composé de plusieurs fragment commençant par "as", "at", etc. On garde donc le fonctionnement du dernière exemple, mais sans avoir a répéter le mot "execute" a chaque fois. Voici une démonstration en images:
Voici quelques exemples avec cette nouvelle syntaxe:

• execute at @a then summon pig ==> Spawn un cochon pour chaque joueur
• execute at @a if block ~ ~-1 ~ grass then summon pig ==> Spawn un cochon pour chaque joueur qui se trouve sur un bloc de pelouse
• execute as @a at @s unless entity @e[distance=..5,type=creeper] then effect give @s regeneration 5 ==> Donne un effet de regénération a tous les joueurs, à moins qu'un creeper se trouve a proximité

Maintenant que la commande permet de gérer les conditions if et unless, cette fonctionnalité a donc été supprimé de la commande /function, ainsi l'ancienne commande:
/function foo if @e[tag=bar]
Devra maintenant s'écrire:
/execute if entity @e[tag=bar] function foo
Cela permettra la prise en charge de conditions plus élaborées, non plus limité sur les entités, mais aussi sur les blocs.



La suppression des DataValues
Dans notre précédente news Dinnerbone avait annoncé la suppression des DataValues (aussi connue comme étant la valeur de "Dommage" pour les armes et outils), mais il était resté assez vague sur le système permettant de les remplacer. Nous en savons maintenant un peu plus:

Concernant les blocs qui étaient différenciés par leur DataValue (laine de couleur, type de roche, etc.) ils auront maintenant leur propre ID. Par exemple les différentes couleurs de terracotta s'appelleront désormais: "minecraft:blue_terracotta", "minecraft:red_terracotta", etc. (Notez au passage que le nom changera, ce n'est plus "hardened_clay" mais "terracotta" en 1.13).

Pour les armes, outils et tous les items qui s'use, c'est plus délicat puisqu'il s'agit toujours du même objet. Dinnerbone envisage l'utilisation des tags NBT pour stoquer la valeur d'usure:
/give @p minecraft:diamond_sword{Unbreakable:1,Damage:1}



Suppression des gamerules personnalisées:
Lorsqu'on utilise la commande /gamerule avec un nom de gamerule qui n'existe pas, la commande créer alors une "variable" avec ce nom, et lui affecte la valeur de notre choix: ce sont les gamerules personnalisées. Mais ce système pose plus de problème qu'il n'en résout:

• Les valeurs ainsi affectées sont très difficile a récupérer dans d'autres commandes
• Ce système est sujet au faute de frappe: il est facile de se tromper sur un nom de gamerule, et aucune erreur n'apparait.
• Il est impossible de faire de la gestion d'erreur dessus, puisque tous les noms sont valides
• Et surtout, le système de fonctions et de scoreboard permettent de faire la même chose, mais de manière plus sur.

La commande /gamerule existera toujours, mais seules les valeurs prises en charge par le jeu seront autorisées, il ne sera plus possible de créer des variables personnalisées.



L'assistant de commande:
Ce n'est pas une nouveauté, mais voici une nouvelle animation présenté l'assistant de commande, et comment les couleurs peuvent aide a s'y retrouver parmis tous les arguments de la commande !
Un autre exemple avec la sélection automatique par l'assistant des sous-commandes (commandes avec plusieurs syntaxes possible):