[Note du Rédacteur en Chef : Cet article a été exceptionnellement écrit par Oromis, un modérateur de notre forum qui est bien plus à l’aise avec les commande que moi ou n’importe quel rédacteur. On le remercie ! Je précise également que cet article sera régulièrement mis à jour en fonction des ajouts et changements que nous apporteront les prochaines snapshots. Bonne lecture !]
Les premières snapshots de la 1.13 sont maintenant sorties et avec elles arrive le rework d’une majeure partie des commandes du jeu comme annoncé quelques mois plus tôt par Dinnerbone. Cette grosse mise à jour a pour conséquence de modifier la syntaxe de la plupart des commandes, voire la suppression ou l’ajout pur et simple de certaines, au désespoir des Map Makers, devant donc revoir entièrement leurs maps pour passer à la version suivante.
Peut-être vous demandez-vous pourquoi changer si soudainement ce système de commandes, pourtant bien fonctionnel et utilisé depuis pas mal de temps. À cela, nous pouvons y apporter plusieurs réponses.
Tout d’abord la refonte du système d’ID : en effet, le jeu stockait auparavant les blocs et les items sur des nombres. Ainsi, les nombres inférieurs à 256 représentaient les blocs et ceux supérieurs, les items. Nous étions donc limités à 256 blocs dans le jeu. Ce système d’ID, et par extension celui des data values (solution partielle au problème ajoutant la possibilité d’avoir 16 sous-blocs sur un ID, permettant entre autres de stocker les diverses laines par exemple) étant donc maintenant obsolète, Mojang se doit de modifier les commandes concernées afin de les adapter à ce changement, concernant déjà une grande partie des commandes (give, setblock, fill, testforblock, les NBTs…).
De plus, certaines commandes actuelles manquent cruellement de logique. Nous pouvons noter par exemple les commandes toggledownfall et weather qui ont, à quelques choses près, la même utilité ; le manque d’explicité de la commande gamemode (Pour laquelle un néophyte ne peut pas voir au premier coup d’œil que 0 correspond à « survival ») ou encore se demander pourquoi les teams et les tags se trouvent tous deux dans la commande scoreboard alors qu’ils n’y sont pas nécessairement liés.
Mojang a par conséquent décidé de faire un peu de ménage dans tout cela et d’en profiter pour uniformiser le tout. Je vous propose donc de mettre un peu de lumière sur toutes ces modifications en commençant par les modifications des commandes en elles-mêmes.
Avant cela, je tiens à rappeler la syntaxe des paramètres :
[<type>] signifie que le paramètre est facultatif.<type> signifie que le paramètre est obligatoire.
(type1|type2) signifie soit l’un, soit l’autre.
[type1|type2] signifie soit l’un, soit l’autre (facultatif).
/advancement :
La commande /advancement test a été supprimée et remplacée par un argument en sélecteur (nous y reviendrons).
/clear :
Changement de syntaxe :
/clear [<cible>] [<item>] [<data>] [<nombre>] [<nbt>]
devient :
/clear [<cible>] [<item>] [<nombre>]
/gamemode et /defaultgamemode :
Les commandes ne peuvent plus prendre en paramètres le numéro du gamemode (0 pour survival) ou son alias (sp pour spectateur), le nom doit donc être rentré entièrement.
Exemples :
/gamemode 1 devient /gamemode creative
/defaultgamemode s devient /defaultgamemode survival
/difficulty :
Cette commande suit la même logique que la précédente.
Le fait d’utiliser le /difficulty sans paramètre permet d’afficher la difficulté.
Exemples :
/difficulty 1 devient /difficulty easy
/difficulty p devient /difficulty peaceful
/effect :
Le /effect est maintenant divisé en deux sous-commandes :
/effect give < cible> <effet>
/effect clear < cible> [<effet>]
Le fait de donner un effet de potion à un mob ne pouvant être affecté par l’effet en question échouera (tel que l’EnderDragon).
Donner un effet de potion inférieur à un mob ayant le niveau supérieur de ce dernier échouera aussi.
/execute :
Voici l’une des commandes les plus modifiées, elle se voit divisée en plusieurs sous-commandes :
/execute as <sélecteur> <commande> – Exécute la commande en utilisant l’identité de l’entité sans en reprendre sa position.
/execute at <sélecteur> <commande> – Exécute la commande à partir de la position de l’entité sans en reprendre l’identité.
/execute offset <x y z> <commande> – Exécute une commande aux coordonnées.
/execute align <axe(s)> <commande> – Exécute la commande après avoir aligné la position actuelle à l’entier inférieur (exemple plus bas).
/execute (if|unless) block <x y z> <bloc> <commande> – Exécute une commande si (if) ou sauf si (unless) un bloc se trouve aux coordonnées. Cette commande remplace le /testforblock qui est supprimé.
/execute (if|unless) blocks <début> <fin> <destination> (all|masked) <commande> – Exécute une commande si (if) ou sauf si (unless) la zone entre début et fin est équivalente à destination (où début, fin et destination sont des coordonnées). Cette commande remplace le /testforblocks qui est supprimé.
/execute (if|unless) entity <sélecteur> <commande> – Exécute une commande si (if) ou sauf si (unless) l’entité existe au moins une fois.
/execute (if|unless) score <cible> <cibleObjectif> (<|<=|=|=>|>) <source> <sourceObjectif> <commande> – Exécute la commande si (if) ou sauf si (unless) le score de la cible est relatif au score source par rapport au critère choisi.
/execute store (result|success) score <sélecteur> <objectif> <commande> – Est le remplaçant de la commande /stat entity.
/execute store (result|success) block <pos> <chemin d’accès> (byte|double|float|int|long|short) <commande> – Permet de sauvegarder un score sur l’un des NBTs existant d’un bloc. Il faut préciser le type de la valeur (voir exemple).
/execute store (result|success) entity <cible> <chemin d’accès> (byte|double|float|int|long|short) <commande> – De même mais avec une entité.
« result » remplace les paramètres AffectedEntities, AffectedBlocks, AffectedItems et QueryResult alors que « success » remplace SuccessCount et compte le nombre de succès d’exécution.
Le stockage ne se fera que lorsque tout le execute sera exécuté, vous pouvez donc ajouter un if à la suite pour ajouter des conditions.
Le paramètre <chemin d’accès> s’écrit sous la forme « parent.enfant ».
Voici quelques exemples :
Il faut savoir que toutes ces sous-commandes peuvent bien entendu se succéder, mais il est important de savoir que la dernière commande mise dans un execute doit être précédé du mot-clé « run ».
Exemple :
/execute offset 1.1 5.8 52.5 align yz run summon slime ~ ~ ~
Fera apparaître un Slime en 1.1, 5.0, 52.0 grâce à la sous-commande align.
/execute store result score fake Test run data get entity @e[type=slime,limit=1] Pos[0]
Permet de récupérer les coordonnées en X (Pos[0]) et de les enregistrer dans le faux joueur « fake » du scoreboard Test.
/execute as @e[type=pig] at @s store success entity @s Saddle byte 1 if entity @p[distance=..5]
Exécutera sur chaque cochon un stockage du chiffre 1 sous forme de bytes dans le NBTtag « Saddle » de cette même entité seulement si le joueur le plus proche se trouve à plus de 5 blocs de distance.
Le /execute if peut être utilisé seul de façon à renvoyer le nombre d’entités détectées par le sélecteur à l’aide du comparateur. Par exemple, /execute if entity @a retournera sous forme de courant de redstone le nombre de joueurs présents sur la map.
/experience :
Nouvelle commande remplaçant le /xp (devenu alias de cette nouvelle commande).
Elle est divisée en trois sous-commandes :
/experience add <joueur> <montant> [points|level]
Ajoute le montant au joueur précisé, soit en points, soit en niveaux (par défaut, en points).
/experience set <joueur> <montant> [points|level]
Définit le montant en points ou en niveaux du joueur précisé (par défaut, en points).
/experience query <joueur> (points|level)
Retourne le nombre de points ou de niveaux que possède le joueur.
/fill :
Il ne s’agit ici que de changements de syntaxe :
/fill <x y z> <xt yt zt> <block> <data> replace [<bloc de remplacement>] [<data de remplacement>]
est maintenant :
/fill <x y z> <xt yt zt> <block> replace [<bloc>]
/fill <x y z> <xt yt zt> <block> [<data>] [destroy|hollow|keep|outline|replace] [<nbt>]
est maintenant :
/fill <x y z> <xt yt zt> <block> [destroy|hollow|keep|outline|replace]
/function :
La commande n’accepte plus if et unless car se trouvant maintenant dans un execute.
/gamerule :
N’accepte plus les règles personnalisées.
/give :
Changement de la syntaxe :
/give <joueur> <item> [<count>]
/kill :
Préciser l’entité à tuer est maintenant obligatoire.
/locate :
La commande retourne 64 pour l’axe Y à la place de ‘?’
Le résultat peut être récupéré dans un scoreboard à l’aide du scoreboard store sous forme de distance.
/particle :
L’ancienne syntaxe :
/particle <particule> <pos> <dX dY dZ> <vitesse> [quantité] [normal|force] [joueur/mob/entité] [BlocID] [DataID]
Se voit remplacée par :
/particle <particule> <pos> <dX dY dZ> <vitesse> <quantité> [normal|force] [joueur/mob/entité]
Nous pouvons constater la disparition du BlockID et du DataID, ces deux paramètres sont maintenant directement intégrés à la particule lorsque cette dernière est « blockcrack » ou « iconcrack » (permettant les particules de blocs).
Par exemple :
/particle blockcrack stone[variant=smooth_granite] ~ ~ ~ 0 0 0 0 1
Permettra de faire des particules de granite poli (nous reparlerons plus bas de la nouvelle syntaxe des noms d’items/blocs).
Il y a aussi quelques changements dans la nomenclature des particules : tous les noms sont maintenant en minuscule.
/replaceitem :
La syntaxe de la commande a changé :
/replaceitem block <pos> <slot> <item> [<nombre>] [<data>] [<nbt>]
Devient :
/replaceitem block <pos> <slot> <item> [<nombre>]
De même avec entity :
/replaceitem entity < cible > <slot> <item> [<nombre>] [<data>] [<nbt>]
Est maintenant :
/replaceitem entity <cible> <slot> <item> [<nombre>]
Le paramètre slot, avant noté slot.hotbar.1 voit disparaître le « slot. » et est donc maintenant remplacé par hotbar.1.
/scoreboard :
Les paramètres « datatag » de la commande disparaissent.
La commande est fractionnée en plusieurs commandes. Ainsi le /scoreboard teams devient /team (et garde la même syntaxe) et le /scoreboard players tag devient /tag (et garde la même syntaxe).
Le /scoreboard players test est supprimé au profit du /execute (if|unless) score, des sélecteurs et de la nouvelle sous-commande :
/scoreboard players get <cible> <objectif> – permet d’obtenir le score d’une entité. Elle peut bien sûr être additionnée au /execute afin d’affecter cette valeur à une autre entité, par exemple :
/execute store result score Test2 Obj run scoreboard players get Test Obj
Affectera le score de l’objectif Obj du joueur Test au score de l’objectif Obj du joueur Test2.
/setblock :
L’ancienne syntaxe :
/setblock <pos> <bloc> [<data>] [<mode>] [<nbt>]
Se voit remplacée par :
/setblock <pos> <bloc> [<mode>]
/stats, /testfor, /testforblock, /testforblocks, /entitydata et /blockdata :
Supprimés au profit du /execute et du /data.
/stopsound :
L’astérisque ‘*’ peut maintenant être utilisé au paramètre « source » afin de stopper tous les sons avec un certain nom joués.
/toggledownfall :
Supprimé au profit de la commande /weather.
/tp et /teleport :
/tp devient un alias du /teleport (même commande donc).
Les coordonnées sont maintenant relatives à l’exécutant de la commande.
Il est possible de rendre le tp relatif à l’entité avec une imbrication de /execute, exemple :
/execute as @e[type=slime] at @s run tp @s ~ ~5 ~
Ici, nous faisons exécuter à tous les slimes (as), à partir des coordonnées de chacun (at) un tp d’eux-mêmes 5 blocs au-dessus.
/weather :
Si le paramètre « temps » n’est pas spécifié, il sera par défaut à 5 minutes (aléatoire auparavant).
/trigger :
Faire /trigger <objectif> est maintenant un raccourci de la commande /trigger <objectif> add 1.
/data :
Il s’agit d’une commande permettant d’obtenir, de définir ou de retirer un nbt tag d’un bloc ou d’une entité.
Elle est divisée en plusieurs sous-commandes :
/data get block <pos> [<chemin d’accès>] [<échelle>] va retourner la valeur du chemin d’accès du bloc se trouvant aux coordonnées précisées.
Le paramètre <chemin d’accès> s’écrit sous la forme « parent.enfant ».
Voici quelques exemples :
Si le paramètre n’est pas défini, alors la liste de tous les NBTs de l’entité s’affiche dans le chat.
Le paramètre « échelle » permet de définir une échelle. Ainsi, la valeur retournée sera multipliée par l’échelle. Ceci est particulièrement pratique lorsque l’on souhaite obtenir une valeur flottante (à virgule) de manière précise. De cette façon, si l’on récupère la valeur en X (Pos[0]) avec une échelle de 10, et que nous nous situons en X = 256.12, alors nous aurons dans le scoreboard 2561.
/data get entity <cible> [<chemin d’accès>] [<échelle>]
De même mais avec une entité :
/data merge <bloc> <pos> <nbt>
Fait la même chose que le blockdata.
/data merge <cible> <nbt>
Fait la même chose que l’entitydata.
Par exemple :
/data merge entity @e[type=zombie,limit=1,sort=nearest] {HandItems:[{id:”minecraft:slime_ball”,Count:12b}]}
Permet de mettre 12 slime balls dans la main du Zombie le plus proche.
/data remove block <pos> <chemin d’accès>
Permet de supprimer le nbt précisé d’un bloc.
/data remove entity <cible> <chemin d’accès>
De même mais avec une entité.
Par exemple :
/data remove block 17 45 34 Items
Permet de vider un coffre de son contenu.
À noter que la sous-commande data get entity fonctionne avec les joueurs, vous pouvez donc récupérer les NBTs d’un joueur (en y ajoutant un execute store), mais ni les modifier, ni les supprimer.
Il existe une dernière commande qui va sûrement être ajoutée lors de la 1.13, il s’agit du /modifyitem remplaçant le /enchant et permettant plus facilement de personnaliser un item directement dans l’inventaire d’un joueur ou d’un coffre. Mais nous n’en parlerons pas ici car cette commande est encore sujette à des changements et n’est pas encore sortie sur les snapshots actuelles. Néanmoins, voici un lien pour les éventuels intéressés par cette commande.
Nous avons maintenant fait le tour des modifications sur les commandes, mais ces dernières ne sont pas les seules affectées par la 1.13. En effet, vous avez sans doute pu constater la disparition de tous les paramètres « nbt » et « data » des commandes. Il existe donc un nouveau moyen d’accéder à ces paramètres à partir du nom du bloc ou de l’item.
Pour les blocs, il faut d’abord différencier deux choses :
Voici donc plusieurs exemples :
Comme vous pouvez donc le constater, ces paramètres sont facultatifs tout comme le préfixe « minecraft : » l’est, vous pouvez toujours mettre le bloc seul.
Les items, eux, ne possèdent que les NBTs, mais la syntaxe reste la même :
Slime{display :{Name :”Boing boing”}}
Voici trois exemples avec le /give :
Pour se donner une épée en diamant sharpness I :
/ give @s diamond_sword{ench:[{id:16,lvl:1}]} 1
Quant à l’andésite ou autres blocs étant auparavant des data values, ils ont chacun leur id propre :
/give @s andesite
/give @s red_wool
(Pas encore fonctionnel dans les snapshots actuelles)
Une autre modification importante que vous avez sans doute pu constater est la modification d’une grande partie des arguments (paramètres mis dans un sélecteur). En effet, ceux-ci ont été renommés afin d’être plus compréhensibles, et de nouveaux ont été ajoutés. Les arguments prennent maintenant un type d’entrée précis. Ainsi « x=patate » causera une erreur lors de l’écriture de ce paramètre, pour la simple raison que le paramètre x prend un nombre pour valeur.
Les paramètres n’ayant plus de minimum et de maximum, une nouvelle syntaxe a été créée pour borner des valeurs :
level = 5 – précise que le joueur doit avoir 5 niveaux précisément.
level = 5..10 – précise que le joueur doit avoir entre 5 (inclus) et 10 (inclus) niveaux.
level = ..5 – précise que le joueur doit avoir 5 niveaux ou moins.
level = 5.. – précise que le joueur doit avoir 5 niveaux ou plus.
Les paramètres x, y, z, distance, x_rotation et y_rotation sont maintenant des doubles (nombres à virgule) et non plus des entiers. Ainsi, x = 15.3 est correct.
Le paramètre « limit » ne prend plus en compte les nombres négatifs (permettant de préciser si l’on prenait le(s) plus proche(s) ou le(s) plus loin(s) auparavant).
Ajout de l’argument « sort » permettant de définir la façon dont les entités sont choisies. Il prend pour valeur :
Il est maintenant possible de préciser plusieurs fois le même argument, par exemple @a[tag=test,tag=test2] prend tous les joueurs ayant les tags test ET test2.
De même pour le type : @e[type= !slime,type= !zombie] prendra toutes les entités n’étant ni un slime, ni un zombie. Par contre @e[type=slime,type=zombie] ne fonctionnera pas car aucune entité est à la fois un slime ET un zombie.
Il en est de même pour les scoreboards dont la syntaxe a totalement changé. Ainsi, score_OBJ_min et score_OBJ sont remplacés par scores={OBJ1,OBJ2}.
On peut donc tester deux objectifs de cette façon : @a[scores={Test=15,Test2=..5}] où les joueurs pris seront ceux ayant un score Test à 15 et un score Test2 à 2 ou moins.
Les avancements suivent la même logique que les scoreboards :
@a[advancements={story/mine_diamond=true,story/enchant_item=false}]
Ainsi, les joueurs sélectionnés seront ceux qui ont l’advancement « Diamonds! » mais qui n’ont toujours pas enchanté un item. Les paramètres ne peuvent donc prendre que deux valeurs, true (advancement réalisé) et false (non réalisé). Pour préciser un advancement personnalisé, il est nécessaire de préciser le namespace (emplacement personnalisé où se trouve les advancements) avant le nom de l’advancement en question de cette façon-ci : custom:Test.
Il est aussi possible de tester si l’un des critères de l’advancement est réalisé. Cela ne concerne que les advancements requérant plusieurs actions afin d’être obtenus (comme tuer une fois chaque mob hostile du jeu).
Par exemple @a[advancements={adventure/adventuring_time={swampland=true}}] permettra de ne sélectionner que les joueurs ayant accompli le critère « Visiter un marais » de l’advancement « Adventuring Time » (visiter tous les biomes).
Une dernière chose à savoir : les noms d’entités sont maintenant sensibles à la casse, ainsi, marquer « Slime » ne fonctionnera plus, il faudra obligatoirement que le nom paraisse en minuscules.
Voici ce qu’il en est pour toutes les modifications directement liées à la syntaxe des commandes.
Il y a toutefois deux autres ajouts qu’il est important de mentionner. Tout d’abord, les modifications liées à la frappe de commandes dans le chat. La première chose que nous pouvons constater est l’amélioration de l’auto-complétion du jeu. En effet, lorsque vous commencez à taper votre commande, une liste apparaît, vous montrant la syntaxe de cette dernière :
Nous pouvons aussi voir que lorsque j’ai commencé à écrire le mot « player », le jeu me propose directement en gris la suite du mot, une simple tabulation permet ainsi d’auto-compléter ce dernier.
Autre chose que l’on peut remarquer est la coloration de la commande dans le chat. En effet, la 1.13 ajoute la coloration syntaxique sur nos commandes (seulement dans le chat), permettant ainsi de relire plus facilement cette dernière, mais aussi de repérer les erreurs faites, colorées la plupart du temps en rouge :
Et même parfois directement signalées par le jeu avant même de valider cette dernière :
Ce parser (analyseur syntaxique, et détecteur d’éventuelles erreurs) permet donc d’éviter une majeure partie des erreurs que l’on faisait avant, et signale même les problèmes JSON avant exécution de la commande ou encore les erreurs de type dans un sélecteur (x=slime). De plus, la coloration syntaxique permet de rendre les NBTs d’une entité bien plus visible, et on prend ainsi moins de temps à trouver une information voulue :
Le dernier gros ajout technique de la 1.13 est l’arrivée tant attendue des DataPacks.
Pour ceux que ne savent pas ce que c’est, il s’agit d’un dossier ou d’une archive (de la même façon que les ResourcePacks) regroupant les functions, les loot tables, les structures, les advancements et les recipes (crafts personnalisés). Les DataPacks s’installent dans le dossier datapacks de la map. L’avantage de ce dossier est qu’il permet de regrouper toutes ces fonctionnalités en un seul endroit, facilitant ainsi leur distribution. En effet, avant, les structures par exemple ne se trouvaient pas dans le dossier « data » de la map comme les advancements et les functions. Il fallait donc pour la distribution donner chaque dossier séparément et les installer dans un répertoire différent, ce qui n’est plus le cas du DataPack, se partageant de la même façon qu’un Resource Pack. La structure du dossier est faite ainsi :
Il y a quelques conventions à respecter :
Pour le namespace, le nom doit être seulement en minuscules, peut contenir des chiffres, un underscore ‘_’ et un tiret ‘-‘.
Il en est de même pour les noms de fichiers, en y ajoutant les slashs ‘/’ et le point ‘.’.
Voilà qui boucle notre tour des fonctionnalités techniques qu’ajoutent les snapshots. Même s’il se peut qu’il y ait d’autres ajouts avant la sortie officielle de la 1.13, il y a peu de chances que beaucoup de nouvelles commandes fassent leur apparition (outre la modifyitem que j’ai mentionné plus haut). Bien que cela fasse râler pas mal de Map Makers, qui devront mettre tout leur contenu à jour, cette version ajoute énormément de possibilités techniques jusqu’alors trop peu accessibles. Ainsi, je l’espère, nous verrons sortir d’ici quelques mois des systèmes plus complets et complexes agrandissant encore le champ des possibles de ce jeu.
