Un predicado con una sola condición no tiene envoltorio, y eso es un cambio de forma real
Una condición es el objeto en sí. Dos o más se envuelven en all_of o any_of. Además, los ocho tipos de condición, y por qué invertir es un envoltorio en lugar de una bandera.
Un predicado de datapack es un archivo JSON que describe una condición, y su estructura cambia según cuántas condiciones tengas. Esa es la parte que hace tropezar a quien copia un ejemplo y lo amplía.
Una no es una lista de una
| condiciones | forma de salida |
|---|---|
| 0 | {} |
| 1 | el propio objeto de condición |
| 2+ | { "condition": "minecraft:all_of", "terms": [ … ] } |
No hay ningún envoltorio alrededor de una sola condición. Añade una segunda y el archivo entero cambia de forma: la condición original pasa a ser el primer elemento de un array terms bajo una raíz nueva. Todo lo que lea o genere estos archivos tiene que manejar ambas formas, y un ejemplo construido con una sola condición no te muestra la forma que necesitarás en el momento en que añadas otra.
any_of es el combinador alternativo: todos los términos deben pasar, o cualquiera de ellos.
Invertir también es un envoltorio, no una bandera
No existe ningún campo "invert": true. Una condición negada se envuelve:
{ "condition": "minecraft:inverted", "term": { …the original condition… } }Fíjate en term, en singular: inverted acepta exactamente uno, mientras que all_of y any_of aceptan un array terms. Dos claves de aspecto similar con formas distintas, y la inversión se aplica por condición, así que un predicado puede mezclar términos invertidos y normales libremente dentro de un mismo all_of.
Los ocho tipos de condición que ofrece el constructor
entity_properties random_chance
int_value_check random_chance_with_enchanted_bonus
weather_check time_check
location_check match_toolEl juego tiene veinte tipos de condición; estos son los ocho que cubre el selector del constructor. Dos de ellos cambiaron de nombre, y el constructor sigue escribiendo los ids antiguos —random_chance_with_looting y value_check—, que las versiones actuales rechazan, así que renombra esos dos en la salida.
random_chance_with_enchanted_bonus es el que merece una pausa: acepta una probabilidad sin el encantamiento y un enchanted_chance que escala con el nivel de un encantamiento (Botín, en las propias tablas del vanilla), así que la probabilidad depende de lo que lleve el asesino. Eso lo hace significativo solo donde existe un asesino en el contexto: es una condición de tasa de drop, no una puerta aleatoria de propósito general. El random_chance simple es al que hay que recurrir en todos los demás casos.
int_value_check (y float_value_check) comprueban si un número cae dentro de un rango. La comprobación de valores del constructor ofrece una fuente de nivel de encantamiento o una expresión personalizada que editas en el JSON a mano después de copiar.
Los selectores son exactamente los conjuntos del vanilla
Vale la pena saberlo cuando compruebas si un id de bioma o de estructura es real: los desplegables del constructor no son una muestra seleccionada.
- 66 biomas: todos los biomas hasta 26.2; falta el
dappled_forestde 26.3, así que escríbelo a mano - 34 estructuras: igualmente hasta 26.2; las 18 estructuras
abandoned_camp_*que añadió 26.3 no aparecen en la lista - 18 etiquetas de bloque y 15 de objeto, que sí son un subconjunto funcional
Eso se verificó contra los propios datos de registro del juego en lugar de darlo por supuesto, así que si un id no está en la lista de biomas o estructuras y no es una de las adiciones de 26.3, el id no existe. Para las etiquetas de bloque y los objetos es lo contrario: que no aparezca significa solo que el selector no lo lista, y escribir el id tú mismo es perfectamente válido.