Minecraft 17w43a: Première Snapshot 1.13

Comme vous le savez déjà, la version 1.13 de Minecraft Java Edition n'apportera pas de nouvelles fonctionnalités, c'est une mise à jour technique, ayant pour but de:

• Améliorer le fonctionnement du jeu (performance, stabilité)
• Faciliter l'évolutivité du code (permettre d'ajouter plus facilement des contenus dans le futur)
• Simplifier le modding (qui est une conséquence du 2ème point)

Ce ne sont donc que des améliorations techniques, non visible, mais malgré tout très interressante qui nous attendent dans cette version Minecraft Snapshot 17w43a.


Cette première snapshot apporte deux changements majeurs au code: L'ajout des packs de données (datapack) et la mise à jour vers LWJGL 3. Les nombreux changements de Dinnerbone liés aux commandes n'ont pas encore été inclus dans la snapshot, ni les nouvelles textures de Jappa.


Les packs de données (ou datapacks)
Les pack de données sont l'équivalent des packs de ressources, mais ils s'appliquent coté serveur. Attention: "Coté serveur" ne signifie pas qu'ils ne fonctionnent pas en mode solo, bien au contraire, mais pour comprendre cette appellation il faut revenir un instant sur le fonctionnement de Minecraft.

Aux origines de Minecraft, à une époque lointaine où Notch était encore développeur principale sur le jeu, il n'y avait pas de distinction entre serveur et client: Minecraft était un jeu tout en un. Pour le faire fonctionner en mode multijoueur, Notch avait créer un serveur dédié, qui reprenait une bonne partie du code de Minecraft, autrement dit le code de Minecraft était dupliqué: le serveur dédié était un copier/coller d'une partie du jeu. Et malheureusement cela était une grosse source de bug, puisque tout bug corrigé sur le jeu devait également l'être sur le serveur, etc.

Donc pour régler ce problème, rapidement le serveur fut inclus dans le jeu, et aujourd'hui, lorsqu'on joue en mode solo, le mini serveur est lancé par le jeu, un serveur sur lequel vous êtes seul à jouer (sauf si vous ouvrez votre partie en mode lan, et c'est là qu'on comprend que la partie solo fonctionne sur un serveur multijoueur).

Il y a donc dans Minecraft 2 grand composant:
- Le client (qui gère tout ce qui est visible, les textures, les skins, l'affichage, les menus hors d'une partie, les sons, etc.)
- Le serveur (qui gère la grosse majorité des fonctionnalités du jeu, allant de la position des joueurs, les craftings, la configuration des menus, la positions de tous les blocs, les entités, les interactions entre blocs, les systèmes redstone, les commandes, etc...)

Les packs de ressources qui existaient déjà permettent de modifier les éléments gérer par le client (textures, sons, affichage 3D des blocs). Les packs de données permettront de modifier tous les éléments gérer par le serveur: commandes, table de loot, structures, advancements, craftings, et probablement encore plus de choses à l'avenir.

L'utilisation des datapacks sera très similaire aux packs de ressources déjà existant, la principale différence étant qu'il permet de modifier d'autres fonctionnalités du jeu

Utilisation et installation
Un fichier de données peut être un fichier zip ou un répertoire à l'intérieur du dossier <world>/datapacks/. Par exemple, les deux packs suivants sont des nom de datapacks parfaitement valides:

• <world>/datapacks/CoolPack2000.zip
• <world>/datapacks/SuperPack3000/

L'utilisation sous forme de dossier sera surtout pratique pour les créateurs de packs. Pour la majorité des joueurs, qui téléchargeront des packs depuis internet, il suffira de copier le fichier zip téléchargé dans le dossier "packs" dans le monde, et c'est tout, il sera automatiquement reconnu et installé par le jeu.

Si vous modifiez, installez ou supprimez un pack pendant l'exécution du jeu, la commande /reload permet de recharger les modifications.

Structure du fichier
La structure des datapacks est relativement similaire au pack de ressources, il contient:

• pack.mcmeta (Obligatoire) : Comme dans les packs de ressources, ce fichier contient une description du pack.
• data/ : C'est ce qui en fait un pack de données, contenant tous les fichiers de données.
• <namespace>/ : Comme pour les packs de ressources, tout les éléments ont besoin d'un espace de nommage. (Les éléments inclus de base de le jeu étant dans l'espace de nommage "minecraft")
  • functions/ : Contient toutes les fonctions (accessible via la commande /function)
    • <name>.mcfunction : Chaque fichier connant chacun une fonction de commande (nommé "<namespace>:<name>")
  • loot_tables/ : Contient toutes les tables de butin
    • <name>.json : Une table de butin (nommée "<namespace>:<name>")
  • structures/ : Contient toutes les structures du monde (les constructions pouvant être chargées/enregistrées via les blocs de structures)
    • <name>.nbt : Une structure (nommée "<namespace>:<name>")
  • advancements/ : Contient tous les progrés
    • <name>.json : Un avancement (nommé "<namespace>:<name>")
  • recipes/ : Contient toutes les recettes de crafting (Voir note ci-dessous)
    • <name>.json : Un crafting (nommée "<namespace>:<name>")

