Sortie du resource pack FreeMinecraftModels

FreeMinecraftModels écrit actuellement son pack généré dans output, et non outputs.

Chemins de sortie par défaut

Le plugin reconstruit ce dossier au démarrage et lors de /fmm reload :

plugins/FreeMinecraftModels/output/FreeMinecraftModels

Il zippe ensuite ce dossier dans :

plugins/FreeMinecraftModels/output/FreeMinecraftModels.zip

Ce chemin de zip est celui que ResourcePackManager attend lorsqu'il s'intègre à FreeMinecraftModels.

Ce qui est généré

Le dossier généré inclut toujours :

• pack.mcmeta
• pack.png
• assets/minecraft/atlases/blocks.json
• assets/freeminecraftmodels/... sortie de modèle et texture

FreeMinecraftModels génère des fichiers de définition d'item model sous :

assets/freeminecraftmodels/items

Un chemin hérité de surcharge d'armure de cheval en cuir existe toujours dans le code pour les serveurs antérieurs à 1.21.4, mais le plugin déclare api-version: 1.21.4 : aucun serveur capable de le charger ne prend cette branche.

Sortie du modèle d'affichage (1.21.4+)

Lorsqu'un modèle a un fichier de modèle d'affichage .json voisin (voir Notes sur la création de modèles), FMM copie ce JSON (avec les références de texture réécrites pour correspondre aux textures extraites) dans :

assets/freeminecraftmodels/models/display/{modelId}.json

Il génère également une définition d'item correspondante à :

assets/freeminecraftmodels/items/display/{modelId}.json

Le DisplayModelRegistry suit quels modèles ont des JSONs d'affichage au runtime afin que ItemMeta.setItemModel() puisse être appelé sur les ItemStacks pour leur donner la bonne apparence en main et dans l'inventaire.

Bundle d'entités personnalisées Bedrock

Parallèlement aux ressources du pack Java, FreeMinecraftModels exporte un bundle d'entités personnalisées Bedrock pour chaque modèle converti vers :

plugins/FreeMinecraftModels/output/FreeMinecraftModels/assets/freeminecraftmodels/rspm_bedrock_pack

Chaque modèle apporte ses textures, sa géométrie, son render controller, ses animations, ses animation controllers et sa définition d'entité, le tout sous l'espace de noms freeminecraftmodels: (freeminecraftmodels:<model_id>).

Points à connaître lors de la création :

• Un modèle sans texture est ignoré, avec Skipping Bedrock custom entity export for <id>: model has no textures. dans la console
• L'importateur Java accepte toujours cette définition sans texture ; l'exclusion explicite ne concerne que son entrée dans le bundle d'entités personnalisées Bedrock
• La géométrie Bedrock exclut les os de monture (m_), les os de nom générés (fmm_nametag_bone_*) et hitbox. Les ancrages tag_ créés par l’auteur restent présents, souvent sans cubes.
• Un modèle sans animation exporte tout de même un unique emplacement d'animation idle
• La largeur et la hauteur de hitbox d'exécution de l'entité Bedrock proviennent de l'os hitbox du modèle ; sans lui, elles retombent sur 1.0 x 2.0

Le backend Bedrock nécessite un plugin actif nommé floodgate, Geyser-Spigot ou Geyser. La comparaison ignore la casse, mais pas les différences de nom. Sur un serveur Java seul, FMM exporte toujours les fichiers du bundle sans créer ni faire tourner ce backend.

Sortie conditionnelle d'item pour les arcs et arbalètes

Lorsque FMM détecte un ensemble de modèles d'état d'arc ou d'arbalète (voir Notes sur la création de modèles), il génère un seul JSON de définition d'item pour le modèle _idle qui bascule conditionnellement entre tous les états au niveau du resource pack. Aucun travail de paquet côté serveur n'est nécessaire -- le client gère les transitions d'état nativement.

Sortie d'arc

Pour les arcs, la définition d'item générée utilise minecraft:condition sur using_item avec un minecraft:range_dispatch sur use_duration (échelle 0.05) :

Condition	Modèle utilisé
N'utilise pas l'objet	_idle
Utilise, fallback (vient de commencer)	_draw_start
Utilise, seuil 0.65	_draw_half
Utilise, seuil 0.9	_draw_full

Sortie d'arbalète

Pour les arbalètes, la définition d'item générée utilise minecraft:select sur charge_type. Lorsque chargée (flèche ou roquette), elle affiche le modèle _charged. Le fallback non chargé utilise minecraft:range_dispatch sur crossbow/pull :

