Les commandes en 1.9 : les nouveautés et les changements

Salut les gens !

Depuis la 1.8 sortie il y a près d’un an et demi, et avec l’arrivée de la 1.9, les commandes et les command_blocks tels que nous les connaissions ont bien changé (pour le meilleur et pour le pire). Aujourd’hui, ensemble, dans cette news, nous allons donc voir ce qui a été ajouté, ce qui a été remplacé, et même ce qui a été supprimé !

Pour plus de clarté, un code couleur a été instauré pour mieux faire la différence entre les deux versions : en conséquence, tout ce qui a trait à la 1.8 (en termes de commandes, tags NBT, exemples, valeurs chiffrées ou paramètres) est en vert, et tout ce qui a trait à la 1.9 est en jaune.

I) Les command_blocks

La première différence que l’on peut voir entre la 1.8 et la 1.9, c’est bien celui qui a affecté les command_blocks. On en distingue maintenant trois types : les blocs de commande classiques à impulsion, les blocs de commande à répétition (violets), et les blocs de commande en chaîne (verts).

Vous pouvez vous rendre sur cet article pour voir leurs nouvelles fonctionnalités : http://fr-minecraft.net/news-minecraft-1521-minecraft-snapshot-15w34a-test-complet.html.

Voilà ce qui a été modifié dans les grandes lignes : d’abord, les ordres d’exécution. Auparavant, les command_blocks s’activaient du bas vers le haut en premier lieu, puis de l’ouest vers l’est, et enfin du nord vers le sud. A présent, cet ordre fonctionne toujours, mais on lui privilégiera celui donné par la direction des command_blocks. En effet, ceux-ci peuvent à présent être orientés, et les flèches présentes sur leur face indiqueront quel prochain bloc de commande sera activé.

Ensuite, la limite de caractères que peuvent contenir les command_blocks a été rabaissée : elle est passée de 32 767 caractères en 1.8 à 32 500 caractères en 1.9, soit une diminution de 267 caractères.

Autre ajout : l’auto-complétition dans les command_blocks avec une pression sur la touche <TAB> du clavier. Celle-ci ne se fait maintenant plus uniquement dans le chat, mais aussi dans les blocs de commande.

En parallèle, le changement sans doute le plus apprécié réside dans l’ajout du command_block à répétition, qui remplace nos anciennes clocks en /fill et diminue grandement les lags qui pouvaient en découler. Auparavant, exécuter une commande 20 fois par secondes (dans une configuration créée pour avoir le moins de lags possibles, une commande en "/setblock ~ ~ ~1 redstone_block 0 destroy" ne compte pas) nécessitait au minimum 3 blocs de commande ; aujourd’hui, un seul suffit :

Pour minimiser encore plus les lags sur ces blocs qui, déjà, n’en font presque pas, on peut exercer sur eux une commande en "/blockdata ~ ~-1 ~ {TrackOutput:0b}", qui aura pour effet de mimer un clic sur le "O" à droite de la ligne la plus basse pour le changer en "X ", afin que le bloc ne communique pas le "résultat" de la commande, sa réussite ou son échec.

On peut également citer la nouvelle fonction "Conditionnal" (inversée en "Unconditionnal") qui remplace les comparateurs, et est expliqué dans cette news : http://fr-minecraft.net/news-minecraft-1522-minecraft-snapshot-15w34b-est-sortie.html.

On peut aussi noter la fonction "Needs Redstone" (inversée en "Always Active") qui précise si un bloc de commande a besoin (ou pas, avec le "Always Active") d’être activé par un courant de redstone pour fonctionner.

II) Les ajouts

1) Les ajouts d’éléments de commandes

Entre la 1.8 et la 1.9, concernant les commandes, de nombreuses choses ont été ajoutées. Dans cette news, nous toucherons à tout ce qui ne se résume pas à un simple ajout d’ID, comme les blocs, les items, les entités, les effets ou les enchantements, que nous ne traiterons pas.

Pour commencer, on notera l’ajout de nouvelles statistiques :

• aviateOneCm : cette stat rend compte de la distance parcourue par un joueur avec des élytres.
• drop : cette stat comptabilise le nombre de fois que le joueur a jeté un objet.
• pickup : cette stat comptabilise le nombre d’items que le joueur a ramassé.
• sneakTime : cette stat comptabilise le nombre de ticks où un joueur "sneake", soit le nombre de ticks où il est accroupi avec la touche <SHIFT> de son clavier.
• stat.sleepInBed : cette stat comptabilise le nombre de fois où un joueur a dormi dans un lit.

