Sortie du resource pack FreeMinecraftModels

FreeMinecraftModels écrit son pack généré dans output.

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.

La génération supprime tout le contenu de output, à l'exception du dernier FreeMinecraftModels.zip publié, puis le reconstruit. Conservez vos modèles sources et vos autres fichiers ailleurs. Si FMM ne parvient pas à vider le dossier, la génération échoue avec Failed to prepare output folder et FMM ne termine pas son initialisation.

Ce qui est généré

La génération copie les métadonnées, l'icône et l'atlas fournis avec le plugin, puis ajoute les modèles et textures chargés :

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

Une ressource fournie manquante, ou un dossier que FMM ne peut pas créer, fait échouer la génération. Un échec d'écriture des fichiers d'un modèle est journalisé et la génération continue : vérifiez donc la console autant que la sortie. Avant de créer le ZIP, FMM ajoute des entrées explicites à l'atlas pour ses textures d'entités, textures de particules comprises, et remplace sa source d'atlas fondée sur le répertoire des entités. Les autres sources sont conservées. Une erreur de lecture ou d'écriture de l'atlas fait échouer la génération.

FreeMinecraftModels génère les fichiers de définition des modèles d'objets 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 possède un fichier d'affichage .json voisin valide (voir Notes sur la création de modèles), FMM traite sa table textures et l'écrit dans :

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

Il génère également une définition d'objet correspondante dans :

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

Les valeurs de texture avec un espace de noms restent inchangées. Les autres sont résolues par indice numérique de texture, avec une texture extraite disponible comme solution de repli. Un JSON d'affichage mal formé produit un avertissement et n'est pas enregistré. Le registre permet à FMM d'attribuer le modèle traité à l'apparence d'un objet en main et dans l'inventaire.

Sprites de particules

Pour chaque effet de particules utilisé par un modèle, FMM écrit la texture de l'effet et un modèle d'objet plat par sprite :

assets/freeminecraftmodels/textures/entity/fmm_particles/{modelId}/{effect}.png
assets/freeminecraftmodels/models/particle/{modelId}/{effect}/{index}.json
assets/freeminecraftmodels/items/particle/{modelId}/{effect}/{index}.json

Seuls les joueurs Java voient ces sprites. Les joueurs Bedrock reçoivent l'effet sous forme de particule native issue de l'ensemble Bedrock décrit ci-dessous.

Fichiers annexes pour ResourcePackManager

FMM écrit de petits fichiers JSON que ResourcePackManager lit pendant la conversion du pack pour Bedrock. Ils n'ont aucun effet sur les clients Java.

Fichier	Écrit lorsque	Rôle
assets/freeminecraftmodels/rspm_item_bases/display/{modelId}.json	Le modèle possède un modèle d'affichage et son .yml voisin définit un material connu du serveur. Un suffixe de teinture de cuir tel que LEATHER_CHESTPLATE:ff8800 empêche l'écriture du fichier	Indique l'objet vanilla sur lequel repose l'objet personnalisé, par exemple minecraft:blaze_rod, pour que Bedrock affiche le modèle sur le bon objet de base au lieu d'un objet deviné à partir du nom de fichier
assets/freeminecraftmodels/rspm_item_particles/display/{modelId}.json	Le modèle possède un modèle d'affichage et une animation comportant des images clés de particules	Liste les effets, les locators et la timeline de particules en boucle que ResourcePackManager ajoute à l'attachable Bedrock de l'objet
assets/freeminecraftmodels/rspm_item_java_only/particle/{modelId}/{effect}.json	Le modèle utilise un effet de particules	Indique à ResourcePackManager de ne pas transformer les objets sprites de cet effet en objets personnalisés Bedrock

Tant que particleEffectsEnabled vaut false, FMM n'écrit ni les fichiers rspm_item_particles ni les fichiers de particules Bedrock. Les sprites de particules Java et leurs fichiers rspm_item_java_only sont tout de même écrits.

Ensemble d'entités personnalisées Bedrock

Parallèlement aux ressources du pack Java, FreeMinecraftModels tente d'exporter un ensemble d'entités personnalisées Bedrock pour chaque modèle chargé avec des textures vers :

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

Chaque modèle fournit ses textures, sa géométrie, son contrôleur de rendu, ses animations, ses contrôleurs d'animation et sa définition d'entité dans l'espace de noms freeminecraftmodels: (freeminecraftmodels:<model_id>). Un modèle comportant des effets de particules fournit aussi particles/<model_id>_<effect>.json (identifiant fmm:<model_id>_<effect>) et, lorsque FMM a trouvé la texture de l'effet, textures/entity/fmm_particles/<model_id>/<effect>.png. Voir Particules.

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 géométrie d'un modèle est suspendue à un os généré freeminecraftmodels_lean, sauf si le modèle compte plus de 672 animations. Cet os montre aux joueurs Bedrock l'orientation de déplacement et le centrage. Les canaux d'animation contenant des keyframes MoLang sont écrits tels que créés : les clients Bedrock les évaluent donc eux-mêmes
• 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

