Un prédicat à une seule condition n'a pas d'enveloppe, et c'est un vrai changement de structure
Une condition, c'est l'objet lui-même. Deux ou plus sont enveloppées dans all_of ou any_of. Plus les huit types de conditions, et pourquoi l'inversion est une enveloppe plutôt qu'un drapeau.
Un prédicat de datapack est un fichier JSON décrivant une condition, et sa structure change selon le nombre de conditions que vous avez. C'est le point qui piège ceux qui copient un exemple et l'étendent.
Une seule condition n'est pas une liste d'une seule
| conditions | forme produite |
|---|---|
| 0 | {} |
| 1 | l'objet condition lui-même |
| 2+ | { "condition": "minecraft:all_of", "terms": [ … ] } |
Il n'y a pas d'enveloppe autour d'une condition unique. Ajoutez-en une deuxième et tout le fichier change de forme — la condition d'origine devient le premier élément d'un tableau terms sous une nouvelle racine. Tout ce qui lit ou génère ces fichiers doit gérer les deux formes, et un exemple construit à partir d'une seule condition ne vous montre pas la forme dont vous aurez besoin dès que vous en ajouterez une autre.
any_of est le combinateur alternatif : tous les termes doivent passer, ou n'importe lequel d'entre eux.
L'inversion est aussi une enveloppe, pas un drapeau
Il n'existe pas de champ "invert": true. Une condition niée est enveloppée :
{ "condition": "minecraft:inverted", "term": { …the original condition… } }Notez term, au singulier — inverted ne prend exactement qu'un seul élément, là où all_of et any_of prennent un tableau terms. Deux clés d'apparence similaire avec des formes différentes, et l'inversion s'applique par condition, donc un prédicat peut mélanger librement des termes inversés et normaux au sein d'un même all_of.
Les huit types de conditions proposés par le constructeur
entity_properties random_chance
int_value_check random_chance_with_enchanted_bonus
weather_check time_check
location_check match_toolLe jeu compte vingt types de conditions ; voici les huit que couvre le sélecteur du constructeur. Deux d'entre eux ont changé de nom, et le constructeur écrit encore les anciens identifiants — random_chance_with_looting et value_check — que les versions actuelles refusent, donc renommez ces deux-là dans la sortie.
random_chance_with_enchanted_bonus est celui qui mérite qu'on s'y attarde : il prend une chance sans l'enchantement et un enchanted_chance qui évolue avec le niveau d'un enchantement (Butin, dans les tables vanilla elles-mêmes), donc la probabilité dépend de ce que tient le tueur. Cela ne le rend pertinent que là où un tueur existe dans le contexte — c'est une condition de taux de butin, pas une porte aléatoire polyvalente. Le simple random_chance est celui à utiliser partout ailleurs.
int_value_check (et float_value_check) vérifient si un nombre tombe dans un intervalle. Le contrôle de valeur du constructeur propose une source de niveau d'enchantement ou une expression personnalisée que vous éditez dans le JSON à la main après l'avoir copiée.
Les sélecteurs correspondent exactement aux ensembles vanilla
Bon à savoir quand vous vérifiez si un identifiant de biome ou de structure est réel : les listes déroulantes du constructeur ne sont pas un échantillon sélectionné.
- 66 biomes — tous les biomes jusqu'à 26.2 ; le
dappled_forestde 26.3 est absent, donc saisissez-le à la main - 34 structures — de même, jusqu'à 26.2 ; les 18 structures
abandoned_camp_*ajoutées par 26.3 ne sont pas listées - 18 tags de blocs et 15 objets, qui sont bien un sous-ensemble fonctionnel
Cela a été vérifié par rapport aux données de registre du jeu lui-même plutôt que supposé, donc si un identifiant est absent de la liste des biomes ou des structures et ne fait pas partie des ajouts de 26.3, l'identifiant n'existe pas. Pour les tags de blocs et les objets, c'est l'inverse : l'absence signifie seulement que le sélecteur ne le liste pas, et saisir l'identifiant vous-même ne pose aucun problème.