Predykat z jednym warunkiem nie ma otoczki i to jest realna zmiana kształtu
Jeden warunek to sam obiekt. Dwa lub więcej zostają opakowane w all_of lub any_of. Do tego osiem typów warunków i dlaczego negacja to otoczka, a nie flaga.
Plik predykatu w datapacku to JSON opisujący warunek, a jego struktura zmienia się w zależności od liczby warunków. To właśnie ten element gubi ludzi, którzy kopiują przykład i go rozbudowują.
Jeden to nie lista z jednym elementem
| warunki | kształt wyniku |
|---|---|
| 0 | {} |
| 1 | sam obiekt warunku |
| 2+ | { "condition": "minecraft:all_of", "terms": [ … ] } |
Wokół pojedynczego warunku nie ma żadnej otoczki. Dodaj drugi, a cały plik zmienia kształt — pierwotny warunek staje się pierwszym elementem tablicy terms pod nowym korzeniem. Wszystko, co takie pliki czyta lub generuje, musi obsługiwać obie formy, a przykład zbudowany z jednego warunku nie pokaże ci kształtu, którego będziesz potrzebować w chwili, gdy dodasz kolejny.
any_of to alternatywny kombinator: przejść muszą wszystkie warunki albo dowolny z nich.
Negacja to też otoczka, a nie flaga
Nie ma pola "invert": true. Zanegowany warunek jest opakowany:
{ "condition": "minecraft:inverted", "term": { …the original condition… } }Zwróć uwagę na term w liczbie pojedynczej — inverted przyjmuje dokładnie jeden, podczas gdy all_of i any_of przyjmują tablicę terms. Dwa podobnie wyglądające klucze o różnych kształtach, a negacja działa na pojedynczy warunek, więc predykat może swobodnie mieszać zanegowane i zwykłe warunki w obrębie jednego all_of.
Osiem typów warunków oferowanych przez builder
entity_properties random_chance
int_value_check random_chance_with_enchanted_bonus
weather_check time_check
location_check match_toolGra ma dwadzieścia typów warunków; to jest osiem, które obejmuje selektor w builderze. Dwa z nich zmieniły nazwę, a builder nadal zapisuje stare identyfikatory — random_chance_with_looting i value_check — których obecne wersje nie przyjmują, więc zmień nazwy tych dwóch w wyniku.
random_chance_with_enchanted_bonus to ten, nad którym warto się zatrzymać: przyjmuje szansę bez zaklęcia oraz enchanted_chance, który skaluje się z poziomem zaklęcia (Grabież w tabelach vanilla), więc prawdopodobieństwo zależy od tego, co trzyma zabójca. Ma to sens tylko tam, gdzie w danym kontekście istnieje zabójca — to warunek szansy na wypadnięcie przedmiotu, a nie uniwersalna losowa bramka. Wszędzie indziej sięgaj po zwykły random_chance.
int_value_check (oraz float_value_check) sprawdzają, czy liczba mieści się w przedziale. Sprawdzanie wartości w builderze oferuje źródło poziomu zaklęcia albo własne wyrażenie, które po skopiowaniu ręcznie wpisujesz do JSON-a.
Selektory to dokładnie zestawy vanilla
Warto o tym wiedzieć, gdy sprawdzasz, czy identyfikator biomu lub struktury jest prawdziwy: listy rozwijane w builderze nie są wyselekcjonowaną próbką.
- 66 biomów — każdy biom do 26.2; brakuje
dappled_forestz 26.3, więc wpisz go ręcznie - 34 struktury — podobnie, do 26.2; 18 struktur
abandoned_camp_*dodanych w 26.3 nie ma na liście - 18 tagów bloków i 15 przedmiotów, które są działającym podzbiorem
Zostało to zweryfikowane na podstawie danych rejestru samej gry, a nie założone, więc jeśli identyfikatora nie ma na liście biomów lub struktur i nie jest jednym z dodatków z 26.3, to ten identyfikator nie istnieje. W przypadku tagów bloków i przedmiotów jest odwrotnie: brak na liście oznacza tylko, że selektor go nie wyświetla, i samodzielne wpisanie identyfikatora jest w porządku.