NBTForge 中的 BOSS 掉落武器预设

在把同一份物品堆叠转入战利品表或 Command Pack 奖励之前，先用它来负责 BOSS 遭遇里「物品」的那一半。

Workbench 让奖励在变成战利品表 JSON 之前一直保持可读状态，这让 BOSS 奖励的审核工作轻松许多。这恰恰是一段普通命令片段最容易隐藏的部分：面向玩家的文本、随版本变化的组件以及可直接复制的输出，必须在命令离开 Workbench 之前彼此一致。

在物品被接入更大的命令链之前，请把这个预设当成一块校验面板。确认提示框已向玩家说清楚物品的用途，确认 custom_data 或其他隐藏组件承载着真正的命令逻辑，并确认复制出来的输出仍然贴合所选的 Minecraft 版本。游戏内结果之所以特意保持简单，是因为它能直接回答第一个 QA 问题：这条命令是不是真的发放了文章所描述的那一份物品堆叠？

现代 Java 版的物品命令把许多旧教程里以 NBT 形式存在的细节都改用物品组件来表达。编辑时务必让所选版本一直可见，尤其是当物品涉及名称、描述文本 (lore)、附魔、稀有度、自定义模型数据、药水内容或不可破坏状态时。

直接的 /give 命令很适合做物品 QA，但真正的 BOSS 掉落最终应当落到战利品表或函数路径里。

命令通过校验后，请在地图或数据包将来真正运行的同一版本系列里再跑一遍。即便命令看上去复制得干干净净，只要组件不受支持、选择器命中过多玩家，或者物品文本承诺了数据并未真正强制执行的行为，它就依然存在设计漏洞。在添加计分板、战利品、商店、NPC 或重置命令之前，先把这条稳定版本保存到 Project 中。

• 在动手编辑原始命令文本之前，优先使用 Workbench 字段。
• 让显示文本足够简短，能够完整放进物品栏提示框里。
• 用 custom_data 来承载命令逻辑，而不要依赖可见名称。

等物品在游戏里看起来一切正常之后，再把同一份组件复制进 BOSS 战利品工作流里。

如果这件物品需要反复使用，请先把它存为 Project 条目，再围绕它去添加计分板、战利品表、NPC 或重置命令。这样在地图规模不断扩大的过程中，物品定义本身依然可以审核。

至于遭遇那一侧，可把这件物品接到烈焰皇帝火焰 BOSS 战利品预设或带自定义武器的 BOSS 生物预设上。