条件が1つの述語にラッパーは付かない、そしてそれは実際の形状変化である
条件が1つならオブジェクトそのもの。2つ以上ならall_ofかany_ofでラップされる。さらに8つの条件タイプ、そして反転がフラグではなくラッパーである理由。ゲームには20種類の条件があり、そのうち2つは古いIDで手動修正が必要です。
データパックの述語（predicate）は条件を記述するJSONファイルであり、その構造は条件の数によって変化します。ここが、サンプルをコピーして拡張しようとする人がつまずくポイントです。
1つは「1つのリスト」ではない
| 条件の数 | 出力される形状 |
|---|---|
| 0 | {} |
| 1 | 条件オブジェクトそのもの |
| 2以上 | { "condition": "minecraft:all_of", "terms": [ … ] } |
単一の条件にラッパーは付きません。2つ目を追加するとファイル全体の形状が変わり、元の条件は新しいルートの下にあるterms配列の最初の要素になります。これを読み取ったり生成したりするものは両方の形式に対応する必要があり、条件1つで作ったサンプルは、もう1つ追加した瞬間に必要になる形状を示してくれません。
any_ofはもう一方の組み合わせ子です。すべての項が通過する必要があるか、いずれか1つが通過すればよいか、を指定します。
反転もまたフラグではなくラッパー
"invert": trueフィールドは存在しません。否定された条件はラップされます：
{ "condition": "minecraft:inverted", "term": { …the original condition… } }termは単数形であることに注意してください。invertedはちょうど1つを取り、all_ofとany_ofはterms配列を取ります。似た見た目で形状の異なる2つのキーがあり、反転は条件ごとに適用されるため、1つのall_ofの中で反転した項とそのままの項を自由に混在させることができます。
ビルダーが提供する8つの条件タイプ
entity_properties random_chance
int_value_check random_chance_with_enchanted_bonus
weather_check time_check
location_check match_toolゲームには20の条件タイプがありますが、これらはビルダーのピッカーが扱う8つです。そのうち2つは名前が変更されており、ビルダーはまだ古いID — random_chance_with_lootingとvalue_check — を書き出しますが、現行バージョンはこれらを拒否するので、出力内でその2つは名前を変更してください。
random_chance_with_enchanted_bonusは少し立ち止まる価値があります。これはエンチャントなしの確率と、エンチャントのレベルに応じてスケールするenchanted_chance（バニラ自身のテーブルではドロップ増加）を取るため、確率は倒した者が何を持っているかに依存します。つまりこれは、コンテキスト内に倒した者が存在する場合にのみ意味を持ちます — 汎用のランダムゲートではなく、ドロップ率の条件なのです。それ以外の場所では、素のrandom_chanceを使うのが適切です。
int_value_check（およびfloat_value_check）は、数値が範囲内に収まるかをテストします。ビルダーの値チェックは、エンチャントレベルのソースか、コピー後に手動でJSONに編集して書き込むカスタム式を提供します。
ピッカーはまさにバニラのセットそのもの
バイオームや構造物のIDが実在するかを確認するときに知っておく価値があります。ビルダーのドロップダウンは厳選されたサンプルではありません。
- 66のバイオーム — 26.2までのすべてのバイオーム。26.3の
dappled_forestは欠けているので、手入力してください - 34の構造物 — 同様に26.2まで。26.3で追加された18の
abandoned_camp_*構造物は リストに含まれていません - 18のブロックタグと15のアイテム。これらは実際に機能するサブセットです
これは推測ではなくゲーム自身のレジストリデータに対して検証されたものなので、バイオームや構造物のリストに存在せず、26.3の追加分でもないIDは存在しません。ブロックタグとアイテムについては逆です。存在しないということは、ピッカーがそれをリストしていないというだけであり、自分でIDを入力するのは問題ありません。