On a également l’ajout de nouvelles particules :

• damageIndicator : particules en forme de cœur produitent par les mobs lorsqu’ils subissent des dégâts.
• dragonBreath : particules que l’on retrouve lors de la nouvelle attaque de souffle de l'Ender Dragon.
• endRod : particules produitent par les barres de l'Ender.
• sweepAttack : particules que l’on retrouve lors de l'attaque défensive de "balayage" exercée avec une épée.

Viennent après de nouveaux attributs :

• generic.armor : cet attribut désigne à quel point on est protégé en équipant un objet.
• generic.attackSpeed : cet attribut, traduit "vitesse d’attaque", désigne le nombre d’attaques que l’on peut charger au maximum en une seconde.
• generic.luck : cet attribut va jouer sur les "tables de loots" et va déterminer la rareté des items que l’on pourra trouver dans des coffres, à la pêche ou sur des mobs (c’est, en quelque sorte, l’attribut qui détermine si on est chanceux ou non).

L’ajout de l’utilisation d’une nouvelle main a induit la création d’un nouvel ID de slot : celui de la main gauche correspond maintenant au slot "-106".

On a également eu l’ajout de nouveaux effets, que nous ne décrirons pas ici, mais qui possèdent néanmoins une petite particularité liée aux commandes : on sait que dans la 1.9, les effets sont affichés en haut à droite de l’écran. Or, avec une commande en /effect, on peut désactiver cet affichage en inscrivant le paramètre "true" à la fin de la commande, ce qui avait uniquement pour effet, en 1.8, d’enlever toutes traces de particules à l’effet.

Plus de 150 sons ont aussi été ajoutés (et certains ont été remplacé, comme par exemple le son de la pluie).

Enfin, on peut dire que le sélecteur en [m=…], qui permettaient de cibler le mode d’un joueur, accepte à présent les valeurs "négatives". Cela signifie qu’on peut à présent cibler les joueurs qui N’ONT PAS un mode particulier. Par exemple, une commande en "/execute @a[m=!spectator] ~ ~ ~ say Je ne suis pas spectateur", ou "/execute @a[m=!3] ~ ~ ~ say Je ne suis pas spectateur" fera à dire à tous les joueurs qui ne sont pas en mode spectateur… qu’ils ne sont pas spectateurs.

2) Les ajouts concernant les commandes en elles-mêmes

a) Commandes diverses

La commande /gamerule peut s’appliquer à trois nouveaux éléments :

• disableElytraMovementCheck : si cette gamerule est mise à "true", le serveur ne vérifiera pas la vitesse des joueurs quand ils volent avec des élytres. Elle est par défaut mise en "false".
• spectatorsGenerateChunks : cette gamerule est par défaut mise en "true", et implique qu’un joueur en mode spectateur générera des chunks en allant dans des zones qui n’ont pas encore chargé.
• spawnRadius : cette gamerule permet de la taille de la zone dans laquelle un joueur pourra spawner en multijoueur autour du point de spawn. Cette règle est par défaut mise à 10, ce qui signifie qu’un joueur pourra apparaître à un point aléatoire dans un cercle de 10 blocs de diamètre autour du point de spawn du monde.

La commande /time query possédait 2 paramètres : "daytime", qui correspondait au tic écoulés dans une journée ; et "gametime", qui correspondait aux tics écoulés depuis la création du monde. En 1.9, il existe un nouveau paramètre : "day", qui correspond lui au nombre de jours qui se sont écoulés depuis la création du monde.

b) Commande en /scoreboard

Depuis la 1.9, la commande en /scoreboard players… possède un nouveau paramètre : le paramètre "tag". Cela signifie que grâce à cette commande, on peut maintenant, sur le modèle des tags NBT (que nous verrons plus tard) ajouter ou enlever un tag à une/des entité(s). Par exemple, une commande en "/scoreboard players tag @e[type=Arrow] add FlecheVolante {inGround:0b}" ajoutera le tag "FlecheVolante" à toute flèche qui ne sera pas plantée dans le sol. Et inversement, une commande en "/scoreboard players tag @e[type=Arrow] remobe FlecheVolante {inGround:1b}" enlèvera le tag "FlecheVolante" à toute flèche qui, cette fois-ci, SERA plantée.

