Référence
Structure d’un resource pack Minecraft
Quand un pack commence à grandir, la confusion arrive souvent avant la finition. Les textures tombent dans le mauvais dossier, les modèles pointent vers les mauvais fichiers, les couches d’armure prennent des noms incohérents et les nouvelles item definitions de 1.21.4 se mélangent aux vieilles habitudes. Cette page sert de carte rapide: où mettre les fichiers, comment les nommer et quelle structure reste saine aujourd’hui.
Les dossiers les plus utiles
La majorité du travail concret tourne autour d’un petit nombre de dossiers. Si vous remplacez une face de bloc, ajoutez un objet personnalisé, montez un blockstate ou exportez des couches d’armure, ce sont ces chemins qu’il faut garder sous la main.
| Type | Chemin du pack | Exemple |
|---|---|---|
| Texture d’objet | assets/minecraft/textures/item | diamond_sword.png |
| Texture de bloc | assets/minecraft/textures/block | oak_planks.png |
| Modèle d’objet | assets/minecraft/models/item | custom_diamond_sword_1.json |
| Blockstate | assets/minecraft/blockstates | crafting_table.json |
| Couche d’armure | assets/minecraft/textures/models/armor | diamond_layer_1.png |
| Item definition 1.21.4+ | assets/minecraft/items | diamond_sword.json |
Ce qui change après 1.21.4
Beaucoup de vieux tutoriels partent du principe que toute la logique d’un objet custom reste enfermée dans models/item et sa chaîne d’overrides. Ce n’est plus toute l’histoire. Dans les versions récentes, les item definitions ont leur propre place dans assets/minecraft/items. Cela change la manière de penser l’objet: la texture, le modèle et la définition deviennent trois couches distinctes.
Les anciens dossiers restent utiles. Les textures vivent toujours sous textures. Les modèles restent nécessaires. Mais si vous montez un pack pour 1.21.4+, il vaut mieux garder en tête cette architecture en trois temps au lieu de tout comprimer dans une seule habitude héritée des overrides.
Un ordre de montage pratique
Le cycle de travail le plus propre reste presque toujours le même. On crée ou exporte le PNG. On le place dans le bon dossier. On branche ensuite le modèle ou l’item definition. Puis on vérifie le résultat dans le générateur ou dans le jeu. Quand cet ordre casse, le pack se transforme vite en collection de noms presque semblables et de chemins contradictoires.
- Préparer le PNG.
- Le placer dans le bon dossier de textures.
- Créer ou mettre à jour le JSON du modèle.
- Si la version est 1.21.4+, écrire le fichier dans
assets/minecraft/items. - Tester le résultat avant d’empiler l’asset suivant.
Les erreurs de nommage les plus fréquentes
Les pannes les plus courantes sont souvent très simples: un bloc est nommé comme un item, un JSON vise item/foo alors que le PNG vit dans textures/block, un fichier contient des majuscules ou des espaces, ou bien le chemin existe mais ne correspond pas à la référence écrite dans le modèle. La routine la plus sûre reste d’utiliser uniquement des minuscules, des underscores et une base de nom partagée entre les fichiers liés.
Où aller après cette page
Si vous vouliez simplement la carte des dossiers, cette référence suffit. Si vous êtes en train de construire un pack, la suite logique est souvent le guide du générateur, l’article sur CustomModelData et les guides de migration vers 1.21.4. C’est là que cette structure se transforme en workflow réel.