プリセット

データパックプリセット

カスタム報酬用 Item 修飾子プリセット

カスタム報酬用 Item 修飾子プリセットは、テンプレ化されたコマンドメモではなく、完成された Data Pack のワークフローへと整理しました。ルート生成後にデータパックのロジックで報酬アイテムを成形したい場面で活用してください。Item 修飾子を使えば、ルートテーブル、`/item modify`、報酬関数の間で、カスタム名、説明文 (lore)、レア度、カスタムデータといった仕上げを、複数のコマンド文字列に書き写すことなく共有できます。この記事ではセットアップ用のフィールド、出力レビュー、Project への配置、結果のキャプチャをひとつにまとめているので、マップセットアップ、イベントトリガー、再利用可能な Command Pack の一部にする前に、コマンドを無理なく監査できます。Data Pack のワークベンチでは、修飾子の関数、ネームスペース、パス、アイテム用テキストフィールドが一体になって表示されます。これが重要なのは、修飾子は別のリソースから参照されることが多く、パスが JSON 本体と同じくらい大切だからです。

プリセット結果

生成された報酬を、名前付きのクエストメダルへ整形するアイテム修飾子リソース。

出力

報酬用アイテム修飾子 JSON

data/nbtforge/item_modifier/rewards/quest_medal.json
{
  "function": "minecraft:set_components",
  "components": {
    "minecraft:custom_name": {
      "text": "Crypt Medal",
      "color": "gold",
      "italic": false
    },
    "minecraft:lore": [
      {
        "text": "Awarded for clearing the crypt",
        "color": "gray",
        "italic": false
      }
    ],
    "minecraft:rarity": "rare",
    "minecraft:custom_data": {
      "quest_reward": "crypt_clear"
    }
  }
}

プリセットのスクリーンショット

プリセットの状態を決める Data Pack のコントロール群から確認を始めましょう。
2 枚目のスクリーンショットでは、プレイヤーから見える挙動を変更する設定や、併用するコマンドを取り上げています。
出力のスクリーンショットでは、Project に取り込む前に最終的なコマンドやコマンドのペアが表示されたままになります。

プリセットを作成

  1. Data Pack を開き、Item 修飾子を選択します。
  2. ネームスペースを `nbtforge`、リソースパスを `rewards/quest_medal` にします。
  3. 報酬に名前、説明文 (lore)、レア度、カスタムデータが必要なら `set_components` を選びます。
  4. アイテムスタックエディターに、プレイヤーに見せる報酬テキストを入力します。
  5. 生成された JSON を確認し、パスをコピーします。
  6. ルートテーブル、進捗、`/item modify` のワークフローからこの修飾子を参照します。
  7. 修飾子のパスを、それを使うコマンドと一緒に Project に保存します。

この Data Pack プリセットを Project に加える理由

ルート生成後にデータパックのロジックで報酬アイテムを成形したい場面で、このプリセットを使ってください。Item 修飾子を使えば、ルートテーブル、`/item modify`、報酬関数の間で、カスタム名、説明文 (lore)、レア度、カスタムデータといった仕上げを、複数のコマンド文字列に書き写すことなく共有できます。

Data Pack のワークベンチでは、修飾子の関数、ネームスペース、パス、アイテム用テキストフィールドが一体になって表示されます。これが重要なのは、修飾子は別のリソースから参照されることが多く、パスが JSON 本体と同じくらい大切だからです。コピーしたコマンドは、周辺の前提条件 (セレクターの範囲、ワールドの状態、パック内での順序、Minecraft に貼り付ける最終的な出力) が見えてはじめて意味を持ちます。このプリセットは、コマンドが NBTForge を出る前に細部を確認するためのチェックポイントとして扱ってください。

ギャラリーはこのレビュー観点に沿って構成されています。1 枚目はワークベンチの状態を示し、2 枚目はプレイヤーに対する挙動を変えるフィールドや併用モジュールを取り上げ、出力のスクリーンショットでは最終的なコマンドまたはコマンドのペアが残ったままになります。プリセットに目に見える結果がある場合、ゲーム内のキャプチャでは汎用的なオーバーレイに頼らず、再現したテストワールドで同じ考え方を確認します。

テストと範囲の確認

見せるためのテキストと、検出に使うデータは分けてください。名前はバランス調整やローカライズで変わる可能性がありますが、`custom_data.quest_reward` は、ほかのコマンドが報酬アイテムを識別できるよう、安定して保つべきものです。

最初のスモークテストは、絞り込んだセレクターとクリーンなワールド状態で実行してください。環境、ユーティリティ、ルーティング、フィードバックのコマンドは一見無害に思えても、実際にはプレイヤー全員やワールド全体に作用することが少なくありません。コマンドが意図した状態だけを変えていることを確認し、その出力が存在する理由を説明するセットアップ行やフォローアップ行のすぐ隣に、出力を正確に保存しましょう。

コマンドが関数ファイルやコマンドブロックのチェーンの一部になるのであれば、実行中のワークベンチの状態だけでなく、コピーした成果物自体をテストしてください。これによって、古いセレクター、誤ったコマンド順序、抜け落ちたセットアップ行、前回のテストの残留状態のせいで動いて見えていただけの効果を洗い出せます。

  • パック全体のレビューが終わるまで、セレクターは狭く保ちます。
  • 個別エンカウントの上書きより前に、ワールドの初期設定を配置します。
  • フィードバック用コマンドは、トリガーとなる状態変更のすぐ隣に保存します。

次に進むべき場所

修飾子をルートテーブルのエントリやアイテム系コマンドに紐付けるのは、単体の JSON が問題なく読み込まれることを確認した後にしてください。

つながる報酬の例については、進捗報酬プリセットガイドBoss ドロップ用ルートテーブルプリセット と比較してみてください。

FAQ

この Data Pack コマンドはチャットに貼り付けても問題ありませんか?

セレクターが安全で行も短ければ、単発のスモークテストなら基本的に問題ありません。マップでの挙動を繰り返し再現できるようにするには、Project に保存し、順序づけられたパックや関数スタイルの出力をコピーしてください。

ギャラリーが UI 中心になっているのはなぜですか?

このプリセットは、目に見えるワールド内のオブジェクトではなく、JSON、Project の整理、レビュー用ワークフローを生み出すためのものだからです。意味のある証拠は、ワークベンチの状態、出力、Project 上の配置にあります。

このプリセットを共有する前に確認すべき点は何ですか?

セレクターの範囲、コマンドの順序、対象バージョン、そしてコマンドがセットアップ、エンカウントロジック、フィードバック、クリーンアップのどこに属するかを確認します。これらの分類によって、Project パック内のどこに配置するかが決まります。

このワークフローを開く

関連する Data Pack ワークベンチから始め、ワールドに合わせてプリセット項目を調整します。