Une autre particularité de ces tags, qui peut s’avérer très intéressante, est qu’ils peuvent être exploités dans les sélecteurs. Par exemple, une commande en "/execute @e[tag=FlecheVolante] ~ ~ ~ say Je vole !" fera dire "Je vole ! " à une flèche qui aura reçu le tag "FlecheVolante" grâce à la première commande vue juste avant.

En parallèle, de nouveaux types d’objectifs ont été ajoutés :

• "air", qui correspond au nombre de tics qu’il reste à un joueur avant de ne plus pouvoir respirer sous l’eau. Le score est de 300 à la surface et diminue de 1 tous les tics tant qu’on reste sous l’eau. Un effet de "water_breathing" aura pour effet de stopper le "timer", qui recommencera à perdre en valeur dès que l’effet aura disparu.
• "armor", qui correspond aux points de défense qu’aura un joueur grâce à ses pièces d’armure équipées.
• "food", qui correspond au nombre de demi-gigots qu’aura un joueur dans sa barre de faim (allant donc de 0 à 20).
• "level", qui correspond aux niveaux d’xp qu’a un joueur.
• "xp", qui correspond au nombre de points d’xp qu’a un joueur.

Pour donner un exemple, un score "Nourriture" sera créé avec la commande "/scoreboard objectives add Nourriture food". Si je sprinte et que je perds un gigot entier dans ma barre de faim, mon score "Nourriture" sera de 18. Et si je mange une pomme, il reviendra à 20.

Enfin, toujours concernant la commande en /scoreboard, une nouvelle option a été rajoutée à la version /scoreboard teams option : l’option "collisionRule", qui peut être modifiée selon les paramètres "always", "never", "pushOtherTeam" et "pushOwnTeam", et qui permet de déterminer si les joueurs peuvent se pousser entre eux, en règle générale, entre équipes adverses, ou uniquement au sein de sa propre équipe. Tout cela simplement parce que depuis la 1.9, les joueurs ont la possibilité de se faire pousser (donc gare à l’AFK).

3) Les ajouts concernant les NBT tags

En 1.9, de nombreux NBT tags ont été ajoutés. Ces tags peuvent généralement être donnés avec une commande en /summon, exploités avec une commande en /scoreboard ou en /stats, ou encore modifiés avec un /blockdata ou un /entitydata.

Tout d’abord, sur les entités, on a l’ajout du tag "Glowing", qui permet d’entourer les entités d’un halo lumineux. Par exemple, la commande "/summon Cow ~ ~1 ~ {Glowing:1}" fera apparaître une vache affectée indéfiniment de l’effet Glowing.

On a ensuite le tag… "Tags", qui permet de donner (ou d’exploiter) des tags à une entité sans passer par la commande /scoreboard. Par exemple, une commande en "/summon Pig ~ ~1 ~ {Tags:["Dodu","FuturSaucisson"}}" fera apparaître un cochon avec les tags "Dodu" et "FuturSaucisson"

Pour les mobs seulement, cette fois-ci, on a le tag "DeathLootTable" qui détermine le modèle selon lequel les loots d’un mob seront lachés. Par exemple, une commande en "/summon Zombie ~ ~ ~ {DeathLootTable:"minecraft:chests/simple_dungeon"}" fera apparaître un zombie qui, une fois tué, droppera les items qu’on aurait pu trouver dans un coffre de donjon (soit, par exemple, une selle, des pommes d’or, des name_tags, etc).

Dans la même lignée, le tag "DeathLootTableSeed" déterminera le monde depuis lequel le modèle de loots d’un mob sera sélectionné. Par exemple, une commande en "/summon Zombie ~ ~1 ~ {DeathLootTable:"minecraft:chests/simple_dungeon",DeathLootTableSeed:123456789}" fera apparaître un zombie qui, une fois tué, droppera les loots qu’on aurait pu trouver dans un coffre de donjon d’un monde dont la seed aurait été "123456789".

Le tag "LeftHanded" existe maintenant aussi : son utilité est de déterminer si la main dominante d’un mob sera la gauche. Par exemple, une commande en "/summon PigZombie ~ ~ ~ {LeftHanded:1}" fera apparaître un zombie pigmen dont la main dominante sera la gauche.

