アイテムショーケース用のディスプレイエンティティプリセット

博物館の展示ケースや報酬のプレビュー、ロビーに置く小道具、あるいはアイテムをプレイヤーに渡さずに見せたいマップ上の目印に、このプリセットを使ってください。

頼れるのはここでも構造です。item_display が召喚位置を提供し、目に見える passenger、装備、表示用のデータが、このプリセット固有の遭遇 ID を形作ります。ツリーを開いたまま編集していれば、コマンドが Workbench を離れる前に、括弧の付け間違いといったミスを未然に防げます。

あとから遭遇を見直しやすくしたい場面でこそ、このプリセットを活用してください。Workbench のスクリーンショットがどのエンティティに動きや当たり判定を持たせたかを記録し、2 枚目のスクリーンショットが passenger や装備の細部を残し、出力のスクリーンショットが生成された /summon の行を見えたまま保持します。最後にゲーム内のキャプチャが、Minecraft 側でも同じ関係性が描画されることを確認してくれます。テキストだけの例では決して得られない安心感がここにあります。

ディスプレイエンティティは変換データや、各バージョンごとの仕様差に大きく左右されます。ビルドの中に複数のコピーを配置する前に、対象となる Java バージョンでスケールやビルボードの設定をきちんとテストしてください。

最初のテストは開けた Java ワールドで行い、コマンド長の警告にも気を配ってください。コンパクトな rider のプリセットならそのまま貼り付けて構いませんが、長い Boss 用の派生や装備が増えたバリエーションは、コマンドブロックかデータパックの関数に移すのが安全です。

エフェクト、ルートテーブル、サウンド、スコアボードを足す前に、最初のスモークテストはとにかく小さく保ってください。敵対的な passenger は次元や難易度に応じて移動・燃焼・デスポーン・挙動の変化を起こしやすいので、まずは制御された条件で基本となる rider と装備スタックを確かめましょう。見た目の結果が安定したら、表示名や近接セレクターに頼らず、タグを付け、そのタグを対象とする後続のコマンドへつなげてください。

• ルートのエンティティと搭乗者の役割を、はっきり区別して扱ってください。
• 後始末や後続のコマンドを書く前に、目印となるタグを付けておいてください。
• 遭遇を公開する前に、難易度や挙動の条件をひと通りテストしておいてください。

ひと通り完結した報酬展示を組みたいときは、ショーケースをアイテムフレーム、ブロックディスプレイ、テキストラベルと組み合わせてみてください。

近い系統のディスプレイのワークフローを比べたいときは、装飾用のブロックディスプレイプリセット、浮かぶラベル用のテキストディスプレイプリセット、Item Frame アイテムのプリセットワークフロー をあわせてご覧ください。