Minecraft Java 1.13, puis 1.14

De retour de ses vacances, Dinnerbone s'est remis au travail concernant la refonte des commandes dans le jeu. Cette semaine il a été confronté à un difficile dilemme: doit-on réécrire les commandes serveurs ?


Les commandes serveurs
Les commandes serveurs ne sont pas les commande les plus connu des joueurs, bien qu'elle soit quotidiennement utilisé par tous bons administrateurs de serveur, il s'agit de:

• /save-all
• /save-on
• /save-off
• /ban
• /pardon
• /banip
• /unbanip

Les 3 premières commandes (/save-*) permettent de gérer l'enregistrement de la map sur le disque dur:

• /save-all permet de lancer manuellement un enregistrement des dernières modifications (pratique pour enregistrer le monde avant de lancer une commande qui risque de faire crash le jeu par exemple)
• /save-on et /save-off permettent d'activer ou de désactiver l'enregistrement automatique de la map. L'enregistrement créant des lags, il est parfois intéressant sur les serveurs multijoueurs de la désactiver (avec le risque de tout perdre en cas de crash du jeu). Il est aussi possible de le désactiver pour gérer les sauvegardes via des plugins serveurs.

Les 4 autres commandes permettent de gérer les bannissements (ban UUID et ban IP): /ban et /pardon permettent de bannir/débannir un joueur par son ID unique, et /banip et /unbanip permettent de bannir/débannir une adresse IP. Ces commandes sont relativement peut utilisé par les serveurs multijoueurs, les administrateurs préférant l'utilisation de plugins bien plus performant. Cependant elles restent utiles pour les parties sur des petits serveurs improvisés entre amis, ou sur des serveurs vanilla (sans plugin).

Toutes ces commandes sont aussi vieille que le jeu, elles datent des versions alpha de Minecraft, et n'ont que très peut évolué avec le temps. On remarque une certaine incohérance dans leur nom: pourquoi avoir /banip et /unbanip, et pas /ban et /unban ? Très peut de personnes connaissent la commande /pardon, qui aurait du plus logiquement s'appeler /unban. De la même façon, pourquoi avoir fait 3 comamndes de sauvegarde ? Pourquoi "/save-all" et pas plus simplement "/save" ? Pour toutes ces raisons Dinnerbone envisage de renommé toutes ces commandes, pour les rendre plus intuitive, ainsi:

• /pardon deviendrait /unban
• /save-all deviendrait /save
• /save-on deviendrait /save enable
• /save-off devientrait /save disable
• etc.

Mais... tout n'est pas si simple.
Je vous ai donné des exemples d'utilisations manuelles de ces commandes, mais en réalités ces commandes sont surtout utilisées par des bots d'administrations, ou via des consoles d'administrations (par exemple MCMyAdmin ou les consoles fournit par les hébergeurs spécialisés). En un click sur un bouton sur les interfaces d'administrations et la commande est automatiquement envoyée au serveur. Cela a toujours bien fonctionné car ces commandes n'ont jamais changé depuis des années, mais si Dinnerbone change la syntaxe de ces commandes tous les robots, tout les scripts, toutes les consoles d'administrations seront cassé ! C'est donc une petite modification en apparence, mais très lourde de conséquence.

Pour s'aider à prendre la meilleur décision, Dinnerbone a lancé un sondage sur twitter pour avoir l'avis de la communauté, dont voici les résultats (sur 4657 votants):

• 45%: Je m'en fou un peu. Violet.
• 28%: Réorganise les !
• 14%: Réorganise les et garde les anciennes
• 13%: Laisse les tranquilles !

Sans surprise la majorité des joueurs ne s'y intéressent pas, puisqu'elles sont surtout destinés aux serveurs multijoueurs. Mais ensuite la majorité demande du changement, hors, comme le note un administrateur: Les problèmes ne concernent qu'une minorité de personne, les développeurs de scripts, de bot et d'interface d'administrations, même certains administrateurs n'en ont pas conscience, le résultat du sondage ne peut donc pas représenter la réalité de l'ampleur de l'impact qu'une telle modification aurait. Dinnerbone est d'ailleurs bien placé pour le savoir, car en tant que membre fondateur de Bukkit il savait que les petits changements dans une API pouvaient avoir de grande conséquence.