Concernant les joueurs uniquement, deux nouveaux tags ont été ajoutés. On a en premier lieu le tag "DataVersion", qui permet de voir avec quelle version de Minecraft un joueur est-il en train de jouer (ce qui peut s’avérer très utile pour les mapmakers). Par exemple, une commande en "/scoreboard players set @a Version 1549 {DataVersion:152}" mettra un score "Version" à 1549 pour tous les joueurs jouant avec la snapshot 15w49b (dont la DataVersion est 152, et s’obtient dans le dossier "versions" de minecraft, avec un éditeur NBT ; les numéros sont aussi récapitulés sur ce lien, où il faut chercher le mot "dataversion" pour les retrouver : http://fr-minecraft.net/launcher/serveur.php).

En second lieu, on a le tag "RootVehicle", dont l’introduction est due à celle du tag "Passengers", que nous verrons plus tard. Le tag "RootVehicle" permet de voir l’entité que "pilote" une autre entité. Par exemple, la commande "/testfor @a {RootVehicle:{Entity:{id:Boat}}}" renverra un signal positif si un joueur est détecté en train de piloter un bateau.

Pour les items, un tag "Slot" a été ajouté dans l’utilisation du tag déjà existant "AttributeModifiers". Ce nouveau tag, qui peut prendre les paramètres "head", "torso", "legs", "feet", "mainhand" et "offhand", désigne le slot sur lequel doit être porté l’objet avec l’attribut modifié pour que celui-ci fonctionne. Par exemple, un casque en or obtenu avec une commande en "/give @p golden_helmet 1 0 {AttributeModifiers:[{AttributeName:"generic.maxHealth",Name:"Test",Amount:10.0,Operation:0,UUIDLeast:123456l,UUIDMost:123456l,Slot:"head"}]}" ne pourra donner des cœurs supplémentaires à un joueur que si celui-ci équipe le casque sur sa tête. Dans le cas contraire, par exemple s’il le tient en main, le casque n’aura aucun effet sur son nombre de points de vie.

Pour les entités plus spécifiques, on peut noter l’ajout du tag "VillagerProfession" pour les zombies villageois, qui permet, comme son nom l’indique, de spécifier via les commandes la profession de ces derniers.

Pour les Shulkers, on a cinq nouveaux tags :

• les tags "APX", "APY" et "APZ", qui indique les coordonnées où se trouve le Shulker. Par exemple, une commande en "/summon Shulker 11 22 33 {APX:44.0,APY:55.0,APZ:66.0}" fera apparaître un Skulker non pas en 11 22 33, mais en 44 55 66.
• le tag "AttachFace", qui indique dans quelle direction est tournée le Shulker (donc vers quelle face du bloc qui l’entoure, la valeur "0" correspondant à la face du bas).
• le tag "Peek", qui indique l’avancement de son attaque, soit la hauteur du demi-bloc qui lui recouvre la tête.

Concernant les projectiles de ces Shulkers, on a de multiples nouveaux tags, que nous allons voir avec un exemple :

/scoreboard players set @e Target 1 {Steps:2,Dir:0,TXD:11.0,TYD:22.0,TZD:33.0,Owner:{X:44,Y:55,Z:66,L:123456L,M:123456L},Target:{X:77,Y:88,Z:99,L:7890123L,M:7890123L}}

Cette commande mettra un score "Target" à 1 à un projectile de Shulker uniquement si :

• le projectile a déjà dévié 2 fois sa course pour atteindre sa cible (tag "Steps:2")
• le projectile est dirigé vers le bas (tag "Dir:0")
• le projectile se situe en coordonnées 11 22 33 (tags "TXD:11.0,TYD:22.0,TZD:33.0")
• le Shulker qui a lancé le projectile se situe en 44 55 66 et possède l’UUIDLeast 123456 et l’UUIDMost 123456 (tags "Owner:{X:44,Y:55,Z:66,L:123456L,M:123456L}"). Les UUIDs désignent l’identité du Shulker (une longue suite de chiffres et de lettres aléatoires fixées par un système hexadécimal).
• la cible du Shulker se situe en 77 88 99, et possède une UUIDLeast 7890123 et une UUIDMost 7890123 (tags "Target:{X:77,Y:88,Z:99,L:7890123L,M:7890123L}").

Pour les EnderCrystauxl, on a deux nouveaux tags :

• le tag "BeamTarget" suivi de coordonnées, qui indique vers quel bloc pointe le faisceau sortant de l’EnderCrystal. Par exemple, une commande en "/summon EnderCrystal ~ ~ ~ {BeamTarget:{X:11,Y:22,Z:33}}" fera apparaître un EnderCrystal dont le faisceau pointera vers les coordonnées 11 22 33.
• le tag "ShowBottom", qui permet de masquer ou d’afficher la partie en bedrock située sous le cristal. Par exemple, une commande en "/summon EnderCrystal ~ ~ ~ {ShowBottom:0b}" fera apparaître un cristal sans la partie en bedrock.

Pour l’EnderDragon, on a cette fois-ci l’ajout d’un seul tag : le tag "DragonPhase". Par exemple, une commande en "/scoreboard players set @e[type=EnderDragon] Phase 1 {DragonPhase:1}" mettra un score "Phase" à 1 à l’EnderDragon si celui-ci en est bien à la phase 1 du combat.

• La phase 0 correspond au moment où le dragon se contente de faire des cercles
• la phase 1 correspond au moment où il lance une Fireball
• la phase 2 correspond au moment où il vole vers le portail pour atterrir
• la phase 3 correspond au moment où il est en train d’atterrir
• la phase 4 au moment où il atterri pour de bon
• la phase 5 au moment où il s’apprête à cracher son souffle mortel
• la phase 6 au moment où il cherche un joueur pour cracher
• la phase 7 au moment où il rugit et crache
• la phase 8 au moment où il charge le joueur
• la phase 9 au moment où il vole au portail pour mourir
• la phase 10, au moment où il meurt ! (pfiou, ça fait beaucoup de phases)

Concernant les potions, et tout ce qui les utilise, on a l’ajout de deux tags :

• le tag "Lingering", qui permet donner à une potion une forme… "lingering" et de générer un nuage une fois lancée.
• le tag "Potion", qui permet de préciser le type de potion que l’on souhaite, avec des IDs en toutes lettres. Par exemple, une commande en "/give @p splash_potion 1 0 {Potion:"minecraft:healing"}" donnera au joueur le plus proche une potion "splash" de type "healing". Ce tag est aussi applicable aux flèches : par exemple, une commande en "/summon Arrow ~ ~10 ~ {Potion:"minecraft:healing"}" fera apparaître une flèche avec l’effet d’une potion de "healing".

Les flèches dites "Spectrales" ayant été ajouté, le tag "Duration" s’y applique à présent, et défini pour combien de temps en tics les cibles qui seront touchées par ces flèches seront affectées de l’effet Glowing.

Pour les chevaux, deux tags ont été ajoutés :

• le tag "SkeletonTrap", qui indique si le cheval invoqué correspond à un piège. Par exemple, une commande en "/summon EntityHorse ~ ~ ~ {SkeletonTrap:1}" fera apparaître dans un éclair quatre chevaux squelettes montés par des squelettes.
• le tag "SkeletonTrapTime", qui indique le temps écoulé depuis le déclenchement du piège. Si ce tag atteint la valeur 18 000(un quart d'heure), les chevaux et les squelettes dispawneront. Par exemple, une commande en "/summon EntityHorse ~ ~ ~ {SkeletonTrap:1,SkeletonTrapTime:17900}" fera apparaître quatre cavaliers squelettes qui disparaîtront au bout de cinq secondes.

L’introduction d’une nouvelle entité, l’AreaEffectCloud, qui pourrait à terme remplacer les ArmorStands dans l’utilisation des commandes, a entraîné la création et l’utilisation de très nombreux tags :

• le tag "Age" désigne depuis combien de tics l’entité a été générée.
• le tag "Color" indique la couleur des particules du nuage (on l’écrira sous la forme "Color:656568", où le nombre est semblable à celui qu’on aurait pu utiliser pour colorer une armure en cuir).
• le tag "Duration" indique le nombre de tics restants avant que le nuage ne disparaisse (cela arrive quand il égale le tag "Age").
• le tag "DurationOnUse" indique de combien le tag "Duration" augmentera/diminuera lorsqu’une entité sera dans le nuage (par défaut à 0.0).
• le tag "Effects" suivi d’un nom d’effet désigne l’effet de potion qu’on aura en marchant sur le nuage.
• le tag "Particle" désigne quel type de particules est utilisé pour matérialiser le nuage.
• le tag "ReapplicationDelay" indique le nombre de tics durant lesquels un joueur pourra être affecté d’un effet en restant dans le nuage généré par l’entité.
• le tag "Radius" désigne le rayon en bloc(s) que couvre le nuage (par défaut à 20). Ce rayon diminue avec le temps.
• le tag "RadiusPerTick" désigne de quelle taille augmente/diminue le nuage par tics (par défaut à -0.005).
• le tag "RadiusOnUse" désigne de quelle taille augmente/diminue le nuage par tics lorsqu’une entité se trouve à l’intérieur (par défaut à -0.5).
• les tags "OwnerUUIDLeast" et "OwnerUUIDMost" désigne l’identité de l’entité qui est à l’origine du nuage.
• le tag "WaitTime" indique le nombre de tics qui devront s’être écoulés avant que le nuage ne commence à diffuser son effet (par défaut à 10).

En parallèle, pour les conteneurs comme les coffres, les hoppers, ou les minecarts avec coffres ou  minecart avec hopper, les tags "LootTable" et "LootTableSeed" ont été ajoutés. Ces tags suivents les tags "DeathLootTable et "DeathLootTableSeed" vues précédemment, et servent à remplir les conteneurs selon un certain type de table de loots ("LootTable") parfois issus d’un certain seed ("LootTableSeed").

Uniquement pour les minecarts avec hopper, un nouveau tag a été ajouté, le tag "Enabled" : s’il est mis à 0, il interdit au minecart de ramasser les objets qui l’entourent.

Pour continuer dans la lignée des moyens de locomotion, un nouveau tag "Type" a été ajouté aux bateaux, afin de définir leur type de bois. Par exemple, une commande en "/summon Boat ~ ~ ~ {Type:"birch"}" fera apparaître un bateau en bois de bouleau.

A présent, les blocs ! On a en premier lieu de nouveaux tags pour les blocs de commande :

• le tag "auto" qui est mis à 1 si un bloc de commande est mis en mode "Always Active" (ce qui signifie qu’il n’a pas besoin de courant de redstone pour fonctionner).
• le tag "conditionMet", qui est mis à 1 pour un bloc de commande qui a été activé par un autre mis en mode "Conditionnal".
• le tag "powered", qui est mis à 1 si un bloc de commande (ou un bloc de musique) reçoit actuellement un courant de redstone.

Ensuite, en deuxième lieu, on a le nouveau portail, appelé "end_gateway", qui amène avec lui trois tags :

• le tag "Age" qui indique depuis combien de temps le portail existe et augment à chaque tic. Tant que ce tag n’excède pas la valeur 200, le rayon qu’il libère sera violet.
• le tag "ExitPortal" suivi de coordonnées désignera dans quelle zone le joueur pourra être téléporté (sur un bloc, et pas dans le vide, ce qui explique la présence de ce "rayon de spawn").
• le tag "ExactTeleport", s’il est mis à 1, empêche justement cette notion de "rayon de spawn", et téléportera le joueur aux coordonnées exactes déterminées par le tag "ExitPortal".

Par exemple, une commande en "/setblock ~ ~ ~ end_gateway 0 replace {Age:100,ExitPortal:{X:11,Y:22,Z:33},ExactTeleport:1}" fera apparaître un portail dont le rayon sera violet pendant 5 secondes. Si on rentre dans ce portail, on sera téléporté aux coordonnées exactes 11 22 33.

Et enfin, en troisième lieu, on a le brewing_stand avec son nouveau tag "Fuel" qui indique à quel point la jauge de blaze_powder du brewing_stand est rempli. Par exemple, une commande en "/setblock ~ ~ ~ brewing_stand 0 replace {Fuel:15b}" fera apparaître un brewing_stand avec sa jauge remplie aux trois quarts.

III) Les changements

Avec la 1.9, de très nombreux (et souvent regrettables) changements ont eu lieu ! Pour finir cette news, ce sont eux que nous allons voir.

1) Les changements dans les commandes en elles-mêmes