Un groupe hitbox vide a des dimensions nulles ; il n'utilise pas ces valeurs de repli. Le préfixe b_ masque le rendu Java, mais n'est pas filtré dans la géométrie Bedrock. L'export des animations Bedrock n'intègre pas la solution IK calculée par FMM à l'exécution ; voir Animations. Les erreurs d'export sont journalisées et peuvent laisser un ensemble incomplet.

Le backend Bedrock nécessite un plugin actif nommé floodgate, Geyser-Spigot ou Geyser. Ce contrôle ignore la casse. La détection individuelle des joueurs vérifie séparément Floodgate ou Geyser-Spigot ; l'activation du backend ne prouve ni la détection des joueurs ni la livraison du pack. Sur un serveur Java seul, FMM exporte toujours les fichiers sans créer ni faire tourner ce backend.

Définitions conditionnelles d'objets pour les arcs et arbalètes

Lorsque FMM détecte un ensemble complet de modèles d'état d'arc ou d'arbalète chargés avec leurs JSON d'affichage enregistrés (voir les notes sur la création de modèles), il génère une définition d'objet sous l'ID de base du modèle. Cette définition change d'état sur le client. L'objet configuré doit utiliser le matériau BOW ou CROSSBOW approprié.

Sortie des arcs

Pour les arcs, la définition d'objet générée utilise minecraft:condition sur using_item et minecraft:range_dispatch sur use_duration, avec une échelle de 0.05 :

Condition	Modèle utilisé
N'utilise pas l'objet	_idle
Utilisation commencée, valeur de repli	_draw_start
Utilise, seuil 0.65	_draw_half
Utilise, seuil 0.9	_draw_full

Sortie des arbalètes

Pour les arbalètes, la définition d'objet générée utilise minecraft:select sur charge_type. Une arbalète chargée d'une flèche ou d'une fusée affiche _charged. Le cas de repli non chargé utilise minecraft:range_dispatch sur crossbow/pull :

Condition	Modèle utilisé
N'utilise pas, non chargé	_idle
Utilisation commencée, valeur de repli	_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 conditionnelle de l'objet est écrite à côté des autres définitions d'objets, dans :

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

L'ID de base devient l'objet d'affichage public. Les définitions d'objet des états individuels sont supprimées de la sortie et du registre ; leur géométrie d'affichage reste présente, car la définition conditionnelle la référence.

Correctifs de compatibilité Minecraft 26.1+

Le générateur de pack applique ces correctifs sur toutes les versions prises en charge, y compris Minecraft 26.1 et les versions ultérieures :

• Limitation des UV : les UV des faces sont ramenés aux limites UV de la texture (0–textureWidth / 0–textureHeight) avant leur conversion vers l'espace UV 16x16 de Minecraft. Ces limites utilisent les métadonnées UV de la texture si elles existent, sinon les dimensions de l'image ou la résolution de repli du modèle. Limiter les coordonnées négatives ou excessives peut réduire les détails de texture sur la face concernée.
• 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

Un ancrage de plaque de nom tag_ n'a pas besoin de cubes. Les ancrages sans cubes ne produisent aucune géométrie ; le préfixe seul ne masque pas tous les os créés avec des cubes. L'os nommé exactement tag_name reçoit un traitement particulier. Consultez les ancrages des plaques de nom.

Sortie déterministe

FMM réduit les changements inutiles en utilisant des tables qui conservent l'ordre d'insertion pour les définitions d'objet par os et les blocs display des modèles. Le code d'écriture ZIP fixe également les horodatages des entrées.

Des octets ZIP identiques ne sont pas garantis : les répertoires sont parcourus dans l'ordre du système de fichiers, sans tri des entrées. Les changements de modèles, textures, JSON d'affichage, configuration ou versions du générateur et du serveur peuvent aussi modifier légitimement le pack.

Si l'empreinte du pack change de façon inattendue, comparez le contenu et l'ordre des entrées de l'archive ainsi que les données de génération. Un téléchargement répété ne suffit pas à identifier la cause.

Comportement du rechargement

Pour /fmm reload, FMM importe d'abord le contenu et prépare les catalogues candidats d'objets, d'enchantements et de recettes, tout en gardant l'exécution actuelle active. Si cette préparation échoue, il rejette le rechargement et conserve le catalogue actuel. Après une préparation réussie, il :

• supprime les modèles actifs, les props, les déguisements, les instances de scripts, l'état des écouteurs et les données de temps de recharge des scripts avant de les reconstruire
• recharge la configuration et les recettes
• reconstruit le dossier output/FreeMinecraftModels
• régénère output/FreeMinecraftModels.zip
• exécute resourcepackmanager reload si ResourcePackManager est actif
• programme FmmReloadedEvent sur le thread principal 40 ticks plus tard, afin que les plugins dépendants puissent recréer leurs attachements de modèle

FMM écrit d'abord l'archive dans output/FreeMinecraftModels.zip.pending, puis la déplace pour remplacer FreeMinecraftModels.zip. Si l'écriture ou le déplacement échoue, la génération échoue et l'ancien ZIP reste en place. Un ZIP complet ne prouve pas sa livraison : vérifiez donc aussi la livraison par ResourcePackManager et l'acceptation par le client. Consultez Configuration pour distinguer un rechargement complet d'une actualisation du contenu importé.