数据包预设
自定义合成配方预设
自定义合成配方预设如今是一套完整的数据包工作流程，而不再是模板化的命令说明。当某件地图物品应该通过数据包配方合成获得，而不是通过命令派发时，请使用这个预设。配方非常适合中枢解锁、谜题奖励和进度物品，因为输入与结果始终能以 JSON 形式被审查。本文把设置字段、输出审阅、Project 归位与结果捕获放在一起呈现，让命令在成为地图设置、事件触发器或可复用 Command Pack 一部分之前，能被轻松审查。数据包工作台把配方类型、分类、原料、结果 ID、结果数量、命名空间与资源路径全部放进同一个视图里。这能避免一种常见错误：JSON 输出看起来合法，却被保存到了错误的配方路径下。
预设结果
一份自定义无序合成配方资源，用来合成冒险地图的关键物品。
输出
自定义配方 JSON
data/nbtforge/recipe/keys/ancient_key.json
{
"type": "minecraft:crafting_shapeless",
"category": "misc",
"ingredients": [
"minecraft:echo_shard",
"minecraft:gold_ingot"
],
"result": {
"id": "minecraft:tripwire_hook",
"count": 1
}
}预设截图
构建预设
- 打开数据包并选择 Recipe（配方）。
- 选择配方类型，通常是 `crafting_shapeless` 或 `crafting_shaped`。
- 把命名空间设为 `nbtforge`，并选一个语义清晰的资源路径。
- 填写原料 ID 与结果物品 ID。
- 有意识地设置结果数量。
- 审阅生成的 JSON，并复制路径。
- 在目标版本里 `/reload` 之后测试这个配方。
为什么这个数据包预设应该归入 Project
当某件地图物品应该通过数据包配方合成获得，而不是通过命令派发时，请使用这个预设。配方非常适合中枢解锁、谜题奖励和进度物品，因为输入与结果始终能以 JSON 形式被审查。
数据包工作台把配方类型、分类、原料、结果 ID、结果数量、命名空间与资源路径全部放进同一个视图里。这能避免一种常见错误：JSON 输出看起来合法，却被保存到了错误的配方路径下。一条复制出去的命令，只有在其周围的假设全部可见时才真正有用：选择器范围、世界状态、数据包内部顺序，以及最终会被粘贴进 Minecraft 的确切输出。请把这个预设当作一个检查点，让这些细节都能在命令离开 NBTForge 之前被审视一遍。
整组示意图正是围绕这种审视方式构建的。第一张截图展示工作台状态，第二张截图调出会改变玩家面向行为的字段或配套模块，输出截图则让最终命令或命令对保持可见。当预设具备可见结果时，游戏内截图会在一个已恢复的测试世界中确认相同的思路，而不是依靠通用覆盖层。
测试与范围检查
配方只控制合成本身。如果结果需要自定义名称、描述文本 (lore) 或自定义数据，请在合成完成后用奖励命令或物品修饰符来处理，因为原版配方结果无法以同样的方式表达每一个组件流程。
用范围狭窄的选择器和干净的世界状态先做一次冒烟测试。环境、工具、传送和反馈类命令看起来无害，却往往会影响所有玩家或整个世界。先确认命令只改变了你期望的状态，再把准确的输出保存到对应的设置行或后续行旁边，让它的存在理由一目了然。
如果命令会成为函数文件或命令方块链的一部分，请测试复制出去的成品，而不是只验证实时的工作台状态。这样才能抓出陈旧的选择器、错乱的命令顺序、被漏掉的设置行，以及那些只是因为上一次测试残留状态才看似生效的效果。
- 在完整数据包接受审阅之前，把选择器范围保持得足够窄。
- 把世界设置类命令排在遭遇专属的覆盖命令之前。
- 把反馈类命令紧挨着触发它们的状态变化一起保存。
下一步去哪里
把这个配方和讲清楚精心打造的钥匙能解锁什么的物品或奖励预设一起保存。
想看相邻的数据包工作流程，可以对照数据包命名空间预设指南和条件战利品谓词预设。
FAQ
我可以把这条数据包命令粘贴到聊天里吗？
如果选择器安全、命令行也很短，做单条命令冒烟测试通常没问题。要实现可重复的地图行为，请把它保存到 Project，再复制带顺序的数据包输出或函数风格的输出。
为什么这组示意图全是 UI？
这个预设产出的是 JSON、Project 组织或审阅流程，而不是世界中可见的实体物体。真正有用的证据是工作台状态、输出，以及它在 Project 中的归位。
在分享这个预设之前，我应该检查什么？
检查选择器范围、命令顺序、目标版本，以及这条命令究竟属于设置、遭遇逻辑、反馈还是清理。这些类别决定了它在 Project 数据包中应归入哪个位置。
打开这个工作流
从相关 Data Pack 工作台开始，然后按你的世界调整预设字段。