数据包预设
数据包命名空间预设指南
数据包命名空间预设指南如今是一套完整的数据包工作流程，而不再是模板化的命令说明。在一个数据包还没膨胀成一堆散乱目录之前就使用这个预设。命名空间是文件、命令与资源引用之间的契约，越早规划越能避免战利品表、函数、进度、谓词与配方漂移到互不一致的 ID 上去。本文把设置字段、输出审阅、Project 归位与结果捕获放在一起呈现，让命令在成为地图设置、事件触发器或可复用 Command Pack 一部分之前，能被轻松审查。数据包工作台是命名空间和资源路径纪律的可见检查点。整组截图展示了同一个 `nbtforge` 命名空间如何同时支撑数据包元数据文件、函数路径与战利品资源，而不是让每篇文章自己发明一套不同的 ID 方案。
预设结果
一份命名空间方案，把函数、战利品表、配方、谓词与物品修饰符全部归入同一个项目 ID 之下。
输出
命名空间规划数据包文件
pack.mcmeta
{"pack":{"pack_format":81,"description":"NBTForge adventure pack"}}
data/nbtforge/function/setup.mcfunction
gamerule doMobSpawning false
weather clear 6000
data/nbtforge/loot_table/chests/crypt_reward.json预设截图
构建预设
- 打开数据包，先选好你准备规划的资源类型。
- 把命名空间设成一个稳定的项目 ID，比如 `nbtforge`。
- 选择一条包含功能子目录的资源路径。
- 复制生成的文件路径，并在 Project 里登记下来。
- 对相关的函数、战利品表和谓词重复使用同一个命名空间。
- 除非有意覆盖原版数据，否则不要把自定义文件混进 `minecraft` 命名空间。
- 目录结构搭好之后，用 `/reload` 测试这个数据包。
为什么这个数据包预设应该归入 Project
在一个数据包还没膨胀成一堆散乱目录之前就使用这个预设。命名空间是文件、命令与资源引用之间的契约，越早规划越能避免战利品表、函数、进度、谓词与配方漂移到互不一致的 ID 上去。
数据包工作台是命名空间和资源路径纪律的可见检查点。整组截图展示了同一个 `nbtforge` 命名空间如何同时支撑数据包元数据文件、函数路径与战利品资源，而不是让每篇文章自己发明一套不同的 ID 方案。一条复制出去的命令，只有在其周围的假设全部可见时才真正有用：选择器范围、世界状态、数据包内部顺序，以及最终会被粘贴进 Minecraft 的确切输出。请把这个预设当作一个检查点，让这些细节都能在命令离开 NBTForge 之前被审视一遍。
整组示意图正是围绕这种审视方式构建的。第一张截图展示工作台状态，第二张截图调出会改变玩家面向行为的字段或配套模块，输出截图则让最终命令或命令对保持可见。当预设具备可见结果时，游戏内截图会在一个已恢复的测试世界中确认相同的思路，而不是依靠通用覆盖层。
测试与范围检查
除非你是有意要覆盖原版数据，否则不要把自定义数据包资源放在 `minecraft` 下。请使用项目命名空间，例如 `nbtforge`、你的地图 ID 或工作室 ID，这样文件之间才会彼此隔离。
用范围狭窄的选择器和干净的世界状态先做一次冒烟测试。环境、工具、传送和反馈类命令看起来无害，却往往会影响所有玩家或整个世界。先确认命令只改变了你期望的状态，再把准确的输出保存到对应的设置行或后续行旁边，让它的存在理由一目了然。
如果命令会成为函数文件或命令方块链的一部分，请测试复制出去的成品，而不是只验证实时的工作台状态。这样才能抓出陈旧的选择器、错乱的命令顺序、被漏掉的设置行，以及那些只是因为上一次测试残留状态才看似生效的效果。
- 在完整数据包接受审阅之前，把选择器范围保持得足够窄。
- 把世界设置类命令排在遭遇专属的覆盖命令之前。
- 把反馈类命令紧挨着触发它们的状态变化一起保存。
下一步去哪里
FAQ
我可以把这条数据包命令粘贴到聊天里吗？
如果选择器安全、命令行也很短，做单条命令冒烟测试通常没问题。要实现可重复的地图行为，请把它保存到 Project，再复制带顺序的数据包输出或函数风格的输出。
为什么这组示意图全是 UI？
这个预设产出的是 JSON、Project 组织或审阅流程，而不是世界中可见的实体物体。真正有用的证据是工作台状态、输出，以及它在 Project 中的归位。
在分享这个预设之前，我应该检查什么？
检查选择器范围、命令顺序、目标版本，以及这条命令究竟属于设置、遭遇逻辑、反馈还是清理。这些类别决定了它在 Project 数据包中应归入哪个位置。
打开这个工作流
从相关 Data Pack 工作台开始，然后按你的世界调整预设字段。