Lorsqu'une structure est enregistrée via un bloc de structure "Enregistrer", elle est enregistrée dans le dossier:
<world>/generated/structures/<namespace>/<name>.nbt
Lorsqu'on charge une structure à l'aide d'un bloc de structure "Charger", le bloc cherchera la structure en priorité dans le dossier <world>/generated/structures/<namespace> puis, s'il ne trouve pas la structure, il va la chercher dans un second temps dans les datapacks.


Hiérarchie dans les packs
Comme pour les packs de ressources, les packs de données ont un ordre de chargement. Cependant, il n'y a actuellement aucun moyen de voir ou de changer cela (aucun menu dans le jeu ne permet de gérer les datapacks). Mais Mojang promet d'y travailler, cela devrait arriver prochainement !


Et les recettes de craftings ?
Oui vous avez bien lu, la syntaxe des datapacks prend en charge les recettes de crafting personnalisées ! C'est une fonctionnalité que nous attendions pour la version 1.12 de Minecraft, malheureusement cette fonctionnalité n'est toujours pas implémentée, il va donc falloir attendre encore un peu pour en profiter. Et comme l'importation des recettes de crafting n'est toujours pas prise en charge, le jeu lui même ne gère pas la synchronisation des recettes. En d'autres termes, actuellement c'est le client qui gère les craftings et non le serveur, le travail restant pour prendre en charge les craftings personnalisés est donc énorme.


Espace de nommage (namespace)
Ce n'est pas un nouveau concept dans Minecraft, il existe depuis longtemps, mais il peut être intéressant de rappeler ce que c'est, à quoi ça sert, et comment ça fonctionne.

Les namespaces permettent d'éviter les conflits entre les différents mods et packs installés. Prenons un exemple:
Imaginez que vous installiez un mod qui ajoute plein de nouvelles épées, appelons le dans notre exemple "Power Sword". Toutes les épées seront enregistrées dans le namespace "power_sword", dont une certaine épée de granite nommée "granite_sword", exclusive à ce mod.
Puis un jour, Mojang décide d'ajouter une nouvelle arme, l'épée de granite, nommée "granite_sword" ! Que se passe-t-il ? Conflit ? Crash ? Grâce aux namespaces rien de tout cela, les 2 épées pourrons fonctionner parfaitement en parallèle car en réalité elles n'ont pas exactement le même nom, car leur nom complet est:

• power_sword:granite_sword (pour celle du mod)
• minecraft:granite_sword (pour celle du jeu vanilla)

C'est la toute la puissance des namespaces, aucun conflit n'est possible. Chaque créateur de pack ou de mod peut appeller ses créations comme il le souhaite, sans jamais risquer d'être en conflit avec un autre contenu. Notez que le namespace "minecraft" est particulier, car il est optionnel: dans une commande si vous ne donnez pas le nom du namespace d'un élément, c'est le namespace "minecraft" qui sera automatiquement choisit.

Il est donc important de toujours utiliser un namespace unique, le votre, sauf dans le cas ou vous souhaitez explicitement modifier, remplacer ou supprimer un élément d'un autre namespace (par exemple pour modifier les contenus du jeu lui même).

Un espace de noms ne doit contenir que les symboles suivants:

• 0123456789 (chiffre)
• abcdefghijklmnopqrstuvwxyz (minuscule)
• _ (souligné)
• - (tiret)

La convention de nommage recommandé étant lower_case_with_underscores.


Il est possible de nommer les éléments du jeu (recettes, fonctions, progrès, etc) comme on le souhaite, mais il est recommandé de se limiter aux symboles suivants:

• 0123456789 (chiffre)
• abcdefghijklmnopqrstuvwxyz (minuscule)
• _ (souligné)
• - (tiret)
• . (point)
• / (permet de créer des dossiers de contenus, pour les classer par thème par exemple, notamment utilisé pour les advancements qui sont triés par onglet)

La convention de nommage préférée est la même: lower_case_with_underscores.



LWJGL 3
La bibliothèque graphique lwjgl (gestion des entrées/sorties: claviers, souris, affichage 2D et 3D) a été mise à jour en version 3. Cela permet de corriger beaucoup de bugs qui perduraient depuis longtemps sur Mac OS et Linux, et devrait rendre le jeu beaucoup plus stable. Le principal changement visible étant le mode plein écran qui est désormais défini par défaut sur le mode fenêtres sans bordure, ainsi l'activation et la désactivation du mode plein écran est très rapide !

Cependant, cette mise à jour apporte également quelques nouveaux problèmes:

• Le mode plein écran sur Mac OS X a de fortes chances de faire crasher le jeu, il a donc été désactivé sur MacOS le temps de trouver une solution.
• Il peut y avoir des cas dans le jeu où les appuis sur les touches du clavier sont envoyés deux fois, par exemple en appuyant sur une touche de raccourci tout en survolant un élément dans l'onglet de recherche d'inventaire du mode créatif.
• Sur Mac OS X, l'icône du jeu n'est plus un bloc d'herbe. Mais Mojang travaille sur le bug pour le corriger rapidement