L’auto-complétition des commandes dans le tchat a été améliorée : auparavant, quand on appuyait sur la touche de notre clavier sans que notre curseur "sélectionne" un bloc, il ne se passait rien (alors que quand il le sélectionnait, la commande se complétait avec les coordonnées de ce bloc) ; à présent, la commande se complète avec des "~" correspondant à notre position actuelle si le curseur ne sélectionne aucun bloc.

Dans Minecraft 1.9, le langage en .json n’est (malheureusement) plus accepté qu’en tant que json STRICT. Ce qui signifie que ce genre de commande de la 1.8 ne fonctionne plus :

/tellraw @a {text:"yolo",color:blue,bold:true}

Et qu’en 1.9, il faut donc mettre des guillemets absolument partout :

/tellraw @a {"text":"yolo","color":"blue","bold":"true"}

En conséquence, les commandes de livres, de /tellraw, de /title, et une majorité de ce qui peut contenir du langage en .json en règle générale, est à changer en 1.9 (à la main, évidemment, sinon ce serait pas drôle).

Dans la même idée de rendre certaines commandes plus "strictes", faire apparaître une Fireball nécessite maintenant plus d’informations. En 1.8, on pouvait se contenter d’inscrire:

/summon Fireball ~ ~ ~ {direction:[]}

