La Fabric pour Minecraft 1.19 : découverte de la mise à jour sauvage

Minecraft 1.19 : The Wild Update est enfin disponible, apportant avec lui des mises à jour pour la Fabric elle-même et de nombreux mods déjà existants.

Pour les joueurs

Les joueurs souhaitant profiter de Minecraft 1.19 devraient utiliser Fabric Installer 0.11.0 et Fabric Loader 0.14.6 (au moment de la rédaction) pour pouvoir jouer sur cette nouvelle version.

De nombreux mods ont déjà été mis à jour pour la version 1.19 et nous pouvons nous attendre à en voir beaucoup d’autres arriver prochainement. Soyez patients, car les développeurs de mods consacrent une partie de leur temps libre à mettre à jour leurs créations pour cette nouvelle version.

Les changements de la Fabric pour les développeurs de mods

Les développeurs devraient utiliser Loom 0.12 (au moment de la rédaction) pour développer des mods pour Minecraft 1.19.

Minecraft 1.19 introduit plusieurs changements de code au niveau des API principales utilisées par les développeurs. De plus, la Fabric a ajouté de nouvelles fonctionnalités permettant aux développeurs de mods de développer de manière sécurisée des mods côté serveur sans dépendre accidentellement de code spécifique au client.

Nouvelles fonctionnalités de l’API Fabric

L’API Fabric a ajouté de nombreuses fonctionnalités depuis la dernière mise à jour :

• Génération de données : génération facile de fichiers JSON pour les blocs, les recettes, les progrès, etc. (modmuss50)
• Recherche d’API d’entité : récupération flexible des instances d’objets à partir d’entités (deirn)
• Conditions de ressources : activation sélective des recettes, des progrès, etc. lorsque des conditions spécifiques sont remplies (Technici4n)
• Module d’extension d’accès transitoire : utilisation directe de nombreuses classes et méthodes privées/protégées de la version vanilla (Juuxel)
• Attributs de variantes de fluide : définition et accès au nom, à la température, etc. des fluides (Technici4n)
• Balises de convention : définition de balises standard que les mods Fabric peuvent utiliser et enregistrement des entrées vanilla auprès de ces balises (dexman545)
• Loot API v2 : remplacement de l’API de table de butin v1, avec de nombreuses améliorations. La nouvelle version utilise l’injection d’interface et les extensions d’accès transitoire pour mettre en œuvre la plupart de ses fonctionnalités. De plus, LootTableLoadingCallback a été remplacé par l’événement LootTableEvents.REPLACE (pour remplacer une table de butin entière) et l’événement LootTableEvents.MODIFY (pour modifier une partie d’une table de butin). REPLACE s’exécute avant MODIFY et si un mod remplace une table de butin, la boucle de rappel se termine prématurément et aucun autre mod ne peut remplacer la table de butin (Juuxel)
• API de messages (expérimentale) : manipulation côté serveur des messages envoyés aux joueurs (apple502j)
• Et de nombreuses autres fonctionnalités et corrections de bugs.

Modules de l’API Fabric dépréciés

Certains modules de l’API Fabric sont désormais dépréciés (y compris l’API de table de butin v1 susmentionnée et l’API de commande v1) et ne sont plus présents dans l’artefact Maven par défaut. Les mods souhaitant utiliser ces modules doivent maintenant dépendre de net.fabricmc.fabric-api:fabric-api-deprecated dans leur fichier build.gradle pour construire avec succès.

Cela ne devrait pas avoir d’incidence sur les joueurs, car le jar téléchargé depuis CurseForge et Modrinth contient toujours tous les modules nécessaires.

Isolation des chargeurs de classes et Mixins

Fabric Loader 0.14 améliore l’isolation des chargeurs de classes. Cela permet aux Mixins de s’appliquer aux bibliothèques utilisées par le jeu, telles que Brigadier, DataFixerUpper ou Authlib. Les mods qui utilisent des contournements pour permettre l’application des Mixins à ces bibliothèques doivent supprimer ces contournements.

Séparation du code client et commun

Dans Loom 0.12 et Loader 0.14, une option expérimentale a été ajoutée pour séparer tout le code spécifique au client dans son propre ensemble de sources : les ressources et le code commun seront dans src/main, tandis que le code spécifique au client sera dans src/client. Cela garantit à la compilation qu’aucun code spécifique au client de Minecraft ne sera appelé sur le serveur. Lors de la compilation, Loom génère toujours un jar unique qui fonctionne à la fois sur le client et sur le serveur.

Pour activer les ensembles de sources séparés, ajoutez le code suivant au fichier build.gradle de votre mod :

loom {
    // ...
    generateSourcesets()
}

Comme votre mod sera maintenant réparti sur deux ensembles de sources, vous devrez utiliser le nouveau DSL pour définir les ensembles de sources de votre mod. Cela permet à Fabric Loader de regrouper le chemin de classe de votre mod.

Les changements de Minecraft pour les développeurs de mods

Changements de texte

Le texte doit maintenant être créé en utilisant les méthodes statiques fournies par l’interface Text, plutôt qu’en utilisant les constructeurs. Par exemple :

Text text = Text.of("Un exemple de texte");

Dans Yarn, les anciennes classes sont désormais appelées “text contents” (comme TranslatableTextContent), car elles ont été séparées de la structure du texte (style et voisins). Les développeurs de mods auront rarement besoin d’interagir avec ces classes de contenu de texte.

Changements de commandes

Les arguments des commandes ont été refactorisés pour rechercher les entrées du registre en utilisant la classe CommandRegistryAccess, une enveloppe autour du gestionnaire de registre. L’accès au registre est une optimisation pour gérer les références incorrectes aux tags, mais il doit être transmis aux arguments lors de l’enregistrement de la commande :

