Découvrez Fabric pour Minecraft 1.20

Minecraft 1.20 – mise à jour Trails and Tales – sera disponible le 7 juin 2023 et apportera comme d’habitude de nombreux changements qui impacteront de nombreux mods.

Comme toujours, nous demandons aux joueurs d’être patients et de laisser aux développeurs de mods le temps de mettre à jour leurs créations pour cette nouvelle version.

Voici une liste des principaux changements orientés vers les moddeurs dans cette version. Notez que toutes les références de code utilisent les mappages Yarn ; les moddeurs utilisant des mappages alternatifs devront peut-être utiliser des noms différents.

Changements de Fabric

Les développeurs devront utiliser Loom 1.2 (au moment de la rédaction) pour développer pour Minecraft 1.20. Les joueurs devront installer la dernière version stable de Fabric Loader (actuellement 0.14.19) pour jouer en 1.20.

Loom 1.2

Loom 1.2 est une petite mise à jour axée sur l’amélioration de la gestion des bibliothèques de jeux et la prise en charge officielle de Windows ARM. Loom 1.2 nécessite Gradle 8.1.

Nouveaux changements dans l’API Fabric

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

• Génération de données : ajout d’un fournisseur de données codec (ErrorCraft)
• Événements d’interaction : fourniture d’une API de faux joueur (Technici4n)
• Réseau : ajout d’une API basée sur les paquets similaire au système de réseau vanilla. Consultez le gist pour des conseils de migration. Notez que l’API existante n’est pas obsolète de quelque manière que ce soit (apple502j)
• API de rendu : ajout d’une inspection des matériaux et d’une propriété de matériau étincelant, suppression des indices de texture (PepperCode1, Technici4n)
• API de transfert : ajout de stockage à emplacements et d’un itérateur non vide (Technici4n)
• Autres ajouts mineurs à diverses APIs, tels que la ConventionTag et l’Object Builder

Changements et dépréciations importants

Mis à part les modifications liées au code Minecraft (dont nous parlerons ci-dessous), aucune modification majeure de l’API n’a été introduite.

Lors d’une des refactorisations de code, un bogue lié à la synchronisation des registres a été “accidentellement” corrigé. Ce bogue permettait auparavant aux clients avec Fabric API (mais sans mods de contenu) de rejoindre un serveur avec des contenus moddés, même si le mod était manquant sur le client. Le refactor a été fusionné à la fois dans les branches 1.19.4 et 1.20 snapshot. Cependant, le bogue a été réintroduit uniquement dans la version 1.19.4 pour éviter les cassures inattendues. Si vous comptiez sur ce bogue, assurez-vous que les utilisateurs installent les mods sur le client.

Quelques APIs peu utilisées de EventFactory ont été dépréciées. Elles étaient destinées à être utilisées pour le profilage des événements ; cependant, le profileur Java standard donne de meilleurs résultats.

• La méthode invalidate a été dépréciée de manière définitive et sera supprimée dans les futures versions.
• La méthode isProfilingEnabled a été dépréciée et renvoie maintenant toujours false.
• La méthode getHandlerName a également été dépréciée.

Dépréciations dans l’API de rendu de Fabric

De nombreuses méthodes de l’API de rendu avaient un paramètre int spriteIndex qui valait toujours 0. Ce paramètre a été supprimé et le nom de certaines méthodes a été amélioré dans le processus. La propriété booléenne disableAo pour les matériaux a été remplacée par un TriState plus flexible pour ambientOcclusion.

Les anciennes méthodes sont maintenant dépréciées. Voici quelques exemples pour effectuer la transition :

• La liste complète des renommages peut être trouvée dans la description de la pull request.
• Les nouvelles méthodes n’ont pas de mise en œuvre par défaut dans la version 1.20. Cela n’affecte pas les mods utilisant l’API de rendu, mais les rendus tiers tels que Canvas ou Indium doivent ajouter une prise en charge pour eux.

Changements dans Minecraft

Minecraft 1.20 introduit quelques changements importants dans les APIs majeures destinées aux développeurs.

Matériel (ou plutôt l’absence de celui-ci)

Le Matériel était une classe qui indiquait le type de blocs, comme les plantes ou le métal. Cette classe n’existe plus :

• Pour spécifier les propriétés, comme la couleur de la carte et la possibilité de remplacer le bloc, utilisez les paramètres du bloc. Une note sur les nouvelles propriétés solid et notSolid du bloc : ces deux méthodes outrepassent la vérification de bloc solide par défaut. Si un bloc n’est pas spécifié explicitement comme solide ou non solide, le jeu vérifie si la longueur moyenne des côtés de la forme est supérieure à 0,73 ou si le bloc est plus grand qu’un bloc. Si l’une de ces conditions est vraie, le bloc est considéré solide.
• Pour obtenir ces valeurs, utilisez les méthodes de BlockState (vous devrez peut-être refactoriser votre code si votre méthode prend Block au lieu de BlockState).
• Pour vérifier si un bloc est d’un certain type, utilisez les balises de bloc ou instanceof.

Changements connexes :