Condition	Modèle utilisé
N'utilise pas, non chargé	_idle
Utilise, fallback (vient de commencer)	_draw_start
Utilise, seuil 0.58	_draw_half
Utilise, seuil 1.0	_draw_full
Chargé (flèche ou roquette)	_charged

Emplacement de sortie

La définition d'item conditionnelle générée est écrite à côté des autres définitions d'item à :

assets/freeminecraftmodels/items/display/{baseModelId}_idle.json

Seul le modèle _idle obtient un fichier de définition d'item. Les modèles draw et charged sont référencés à l'intérieur en tant qu'entrées conditionnelles.

Correctifs de compatibilité Minecraft 26.1+

Le générateur de pack applique deux correctifs automatiques de compatibilité pour Minecraft 26.1 et plus récent :

• Clamping UV : les UV de faces sont clampés aux limites en pixels de la texture source elle-même (0–textureWidth / 0–textureHeight) avant d'être remis à l'échelle dans l'espace UV 16x16 de Minecraft. Certains auteurs de .bbmodel laissent des UV négatifs ou surdimensionnés dans les faces — un atlas a été redimensionné, l'autouv a dépassé le bord, etc. — ce que le validator plus strict de 26.1 rejette. Le clamping permet au modèle de se compiler ; une face avec un UV hors limites perd tout au plus quelques pixels de détail de texture.
• Les os vides et les os d'ancrage sont ignorés : un os sans cubes n'écrit aucun JSON de géométrie, écrire une définition d'item model pour lui laisserait donc une référence pendante. 1.21.x tolérait cela silencieusement ; 26.1+ journalise chacun d'eux sous la forme Missing block model: freeminecraftmodels:.... Le générateur ignore désormais à la fois le fichier de géométrie et la définition d'item pour de tels os. Cela couvre également les os hitbox (collision uniquement), les ancrages de position tag_name, les variantes fmm_nametag_bone_* générées automatiquement par FMM, et les os purement enveloppants ou d'ancrage.

Ces correctifs s'appliquent automatiquement ; aucune configuration n'est requise.

remarque

C'est parce que ces os sont ignorés qu'un os de plaque de nom tag_ n'a jamais besoin de cubes — c'est un ancrage de position, et le générateur n'écrit délibérément rien pour lui. Voir Les plaques de nom nécessitent un os tag_.

Sortie déterministe

Le pack généré est stable au niveau des octets : le régénérer à partir de modèles inchangés produit un zip identique, et donc un SHA1 identique.

C'est important car ResourcePackManager saute le re-téléversement d'un pack dont le SHA1 correspond déjà à ce que possède l'hôte distant. Si les octets changent sans arrêt, cette vérification ne correspond jamais, RSPM re-téléverse à chaque redémarrage, et chaque joueur re-télécharge un pack dont le contenu n'a pas changé.

Deux endroits du générateur écrivent le JSON directement sur le disque, l'ordre d'itération de leurs maps est donc l'ordre des octets du fichier :

• les définitions d'item model par os sous assets/freeminecraftmodels/items
• le bloc display du JSON de modèle par os sous assets/freeminecraftmodels/models

Les deux utilisent désormais des maps préservant l'ordre d'insertion. Auparavant, ils utilisaient Map.of, qui repose sur java.util.ImmutableCollections — celui-ci initialise un sel aléatoire par JVM et sonde à partir d'un index dépendant de ce sel, de sorte que la même poignée de clés sortait dans un ordre différent à chaque démarrage du serveur. Des clés comme translation / scale, et type / index / default, échangeaient leur place à chaque démarrage, réécrivant chaque définition d'item et chaque fichier de modèle sans raison.

Si vous avez déjà vu des joueurs re-télécharger le resource pack après chaque redémarrage alors que vous n'aviez rien changé, c'était la cause.

remarque

Le déterminisme ne tient que si votre ensemble de modèles est inchangé. Ajouter, supprimer, renommer ou modifier un modèle change légitimement les octets du pack et doit déclencher un re-téléversement.

Comportement de reload

Lorsque FreeMinecraftModels recharge, il :

• démonte les modèles actifs, les props, les déguisements, les runtimes de scripts, l'état des listeners et les stores de temps de recharge des scripts avant de les reconstruire
• ré-exécute l'étape d'import de contenu
• reconstruit le dossier output/FreeMinecraftModels
• régénère output/FreeMinecraftModels.zip
• dispatche resourcepackmanager reload si ResourcePackManager est installé
• émet FmmReloadedEvent sur le thread principal une fois la nouvelle initialisation terminée, afin que les plugins dépendants puissent recréer leurs attachements de modèle

C'est pourquoi les configurations modernes FMM + ResourcePackManager n'ont plus besoin de l'ancien workflow manuel de copie de zip.