Alors qu'en 1.9, il fautmaintenant écrire :

/summon Fireball ~ ~ ~ {direction:[0.0,0.0,0.0],power:[0.0,0.0,0.0]}

Le tag "power" doit donc être précisé, et 3 valeurs comme "0.0" doivent être entrées entre les crochets.

La commande /enchant peut maintenant être appliquée sur les mobs en plus des joueurs.

La commande /gamemode renvoie maintenant dans le tchat le mode vers lequel le joueur est passé.

Si la gamerule "doMobLoot" est mise à "false", les joueurs lâchent à présent leur XP quand ils meurent (sauf si la gamerule "keepInventory" est mise à "true").

La syntaxe de la commande /particle a changé : elle prend maintenant la forme "/particle [quantité] [mode] [joueur] [paramètres ...]". Les ajouts concernent les options (qui, comme leur nom l’indique, sont optionnelles) "joueur" et paramètres". L’option "joueur" permet de spécifier quels joueurs peuvent voir les particules, et l’option "paramètres", qui peut prendre les valeurs "blockcrack", "blockdust", et "itemcrack", permet de voir le type d’objet ou d’item visible dans les particules (les informations concernant cette option "paramètres" sont assez floues, c’est la meilleure interprétation que j’ai pu formuler).

En parallèle, la commande /playsound a également évolué : on est passé de "/playsound <son> <joueur> [x] [y] [z] [volume] [pitch] [minimumVolume]" à "/playsound <son> <source> <joueur>  [x] [y] [z] [volume] [pitch] [minimumVolume]". Par exemple, une commande pour jouer à tous les joueurs le son de téléportation d’un enderman au maximum s’écrivait en 1.8 :

