レアリティを設定したクエスト報酬アイテム

クエストの納品、トライアルチャンバーの報酬、ロビーの解放、あるいはプレイヤーが手順をやり遂げた証となるアイテムに、ぜひこのプリセットをお使いください。

このワークフローは見た目の作り込みを custom_data の ID に結び付けるので、アイテムはプレイヤー側でもコマンドのロジック側でも機能します。素のコマンドスニペットでは、この部分はたいてい隠れてしまいます。プレイヤーに見えるテキスト、バージョン依存のコンポーネント、そしてコピーして使える出力は、コマンドが Workbench を離れる前にすべて噛み合っている必要があります。

アイテムをより大きなコマンドチェーンに組み込む前に、このプリセットを確認用の場としてご利用ください。ツールチップがアイテムの効果をプレイヤーへ伝えているか、custom_data などの目に見えないコンポーネントがコマンドのロジックを支えているか、そしてコピーした出力が選択中の Minecraft バージョンにいまも適合しているかを確かめます。ゲーム内の結果をあえて簡素にしているのは、品質確認の最初の問い、すなわち「このコマンドは記事で説明したアイテムスタックを本当に配布しているのか」に答えるためです。

最新の Java 版のアイテムコマンドは、古いチュートリアルでは NBT として書かれていた多くの詳細を、アイテムコンポーネントとして表現します。とくにアイテムに名前、説明文 (lore)、エンチャント、レアリティ、カスタムモデルデータ、ポーションの中身、または unbreakable 状態を使う場合は、編集中も選択したバージョンをつねに表示しておいてください。

レアリティとエンチャントの輝きは、見た目のサインにすぎません。スコアボードの状態、進捗の確認、検出用の custom_data の代わりにはなりません。

コマンドの検証が済んだら、マップやデータパックを動かす予定と同じバージョンファミリーで実行してください。コンポーネントが未対応であったり、対象として選んだプレイヤーの範囲が広すぎたり、データで担保されていない挙動をアイテムのテキストが約束していたりすると、きれいにコピーしたコマンドであっても設計を誤っていることがあります。スコアボード、ルート、ショップ、NPC、リセット系のコマンドを追加する前に、安定したバリアントを Project に保存しておきましょう。

• 生のコマンドテキストを編集する前に、まず Workbench のフィールドから操作してください。
• 表示テキストは、インベントリのツールチップに収まる長さに保ってください。
• 見える名前に頼らず、コマンドのロジックには custom_data をお使いください。

Give コマンドのテストが済んだら、報酬アイテムをクリアや実行チェックにつなげましょう。

アイテムを使い回す場合は、スコアボード、ルートテーブル、NPC、リセット系コマンドを追加する前に Project エントリとして保存してください。こうしておけば、マップが大きくなってもアイテム定義を見直せる状態を保てます。

報酬チェーンについては、NBTForge の Boss ドロップ武器プリセット と 説明文 (lore) とエンチャントの輝き付きの Sharpness 剣プリセット を見比べてみてください。