Pensez d’abord à la décision, ensuite au fichier
En 1.21.4+, une item definition n’est pas un gros JSON pour le principe. C’est une réponse à une question simple : l’objet garde-t-il toujours la même apparence, bascule-t-il selon une propriété, passe-t-il des seuils numériques, ou réagit-il à un état vrai/faux ? Quand cette question est claire, la structure du fichier devient beaucoup moins intimidante.
C’est précisément là que le builder aide. Il ne vous invente pas une logique artificielle. Il garde l’enveloppe légère, affiche le chemin cible très tôt et vous pousse vers le type de branche qui correspond réellement au besoin au lieu de celui qui rappelle l’ancien workflow des overrides.
Une carte mentale rapide avant le premier clic
| Branche | À utiliser quand | Signal principal |
|---|---|---|
minecraft:model | L’objet n’a besoin que d’une seule apparence fixe. | En réalité, il n’y a pas de vraie arborescence. |
minecraft:select | Une propriété nommée choisit entre plusieurs branches. | Vous pouvez décrire les états avec des mots comme pass, relic, broken, ritual. |
minecraft:range_dispatch | Une valeur numérique franchit des seuils. | L’objet a des stades, une charge, une usure ou une progression. |
minecraft:condition | Le résultat dépend d’un vrai/faux. | L’objet est sélectionné, utilisé, endommagé ou binaire par nature. |
Exemple concret : une relique, trois états visibles
Imaginez un objet d’histoire qui doit rester scellé la plupart du temps, briller pendant un rituel, puis se fissurer après l’événement. Ce n’est pas trois fichiers sans lien. C’est un seul arbre de décision. Si l’état vient d’une valeur custom de type chaîne, vous êtes déjà très probablement dans le territoire de
select.Le builder est utile parce qu’il garde cet arbre lisible : vous choisissez d’abord le type de branche, vous posez le fallback, puis vous ajoutez les états nommés. La difficulté n’est pas de taper. La difficulté est que l’équipe puisse encore relire ce fichier calmement une semaine plus tard.
Un workflow sûr dans le builder
- Définissez d’abord le chemin du fichier dans
assets/<namespace>/items/. - Choisissez le plus petit type de branche qui décrit vraiment l’objet.
- Fixez le fallback avant les variantes plus sophistiquées.
- Utilisez les quick starts si vous savez déjà que vous partez sur un model direct, un switch d’état ou une échelle de seuils.
- Copiez le JSON, testez un objet en jeu, puis seulement ensuite réutilisez le motif ailleurs dans le pack.
Quand passer à un autre outil
Le item model builder gère la couche visuelle de la definition. Si vous avez encore besoin de la commande qui donne l’objet au joueur, passez au custom item builder. Si les textures et modèles doivent encore être emballés dans un resource pack prêt à l’emploi, terminez le travail dans le générateur de packs.
Cette séparation est saine. Un fichier visuel reste plus facile à relire et à déboguer quand la commande et l’emballage du pack ne se battent pas pour la même place.
Erreurs fréquentes
- Choisir
selectpar réflexe moderne alors qu’un simplemodelaurait suffi. - Oublier le fallback et rendre le fichier plus opaque dès la première ligne.
- Mélanger attentes numériques et états nommés sans décider quelle propriété pilote réellement le rendu.
- Nommer le JSON, le chemin du modèle et le nom interne d’équipe de façon si différente que plus personne ne voit le lien.
- Copier la structure sur dix objets avant d’avoir validé un seul exemple en jeu.
FAQ
Faut-il toujours utiliser select dès qu’il y a du CustomModelData ?
Non. Si l’objet n’a qu’une seule identité visuelle, un fichier model direct est plus propre. select sert quand une definition doit réellement se ramifier.
Quand range_dispatch devient-il le meilleur choix ?
Dès que la variation est ordonnée et numérique : usure, charge, progression ou tout état fondé sur des seuils.
Pourquoi commencer par le fallback ?
Parce que le fallback est la lecture calme de base. Quand ce point d’ancrage est juste, toutes les autres branches sont plus faciles à juger.
Peut-on séparer la commande item du fichier de définition ?
Oui, et c’est même l’un des grands avantages du nouveau système. Le fichier visuel n’a pas besoin de porter la logique de commande.
Et si je veux seulement un pass simple basé sur du paper ?
Alors un fichier minecraft:model direct suffit presque toujours. Inutile de gonfler l’arbre de décision si le besoin reste simple.