Finalement, la solution mixte ne serait-elle pas le meilleur compromis ? Ou bien une 5ème solutions, proposé par un hébergeur de serveur Minecraft, une solution non proposé dans le sondage par Dinnerbone et pourtant souvent utilisé dans Bukkit: Réorganiser les commandes, mais garder les anciennes actives encore quelques tant, puis les supprimer dans 1 ou 2 versions de Minecraft. Ainsi les développeurs et administrateurs auront le temps de faire évoluer leurs outils. C'était cette même méthode qui avait été utilisé lors de l'introduction des UUID dans Minecraft (identifiant unique des joueurs, un changement technique qui permet aujourd'hui a tout le monde de pouvoir changer de pseudo).

Pour le moment Dinnerbone n'a pas encore annoncé sa décision finale.


Une commande cliente ?
Continuons avec les autres changements probables: l'introduction d'une commande /clear. C'est une commande qui existe déjà, mais qui n'a pas du tout le comportement qu'on pourrait imaginer: Alors qu'il est naturel de taper /clear pour effacer le tchat, malheureusement cette commande sert a quelque chose de bien pire: vider l'inventaire du joueur ! De nombreux joueurs ont déjà eut une désagréable surprise en testant la commande... Pourtant c'est une commande très demandé, Dinnerbone lui même avoue que ça lui a manqué par le passé. Une commande d'autant plus demandé qu'elle existe sur la plupart des shells (Bash sous linux ou Powershell sous windows par exemple), c'est donc une commande bien connu des administrateurs pour vider l'affichage de la console.
Mais il existe déjà une possibilité de vider l'affichage du tchat, mais c'est une méthode loin d'être intuitive: il s'agit du raccourcit clavier F3+D. Si vous ne le connaissiez pas, il fallait d'abord faire "F3" (pour activer le mode debug), puis voir le message indiquant de faire F3+Q pour afficher l'aide:

En faisant F3+Q on découvre, perdu au milieu de raccourcis de debugage, le raccourcit clavier F3+D permettant de vider le tchat. Un raccourcit qui malheureusement vide également l'historique des commandes déjà tapées.

Si Dinnerbone implémente la commande /clear, cela sera la première (et probablement aussi la dernière) commande uniquement active coté client (c'est à dire sans aucune influence ni sur le monde, ni sur les entités, ni sur d'autres joueurs).


Coloration syntaxique
Autre changement, plus visuel cette fois, la coloration syntaxique pour les tags NBT avec la commande /entitydata:

Cela permet de voir beaucoup plus facilement la structure de la balise JSON, c'est un procédé bien connu de tous les développeurs, une aide précieuse. Ici les couleurs utilisées sont:

• Le cyan pour les noms de tag
• Le orange pour les valeurs numériques
• Le vert pour les chaines de caractère (texte)
• Le rouge pour les types de données (j'y revient tout de suite)
• Le blanc pour la structure

Vous vous demandez peut être a quoi correspond les lettres en rouge, derrières (presque) chaque nombre en orange ?
Il s'agit d'une information purement technique, permettant de connaitre l'encodage du nombre dans la mémoire de l'ordinateur. En connaissant le mode de stockage ça nous permet de connaitre ses limites (Pour donner un exemple fictif simple, si un nombre était stocké sous la forme de 3 chiffres décimaux, on sait qu'on ne pourra pas mettre la valeur 10000 qui fait 5 chiffres).

On retrouve les symboles suivants:

• b (Byte, ou Octet en français), nombre entier relatif stocké sur 8bit, valeur entre -128 et +127
• s (Short), nombre entier relatif stocké sur 16bit, valeur comprise entre -32768 et +32767
• rien (Entier), nombre entier relatif stocké sur 32bit, valeur comprise entre -2³¹ et +2³¹-1
• L (Long), nombre entier relatif stocké sur 64bit, valeur comprise entre -2⁶³ et +2⁶³-1
• f (Float), nombre décimal à virgule flottante, stocké sur 32bit
• d (Double), nombre décimal à virgule flottante, stocké sur 64bit

A noter que le type "Byte" est souvent utilisé dans les tags NBT pour définir des valeurs booléennes (2 valeurs possibles uniquement, vrai (1) ou fausse (0)), dans ces cas il ne faudra donc pas donner de valeur autre que 0 et 1.


Bientôt une sortie des snapshots ?
Reste une question que nous nous posons tous: pourra-t-on bientôt tester les nouveautés de cette version 1.13 dans les snapshots ? Pas tout de suite selon Dinnerbone, il faudra encore attendre quelques semaines, sans donner plus de précision. Mais il modère notre enthousiasme en rappelant que la version 1.13 sera une mise à jour technique, avec très peut (pour ne pas dire aucune) nouveauté fonctionnelle: aucun nouveau bloc, aucun nouveau mob, etc.

Pour les vraies nouvelles fonctionnalités il faudra attendre la version 1.14, et bonne nouvelle: une partie de l'équipe de développement de Minecraft Java travaille déjà sur la version 1.14 et ses nouvelles fonctionnalités ! Mais Mojang garde très probablement le secret sur ces nouveautés pour les annoncer en novembre, lors de la Minecon Earth.