Guide Minecraft sur le CustomModelData

Qu’est-ce que CustomModelData ?

Ajouté dans Minecraft 1.14, CustomModelData permet aux créateurs de packs d’associer différentes textures ou modèles 3D à un objet vanilla avec des identifiants numériques.

Sans tags, une épée en fer ressemble à l’épée vanilla normale.
Avec CustomModelData: 1, elle peut ressembler à un katana.
Avec CustomModelData: 2, elle peut être rendue comme une tronçonneuse 3D.

Pour le serveur et les mécaniques du jeu, cela reste une épée en fer. Seule l’apparence côté client change.

Si vous voulez utiliser CustomModelData sans tout brancher à la main, la combinaison pratique du site est la suivante : le générateur de packs de ressources pour la partie visuelle et le constructeur d’objets personnalisés pour la commande.

Comment ça marche

Le pack de ressources utilise des overrides de modèles d’objets. Le modèle de base indique au jeu de charger un autre modèle quand une valeur CustomModelData précise est présente.

{
  "parent": "item/handheld",
  "textures": { "layer0": "item/iron_sword" },
  "overrides": [
    { "predicate": { "custom_model_data": 1 }, "model": "item/custom_katana" },
    { "predicate": { "custom_model_data": 2 }, "model": "item/custom_chainsaw" }
  ]
}

NBT contre Components

Minecraft 1.20.5 a remplacé l’ancienne syntaxe NBT des objets par les Data Components. Le résultat visuel est similaire, mais les commandes ont changé.

Avant 1.20.5

/give @p minecraft:iron_sword{CustomModelData:1} 1

1.20.5 et plus récent

/give @p minecraft:iron_sword[minecraft:custom_model_data=1] 1

Le générateur de packs de ressources Minecraft tient compte de ce changement quand il affiche les commandes give pour vos objets personnalisés.

Pourquoi CustomModelData reste important même après les composants

Quand on entend parler du grand basculement vers les Data Components, il est facile d’imaginer que CustomModelData appartient surtout au vieux Minecraft. En pratique, le problème visuel n’a jamais disparu. Un seul objet vanilla doit encore pouvoir devenir un laissez-passer, une relique, une monnaie, une preuve de quête, un stock de boutique ou une arme inhabituelle. CustomModelData reste donc l’un des ponts les plus propres entre ce besoin de gameplay et la couche artistique du resource pack.

Ce qui a changé, ce n’est pas l’idée de base, mais l’écosystème autour. Les anciens workflows demandaient souvent à un seul nombre de porter l’art, l’identité logique, la documentation et même la mémoire de l’équipe. Les setups modernes sont plus solides quand les rôles sont séparés. Le pack décide de l’apparence. La commande et les données cachées décident de ce à quoi le serveur fait confiance. Une fois cette séparation comprise, CustomModelData cesse d’être un “truc obscure” et devient un contrat clair entre image et logique.

Un workflow pratique: de l’art à l’objet réellement jouable

1. Commencer par le plan visuel

Il faut d’abord savoir ce que l’objet doit montrer dans la main ou l’inventaire du joueur. Si l’item a besoin d’une icône, d’une texture ou d’un modèle 3D spécifique, cela commence dans le pack. Le générateur de packs est utile ici parce qu’il construit les dossiers et la plomberie JSON sans vous obliger à recâbler chaque fichier à la main.

2. Donner ensuite une identité cachée stable

Pour un vrai serveur, le crochet visuel seul ne suffit presque jamais. Un permis, un jeton, un contrat ou une relique ont souvent besoin d’un ID caché que les quêtes, marchands et scripts peuvent lire sans ambiguïté. C’est là que le Custom Item Builder devient pratique: la logique de commande reste lisible au lieu de s’effondrer dans un nombre mystérieux.

3. Choisir la bonne syntaxe pour la bonne version

Avant la 1.20.5, les données d’objets vivaient dans l’ancien monde NBT. Ensuite elles ont migré vers les composants, et en 1.21.4+ la couche visuelle peut devenir encore plus riche grâce aux nouvelles routes de modèles et aux slots étendus de custom_model_data. Si la version n’est pas la bonne, l’idée de l’objet peut être correcte et la commande échouer quand même.

4. Tester l’objet avant de le brancher à de gros systèmes

Faites apparaître l’objet une première fois, vérifiez le nom, vérifiez le rendu du resource pack, puis seulement après connectez-le à des échanges, des récompenses de quête, du loot ou des scripts. Cet ordre évite de déboguer trois systèmes en même temps quand le vrai problème est encore juste l’item lui-même.

Erreurs fréquentes autour de CustomModelData

Demander à un seul nombre de devenir tout le système

L’erreur classique consiste à faire porter à une seule valeur CustomModelData la route visuelle, l’identité cachée, la convention de documentation et l’aide-mémoire de l’équipe. Cela casse mal dès que la bibliothèque d’objets grandit et que plus personne ne sait ce que signifiait l’ancien nombre.

Construire la commande avant que la route visuelle n’existe vraiment

Un objet est beaucoup plus facile à déboguer quand le chemin de modèle, l’intention artistique et le fallback sont déjà décidés. Sinon, la commande peut fonctionner techniquement alors que le joueur voit toujours la mauvaise icône — et l’on croit à tort que “CustomModelData est cassé”.

Copier des exemples entre différentes époques de syntaxe

Une grande partie des exemples de forums appartiennent encore à des générations de commandes plus anciennes. Si vous collez du NBT legacy dans un environnement à composants, ou l’inverse, la commande casse même si l’idée générale reste bonne. C’est l’une des raisons pour lesquelles un builder visuel aide tant: il garde l’époque de syntaxe visible.

Penser que CustomModelData suffit à lui seul pour la confiance côté serveur

CustomModelData parle d’abord de rendu. Un vrai serveur RP a souvent aussi besoin d’IDs cachés, de noms lisibles et de données auxiliaires pour les scripts. Les meilleurs setups laissent l’apparence au pack et la validation à la logique serveur.

FAQ rapide

Faut-il encore CustomModelData dans les nouvelles versions?

Oui, dès qu’un même objet vanilla doit se ramifier en plusieurs apparences. La syntaxe autour a changé, mais le problème visuel de base n’a pas disparu.

Quel est le duo pratique sur ce site pour travailler avec lui?

Le générateur de packs s’occupe de la partie visuelle, et le constructeur d’objets personnalisés s’occupe de la commande et de la logique cachée. Ensemble, ils couvrent le workflow le plus fréquent.

Est-ce que cela sert seulement pour les armes?

Non. C’est tout aussi utile pour des permis, badges de guilde, monnaies, lettres, reliques, props de quête, jetons, nourriture décorative ou stock de marchands. Les armes sont simplement les exemples les plus faciles à reconnaître.

Que vérifier d’abord si l’objet ne s’affiche pas correctement?

Le chemin dans le pack, le lien vers le modèle, la syntaxe adaptée à la bonne version et la valeur effectivement attachée à l’objet. Dans beaucoup de cas, l’idée est bonne, mais l’un de ces ponts n’est tout simplement pas relié.

Guide Minecraft sur le CustomModelData : définition et fonctionnement