CommandRegistrationCallback.EVENT.register((dispatcher, dedicated) -> {
    MyCommand.register(dispatcher, CommandRegistryAccess.get(dispatcher));
});

Si vous utilisez Fabric API pour enregistrer des commandes, vous devriez passer à la version 2 de l’API Fabric Command, qui contient un changement majeur pour fournir l’accès au registre. Contrairement à la plupart des autres changements de rupture, il s’agit d’une API entièrement nouvelle avec un nouveau package.

Bien que la version 1 de l’API existe toujours pour l’enregistrement côté serveur, la fonctionnalité des commandes côté client n’est plus présente dans cette version. Si vous utilisez des commandes côté client, vous devez utiliser la version 2, qui utilise désormais un événement pour l’enregistrement.

Chat sécurisé

Mojang a introduit une fonctionnalité permettant de signer cryptographiquement les messages de chat afin de détecter si le serveur modifie les messages envoyés. Les joueurs signent tous les messages de chat à l’aide d’une clé privée fournie par Mojang, qui est vérifiée par le serveur et les clients. Si le serveur modifie le message de manière inattendue, le message ne peut pas être vérifié, et les clients peuvent choisir de masquer ces messages.

Cette fonctionnalité a également entraîné plusieurs changements de protocole :

• Le client enveloppe désormais le message avec le type de message chat.type.text (ou similaire) au lieu du serveur. Pour personnaliser cela, un type de message personnalisé (appelé “chat type” par le jeu) peut être enregistré. (Voir ci-dessous pour plus de détails.)
• Les commandes sont envoyées dans un paquet séparé, et non plus sous forme de message de chat précédé d’un slash.

Ces changements ont principalement un impact sur les mods qui modifient le message de chat côté serveur de diverses manières, comme la traduction ou la coloration. Pour éviter que les messages ne soient marqués comme “non vérifiés”, le mod doit utiliser l’une des deux options suivantes :

• Décoration du message côté client. Un serveur peut enregistrer un type de message personnalisé en utilisant un pack de données (tout comme la génération de monde personnalisée) qui comprend diverses “décorations” appliquées à l’ensemble du message. Chat Type Generator est un outil tiers qui peut générer facilement le fichier JSON définissant les types de messages personnalisés. Ensuite, lors de l’envoi d’un message, le mod doit transmettre la clé d’enregistrement du type de message à utiliser.
• Décorateur côté serveur. Celui-ci peut être utilisé pour modifier le contenu du message lui-même, ainsi que le style appliqué. L’API Fabric fournit une manière d’enregistrer un décorateur de message personnalisé.

Notez que pour signer le message produit par le décorateur de message, le serveur doit activer l’option “chat preview” en définissant previews-chat=true dans le fichier server.properties. Lorsque les clients se connectent à de tels serveurs, ils recevront un avertissement indiquant que le message tapé sera envoyé pour afficher un aperçu avant l’envoi. Les clients peuvent désactiver les aperçus de chat via les options, ce qui entraîne le marquage de la partie décorée du message comme “non signée” (mais pas le message original).

Enfin, il est recommandé de consulter la documentation de l’API Yarn, qui fournit des informations sur la manière dont les messages de chat sont gérés.

Autres changements

• La classe java.util.Random du JDK a été entièrement remplacée par l’interface net.minecraft.util.math.random.Random de Mojang. Plusieurs implémentations sont disponibles pour offrir différents niveaux de sécurité par rapport aux threads. Pour la plupart des cas d’utilisation, Random.create() devrait être utilisé pour créer une instance de générateur de nombres aléatoires. Notez que cette instance n’est pas sûre pour une utilisation multi-thread.
• Les options du client ont été entièrement refactorisées. Il existe une classe nommée SimpleOption qui gère tout ce dont une option a besoin, notamment le rendu, la validation, la sérialisation, etc. Une instance contient son nom, sa valeur actuelle, sa valeur par défaut et un ensemble de rappels pour fournir des comportements personnalisables. Par exemple, une option d’entier basée sur un curseur utiliserait ValidatingIntSliderCallbacks, tandis qu’une option basée sur un bouton utiliserait PotentialValuesBasedCallbacks. Pour obtenir la valeur, utilisez getValue(), et pour définir la valeur tout en effectuant une validation, utilisez setValue().
• La classe Tag a été supprimée, car elle était devenue largement obsolète dans la version 1.18.2 grâce à l’ajout de TagKey.
• Les classes internes, qui sont encore utilisées, ont été déplacées vers TagBuilder et TagEntry. Les utilisations restantes dans les fonctions utilisent maintenant Collection. TagFile a été ajoutée, ce qui permet de faire référence à un fichier JSON de tag spécifique.
• De plus, de nombreux tags vanilla ont été ajoutés ou modifiés dans la version 1.19. Assurez-vous que votre contenu modifié fait partie de tous les tags applicables. Par exemple, les postes de travail des villageois doivent maintenant être ajoutés au tag minecraft:acquirable_job_site.
• Le jeu ne fait plus référence aux structures générées comme des “configured structure features”. Les classes liées aux structures ont été renommées dans le mapping Yarn pour gérer ce changement. Par exemple, StructureFeature a été renommé en Structure.
• Les méthodes playSound ont désormais un paramètre de graine. Cette graine est utilisée pour déterminer quel son est joué pour un événement sonore, de sorte que deux joueurs qui entendent le même événement sonore entendront maintenant le même son. La plupart des mods n’auront pas besoin de modifier leur code pour prendre en charge les sons basés sur une graine, car les méthodes playSound sont surchargées pour fournir une graine aléatoire par défaut.