/playsound mob.endermen.portal @a ~ ~ ~ 999999 1 1

Désormais, en 1.9, pour obtenir le même effet, on devra écrire :

/playsound minecraft:entity.endermen.teleport master @a ~ ~ ~ 999999 1 1

On constate au passage que la syntaxe des sons a changé, et qu’ils s’auto-complètent quand on presse la touche <TAB>. Le paramètre "source" peut être remplacé par "master", comme dans notre exemple, pour être joué sur le volume principal, mais aussi par "ambient", "block", "hostile", "music", "neutral", "player", "record", "voice", ou "weather", ou chaque domaine peut avoir son volume modifié dans les paramètres de Minecraft.

2) Les changements concernant les NBT tags

Tout d’abord, l’introduction du paramètre "tag" dans les commandes en /scoreboard a introduit une limite : une entité ne peut posséder au maximum "que" 1024 tags.

En parallèle, il est possible d’obtenir le nombre de tags que possède une entité avec l’utilisation d’une commande /stats avec les paramètres "CommandStats" ou "QueryResult", combinée à une commande en "/scoreboard players tag @p list" (qui fonctionne pour le joueur le plus proche dans cet exemple).

Autre changement fort appréciable, le tag "Riding" a été supprimé au profit du tag "Passengers". Ce qui signifie que pour un squelette chevauchant un cochon en 1.8, on devait écrire :

/summon Skeleton ~ ~ ~ {Riding:{id:Pig}}

Alors que maintenant, en 1.9, on doit écrire :

/summon Pig ~ ~ ~ {Passengers:[{id:Skeleton}]}

Le tag "CustomNameVisible" fonctionne désormais d’une manière légèrement différente : s’il est mis à "true", il affichera le nom d’une entité de la même façon qu’un nom de joueur. Cela signifie qu’auparavant, on ne voyait le nom d’une entité qu’en pointant notre curseur sur elle ; à présent, on le voit même de loin, à travers les murs, exactement comme si c’était un joueur.

Ensuite, le tag "BlockEntityTag" peut maintenant être appliqué au bouclier pour changer son apparence, et fonctionne de la même façon que pour les drapeaux.

En parallèle, le tag "EntityTag" peut à présent être appliqué sur les spawn_eggs, ce qui signifie qu’on peut spécifier quelle entité (avec quels tags) pourra être générée avec un œuf. On n’a donc plus (à première vue) une ID spécifique pour chaque œuf, qui ont maintenant tous le damage "0", mais on peut spécifier ce qu’ils peuvent faire spawner avec ce nouveau tag.
Par exemple, une commande en "/give @p spawn_egg 1 0 {EntityTag:{id:Pig,Glowing:1}}" donnera au joueur le plus proche un œuf de cochon, cochon qui sera brillant une fois apparu grâce à l’œuf.

