Guides / Commandes et données

Enchantements personnalisés sans mods : le format d'enchantement piloté par les données

Les enchantements sont devenus des JSON de datapack, donc un enchantement personnalisé ne nécessite aucun mod. Voici la structure du fichier, les composants d'effet qui font réellement quelque chose, et comment le rendre obtenable.

2026-07-02

Les enchantements étaient autrefois codés en dur. Ils sont désormais des données de datapack, ce qui signifie qu'un enchantement réellement personnalisé — nouveau nom, nouvel effet, nouvelle courbe de coût — est un fichier JSON.

Où il se trouve

data/<namespace>/enchantment/lightning_strike.json

Au singulier enchantment/, comme toutes les autres catégories de datapack depuis le renommage.

Le fichier minimal

{
  "description": { "translate": "enchantment.my_pack.lightning_strike" },
  "supported_items": "#minecraft:enchantable/melee_weapon",
  "weight": 2,
  "max_level": 3,
  "min_cost": { "base": 10, "per_level_above_first": 10 },
  "max_cost": { "base": 50, "per_level_above_first": 10 },
  "anvil_cost": 4,
  "slots": ["mainhand"]
}

Cela suffit à obtenir un véritable enchantement qui se charge et s'affiche sur l'objet. Il ne fait encore rien — le comportement est séparé — et la table ne le proposera pas tant qu'il n'aura pas été étiqueté (voir ci-dessous).

• weight est la rareté à la table d'enchantement. Le vanilla utilise 10 pour commun, 1 pour très rare. C'est relatif, pas un pourcentage.
• slots détermine où l'enchantement est actif : mainhand, offhand, armor, head, etc. Il est obligatoire : omettez-le et le fichier ne se charge pas.
• supported_items accepte une étiquette d'objet ou une liste. Les étiquettes #minecraft:enchantable/* existent déjà pour les groupes pertinents — melee_weapon, sharp_weapon, mining, armor, etc. Il n'y a pas de enchantable/sword ; une étiquette qui n'existe pas fait échouer le fichier.

Le faire agir

effects attache un comportement :

"effects": {
  "minecraft:post_attack": [{
    "enchanted": "attacker",
    "affected": "victim",
    "effect": { "type": "minecraft:run_function", "function": "my_pack:strike" },
    "requirements": { "condition": "minecraft:random_chance", "chance": 0.25 }
  }]
}

post_attack doit savoir à qui appartient l'enchantement (enchanted) et sur qui l'effet retombe (affected) — les deux sont obligatoires. run_function est la porte de sortie — tout ce qu'une fonction peut faire, l'enchantement peut le faire. Les types d'effet intégrés couvrent les dégâts, le recul, la durabilité, les butins et les attributs sans avoir besoin d'une fonction, et ils sont moins coûteux.

requirements accepte n'importe quel prédicat, donc conditionner sur le type de la cible, la météo ou une chance aléatoire ne demande qu'un bloc de JSON.

Le nommer

description est un composant textuel, donc un nom codé en dur fonctionne :

"description": { "text": "Lightning Strike", "color": "gold" }

mais une clé translate accompagnée d'un fichier de langue dans un pack de ressources est ce qui lui permet de s'afficher correctement pour les joueurs d'autres langues — la même raison pour laquelle ce site reprend les termes de jeu des traductions de Mojang.

Le rendre obtenable

Trois voies, et vous en voulez généralement plus d'une :

• Table d'enchantement — une fois weight et la courbe de coût définis et l'enchantement dans #minecraft:in_enchanting_table.
• Tables de butin — enchant_randomly avec votre enchantement listé, ou enchant_with_levels s'il doit rivaliser sur le coût.
• Villageois qui échange — un livre enchanté contenant votre enchantement dans l'objet de l'échange.

L'ajouter à #minecraft:in_enchanting_table est ce qui fait que la table le propose tout court ; l'étiquette est facile à oublier et produit un enchantement qui existe mais n'apparaît jamais.

Construisez le JSON de l'enchantement et son équivalent de motif d'armure, avec les étiquettes et les emplacements définis, dans le Custom Enchantment & Trim Builder.

Enchantements et garnitures personnalisés →