召喚プリセット
クロスエディション召喚プリセット チェックリスト
クロスエディション召喚プリセット チェックリストは、テンプレート的なコマンドメモではなく、完結した Summon ワークフローへと生まれ変わりました。召喚コマンドをクロスエディション対応として公開する前に、このプリセットを利用してください。Java の召喚出力には、Bedrock が同じ形式では解釈しない NBT、属性、装備、passenger が含まれている可能性があるため、チェックリストでその差分が浮き彫りになります。本記事ではセットアップ用フィールド、出力レビュー、Project 上の配置、結果のスクリーンショットを一か所にまとめているため、マップのセットアップ・イベントトリガー・再利用可能なコマンドパック (Command Pack) の一部になる前に、コマンドを楽に監査できます。Summon Workbench は Java 側の単一情報源として使い、Project には Bedrock 向けに何を作り直す必要があるかを記録します。これにより、制作者が成功した Java プレビューを Bedrock 互換の証拠だと取り違えてしまう事態を防げます。
プリセット結果
Java NBT 由来の機能と Bedrock 向けの再構築作業を切り分ける、召喚レビュー用チェックリスト。
出力
クロスエディション召喚のレビュー
Summon cross-edition review
- Java NBT: custom names, attributes, equipment, passengers.
- Bedrock rebuild: supported entity id, supported events/components, separate ride or equipment workflow.
- Save variants separately and test both editions.プリセットのスクリーンショット
プリセットを作成
- 対象のモブを表す Java の Summon プリセットを開きます。
- Java 限定の機能 (NBT、装備、属性、タグ、passenger) をすべて書き出します。
- Bedrock がサポートするコマンドで再構築できる部分はどれかを判断します。
- その再構築用に、別途 Bedrock の Project エントリを作成します。
- 未対応の機能は無言で削るのではなく、必ず明文化しておきます。
- 両エディションのバリアントを、それぞれ独立してテストします。
この Summon プリセットを Project に置くべき理由
召喚コマンドをクロスエディション対応として公開する前に、このプリセットを利用してください。Java の召喚出力には、Bedrock が同じ形式では解釈しない NBT、属性、装備、passenger が含まれている可能性があるため、チェックリストでその差分が浮き彫りになります。
Summon Workbench は Java 側の単一情報源として使い、Project には Bedrock 向けに何を作り直す必要があるかを記録します。これにより、制作者が成功した Java プレビューを Bedrock 互換の証拠だと取り違えてしまう事態を防げます。コピーしたコマンドが役立つのは、セレクターの範囲・ワールドの状態・パック内での順序・Minecraft に貼り付ける正確な出力、といった前提条件が一目で分かるときだけです。このプリセットは、コマンドが NBTForge を離れる前に細部を点検するチェックポイントとして扱ってください。
ギャラリーはそのレビュー手順に沿った構成です。1 枚目で Workbench の状態を、2 枚目でプレイヤーから見える挙動を変えるフィールドや併用モジュールを示し、出力ショットでコマンドあるいはコマンドの組み合わせをそのまま映し出します。プリセットに目に見える結果がある場合、ゲーム内のスクリーンショットでも、汎用オーバーレイに頼らずに、同じ意図を整えたテストワールドで確認します。
テストと範囲の見直し
Java 限定の NBT に依存している召喚は、Bedrock セーフとはラベル付けしないでください。Bedrock で最も近い挙動を別途組み直し、欠ける機能は文書化しておきます。
最初のスモークテストは、狭く絞ったセレクターとまっさらなワールドの状態で行います。環境系・ユーティリティ系・ルーティング系・フィードバック系のコマンドは無害に見えても、しばしば全プレイヤーやワールド全体に波及します。コマンドが意図した状態だけを変えていることを確認し、その出力が存在する理由を説明するセットアップ行や後続行と並べて、正確な出力を保存してください。
関数ファイルやコマンドブロックの連鎖に組み込むコマンドであれば、ライブの Workbench の状態だけでなく、コピーした成果物そのものをテストしてください。これにより、古いセレクター、誤ったコマンド順、抜け落ちたセットアップ行、あるいは前回のテストで残ったワールド状態のせいで「動いているように見えるだけ」の挙動を洗い出せます。
- パック全体のレビューが終わるまでは、セレクターを狭いままに保ちます。
- イベント固有の上書きより前に、ワールドのセットアップを置きます。
- フィードバックコマンドは、それをトリガーする状態変化の直後に保存しておきます。
次にどこへ進むか
passenger、ボス、あるいはカスタムモブのプリセットをクロスエディション記事へ仕立てる前に、このチェックリストを通してください。
関連するチェックには、Bedrock に安全なプリセットワークフロー と Java passenger から作る Bedrock 騎乗プリセット を見比べてください。
FAQ
この Summon コマンドはチャットに貼り付けてもいいですか?
セレクターが安全で、行も短いのであれば、1 行のスモークテスト用としてはたいてい問題ありません。マップでの挙動を再現可能にしたい場合は、Project に保存し、順序立てたパック形式または関数スタイルの出力をコピーしてください。
なぜこのプリセットは UI ギャラリーだけなのですか?
このプリセットが生成するのは、目に見えるワールド内のオブジェクトではなく、JSON・Project の整理・レビュー手順そのものだからです。役立つ証拠は Workbench の状態、出力、そして Project 上の配置です。
このプリセットを共有する前に何を確認すればよいですか?
セレクターの範囲、コマンドの実行順、対象バージョン、そしてそのコマンドがセットアップ・イベントロジック・フィードバック・後始末のどれに属するかを確かめてください。これらの区分が、Project パック内のどこに置くかを決めます。
このワークフローを開く
関連する Summon ワークベンチから始め、ワールドに合わせてプリセット項目を調整します。