• BlockSetType a désormais un champ canOpenByHand utilisé par les portes et les trappes.
• Block#canMobSpawnInside prend désormais un BlockState en argument. Auparavant, il n’en prenait aucun.
• BlockState#blocksMovement, qui renvoie true pour tous les blocs solides sauf les toiles d’araignée et les pousses de bambou, a été ajouté.
• La méthode Block.Settings#of a été renommée create. La méthode FabricBlockSettings#of de Fabric API a également été renommée, et l’ancienne méthode a été dépréciée.
• L’objet FabricMaterialBuilder de Fabric API a été supprimé.

Changements dans le monde

L’un des plus grands, mais subtils, changements de cette version est que Entity#world est désormais privé. Utilisez Entity#getWorld ou Entity#getServerWorld à la place.

RedstoneView fournit des méthodes liées à la redstone qui étaient auparavant présentes dans World.

Changements d’écran et de rendu

DrawableHelper, une utilité souvent utilisée en la sous-classant, est maintenant remplacée par un objet passé aux méthodes de rendu : DrawContext. Cela remplace les divers paramètres MatrixStack matrices. Vous n’avez généralement pas besoin de construire un objet DrawContext vous-même.

Les nouvelles méthodes suivantes ont été ajoutées à DrawContext, remplaçant d’autres méthodes à différents endroits :

• setShaderColor (qui enveloppe la méthode RenderSystem existante)
• drawTextWithShadow (remplace TextRenderer#drawWithShadow)
• drawText (qui enveloppe TextRenderer#draw)
• drawTextWrapped
• drawItem
• drawItemWithoutEntity
• drawItemInSlot
• drawItemTooltip
• drawTooltip (remplace Screen#renderTooltip)
• drawHoverEvent

De plus, diverses méthodes de rendu utilisent maintenant DrawContext au lieu de MatrixStack. Si vous avez vraiment besoin du MatrixStack, vous pouvez utiliser DrawContext#getMatrices.

Changements dans Fabric API liés à cela :

• HudRenderCallback de l’API de rendu, ScreenEvents.beforeRender et ScreenEvents.afterRender prennent désormais DrawContext au lieu de MatrixStack.
• Screens.getItemRenderer a été supprimé. Il peut être facilement remplacé par MinecraftClient#getItemRenderer, bien que cela ne soit généralement pas nécessaire.

Et un changement non lié : Screen#passEvents a été supprimé, les écrans ne peuvent donc plus transmettre d’événements.

Changements dans les groupes d’objets

Les ItemGroups sont désormais enregistrés dans un registre. Cela signifie que le jeu de base les gère maintenant à l’aide d’identificateurs, tout comme les blocs et les objets, et ils sont enregistrés de la même manière.

Remarquez que FabricItemGroup#builder ne prend plus d’arguments maintenant, car l’ID est attribué par le registre. Notez que vous devez maintenant appeler displayName manuellement pour éviter les plantages !

ItemGroupEvents.modifyEntriesEvent prend désormais RegistryKey au lieu de ItemGroup ou Identifier. Notez que les champs des ItemGroups vanilla sont maintenant des clés de registre, il suffit donc de recompiler le code pour qu’il fonctionne. Et comme le jeu fournit maintenant l’identificateur, IdentifiableItemGroup a été supprimé.

Enfin, un petit changement de rupture dans Data Generation : FabricLanguageProvider.TranslationBuilder#add prendra désormais RegistryKey au lieu de ItemGroup.

Changements dans ItemStack

Le code modifiant ItemStack doit maintenant utiliser les méthodes combinées (comme copyWithCount) au lieu de 2 appels de méthode (comme copy + setCount) pour gérer correctement les piles vides. ItemStack#copyAndEmpty a été ajouté pour déplacer le contenu d’une pile vers une nouvelle copie.

Quelques méthodes d’égalité dans ItemStack ont été supprimées :

• ItemStack#isItemEqual : utilisez désormais la méthode statique areItemsEqual().
• ItemStack#areNbtEqual : utilisez canCombine (qui vérifie également les objets) ou comparez les NBT vous-même.

Changements dans les récompenses (Loot)

Les prédicats et les modificateurs d’objets (ou, dans les termes anciens, les conditions de butin et les fonctions de butin) sont désormais gérés par LootManager. Ils sont identifiés à l’aide de LootDataKey, similaire à RegistryKey. getTable a été renommé getLootTable et getElement peut être utilisé pour obtenir des tables de butin, des prédicats ou des modificateurs d’objets.

LootContext.Builder a été déplacé vers LootContextParameterSet.Builder et sa méthode parameter a été renommée add. La méthode putDrop a été renommée addDynamicDrop. La méthode getNullable a été renommée getOptional pour plus de cohérence. La graine de l’inventaire de butin est maintenant donnée via supplyInventory.

Autres petits changements notables

• VillagerPlantableRegistry de Fabric Content Registries a été remplacé par ItemTags.VILLAGER_PLANTABLE_SEEDS (balises de données du pack).
• Herobrine a été supprimé.
• RecipeProvider#offerWoolDyeingRecipe et les méthodes similaires ont été fusionnés en offerDyeableRecipes (qui offre également la recoloration).
• ServerCommandSource#sendFeedback prend désormais Supplier au lieu de Text pour des raisons de performances. Ajoutez () -> et cela devrait fonctionner.

Profitez de la mise à jour 1.20 et amusez-vous bien avec Fabric !