Le tag "HealF" a été remplacé par le tag "Health". Ce tag permet notamment de fixer le nombre de points de vie d’une entité ; par exemple, une commande en "/summon Cow ~ ~ ~ {Health:1}" fera apparaître une vache avec un seul point de vie.

Le tag "Team" peut à présent être appliqué aux mobs. Par exemple, une commande en "/summon PigZombie ~ ~ ~ {Team: "Nether"}" fera apparaître un zombie pigmen qui sera mis d’office dans l’équipe "Nether".

Dans les mobs_spawners, l’usage du tag "EntityId" a été remplacé par celui du tag "id" combiné avec le tag "SpawnData". Ce qui signifie qu’en 1.8, pour faire un spawner de zombie, on écrivait :

/setblock ~ ~1 ~ mob_spawner 0 replace {EntityId:Zombie}

Alors qu’en 1.9, on écrit maintenant :

/setblock ~ ~1 ~ mob_spawner 0 replace {SpawnData:{id:"Zombie"}}

En parallèle, le tag "Properties" a été remplacé par le tag "Entity" (ce qui a aussi entraîné la suppression du tag "Type"). Il est donc maintenant possible de faire apparaître des mobs différents avec un seul spawner, par exemple avec la commande "/setblock ~ ~ ~ mob_spawner 0 replace {SpawnPotentials:[{Weight:1,Entity:{id:"Sheep"}},{Weight:1,Entity:{id:"Cow"}}]}". Cette commande fera apparaître un mob_spawner qui fera tantôt spawner un mouton, tantôt une vache. Le tag "Weight" réparti les chances de spawn entre les deux entités. Question interface, le mob dans le spawner correspond à celui qui apparaîtra à la prochaine activation, ce qui signifie qu’il change assez souvent.

Autre changement, cette fois-ci concernant les ArmorStands : l’utilisation des valeurs du tag "DisabledSlot" a changé, ce qui signifie qu’à présent, à côté de ce tag, on doit mettre un numéro correspondant à l'opération…

• 1 << nombre du slot pour interdire toute interaction.
• 1 << (nombre du slot + 8) pour interdire de prendre un item sur l’ArmorStand.
• 1 << (nombre du slot + 16) pour interdire de mettre un item sur l’ArmorStand.

Tout ceci sachant que le slot de la main à la valeur 0, celui des pieds vaut 1, celui des jambes vaut 2, celui du buste vaut 3, et celui de la tête vaut 4.

Et enfin, dernière chose : suite à l’introduction de l’utilisation de la main gauche dans Minecraft, le tag "Equipment" a été supprimé au profit des tags "ArmorItems" et "HandItems". Ce qui signifie qu’en 1.8, pour faire apparaître un ArmorStand avec un casque en fer sur la tête et une torche dans la main, on écrivait :

/summon ArmorStand ~ ~ ~ {Equipment:[{id:torch},{},{},{},{id:iron_helmet}]}

Alors qu’en 1.9, on doit maintenant écrire :

/summon ArmorStand ~ ~ ~ {ArmorItems:[{},{},{},{id:iron_helmet}],HandItems:[{id:torch},{}]}

Le même système a été appliqué au tag "DropChances", à présent remplacé par les tags "ArmorDropChances" et "HandDropChances" pour définir quelles parties des mobs droppent quels items.

Vidéo

Voici enfin une vidéo récapitulant l'ensemble des ajouts et changements qu'on a pu voir entre la 1.8 et la 1.9 :


Conclusion

Voilà pour ces ajouts et changements ! Pour conclure, on peut dire que cette 1.9 est une petite révolution dans l'utilisation des command_blocks, notamment en ce qui concerne la quasi-suppression des lags qu'ils pouvaient engendrer.

De très nombreux ajouts sont aussi forts appréciables, mais pour ce qui est des évolutions, elles sont certes positives pour la plupart, mais négatives pour une bonne quantité. La récession du nombre de caractères autorisés dans les command_blocks, la disparition du tag "Riding", ou le fait que seul le json strict soit maintenant accepté, fond de la 1.9 une version particulièrement hostile aux One Commands, notamment en terme de nombre de caractères (sans parler du fait que toutes celles créées en 1.8.X sont désormais obsolètes). Cependant, l'introduction de nouveaux blocs de commande et tags NBT ouvre de nombreuses portes, qui seront sans doute TRES intéressantes à exploiter...