数据包预设
条件战利品谓词预设
条件战利品的谓词预设如今是一套完整的数据包工作流程，而不再是模板化的命令说明。当战利品表、进度或函数需要检查某个条件，又不希望到处重复同一段 JSON 时，请使用这个预设。谓词让条件式数据包逻辑更易于复用，因为一个命名文件就成了共享的规则。本文把设置字段、输出审阅、Project 归位与结果捕获放在一起呈现，让命令在成为地图设置、事件触发器或可复用 Command Pack 一部分之前，能被轻松审查。工作台审阅过程应当把谓词类型、目标物品或实体条件、命名空间、路径和生成的 JSON 放在一起呈现。这样在谓词被战利品表或 execute 风格的函数逻辑引用之前，就给作者留下了一个干净的检查点。
预设结果
一份谓词资源，可以把战利品或函数逻辑卡在某把试炼钥匙是否被持有这个条件之后。
输出
条件战利品谓词 JSON
data/nbtforge/predicate/has_trial_key.json
{
"condition": "minecraft:match_tool",
"predicate": {
"items": [
"minecraft:tripwire_hook"
]
}
}预设截图
构建预设
- 打开数据包工作台。
- 选择 Predicate（谓词）作为生成器。
- 为这条可复用的条件设置命名空间与资源路径。
- 选择谓词类型，例如 `match_tool`、`entity_properties` 或 `random_chance`。
- 填写谓词所使用的物品、实体、概率或方块字段。
- 审阅 JSON，并复制资源路径。
- 在测试之前，先在战利品表或函数里引用这个谓词。
为什么这个数据包预设应该归入 Project
当战利品表、进度或函数需要检查某个条件，又不希望到处复制同一段 JSON 时，请使用这个预设。谓词让条件式数据包逻辑更易于复用，因为一个命名文件就成了共享的规则。
工作台审阅过程应当把谓词类型、目标物品或实体条件、命名空间、路径和生成的 JSON 放在一起呈现。这样在谓词被战利品表或 execute 风格的函数逻辑引用之前，就给作者留下了一个干净的检查点。一条复制出去的命令，只有在其周围的假设全部可见时才真正有用：选择器范围、世界状态、数据包内部顺序，以及最终会被粘贴进 Minecraft 的确切输出。请把这个预设当作一个检查点，让这些细节都能在命令离开 NBTForge 之前被审视一遍。
整组示意图正是围绕这种审视方式构建的。第一张截图展示工作台状态，第二张截图调出会改变玩家面向行为的字段或配套模块，输出截图则让最终命令或命令对保持可见。当预设具备可见结果时，游戏内截图会在一个已恢复的测试世界中确认相同的思路，而不是依靠通用覆盖层。
测试与范围检查
谓词文件本身什么都不做。它必须被战利品表条件、进度条件，或 command/function 路径引用，才知道何时去评估它。
用范围狭窄的选择器和干净的世界状态先做一次冒烟测试。环境、工具、传送和反馈类命令看起来无害，却往往会影响所有玩家或整个世界。先确认命令只改变了你期望的状态，再把准确的输出保存到对应的设置行或后续行旁边，让它的存在理由一目了然。
如果命令会成为函数文件或命令方块链的一部分，请测试复制出去的成品，而不是只验证实时的工作台状态。这样才能抓出陈旧的选择器、错乱的命令顺序、被漏掉的设置行，以及那些只是因为上一次测试残留状态才看似生效的效果。
- 在完整数据包接受审阅之前，把选择器范围保持得足够窄。
- 把世界设置类命令排在遭遇专属的覆盖命令之前。
- 把反馈类命令紧挨着触发它们的状态变化一起保存。
下一步去哪里
FAQ
我可以把这条数据包命令粘贴到聊天里吗？
如果选择器安全、命令行也很短，做单条命令冒烟测试通常没问题。要实现可重复的地图行为，请把它保存到 Project，再复制带顺序的数据包输出或函数风格的输出。
为什么这组示意图全是 UI？
这个预设产出的是 JSON、Project 组织或审阅流程，而不是世界中可见的实体物体。真正有用的证据是工作台状态、输出，以及它在 Project 中的归位。
在分享这个预设之前，我应该检查什么？
检查选择器范围、命令顺序、目标版本，以及这条命令究竟属于设置、遭遇逻辑、反馈还是清理。这些类别决定了它在 Project 数据包中应归入哪个位置。
打开这个工作流
从相关 Data Pack 工作台开始，然后按你的世界调整预设字段。