世界预设
保留物品栏预设工作流程
保留物品栏预设工作流程如今是一套完整的游戏规则工作流程，而不再只是一段模板化的命令注释。当死亡不应该破坏测试用的物品、钥匙、Boss 奖励或进度工具时，就用这个预设。它在反复迭代冒险地图时特别有用，因为一次失败的战斗测试不应该逼着创作者去重建整个物品栏状态。本页把设置字段、输出审阅、Project 安置位置以及结果截图放在一起，因此在命令成为地图设置、事件触发器或可复用 Command Pack 的一部分之前就能轻松审核。在保存命令之前，这条工作流程会让那条确切的 `keepInventory` 规则及其 `true` 值始终可见。这听起来是件小事，但它能避免一种常见的混淆：把仅供试玩方便的设置，误当成本应明确告知玩家的发行规则。
预设结果
`/gamerule keepInventory true` 被保存为一条可复用的初始化命令，用于测试以及冒险地图。
输出
保留物品栏的游戏规则命令
/gamerule keepInventory true预设截图
构建预设
- 打开游戏规则 Workbench。
- 把规则设为 `keepInventory`。
- 把数值设为 `true`，用于测试或玩家友好型的地图规则。
- 检查 `/gamerule keepInventory true` 输出。
- 用一个能说明这条命令是仅供调试还是面向发行的名称，把它保存到 Project。
- 在大量物品栏测试之前运行它，确认这条规则确实是初始化命令包的一部分。
为什么这个游戏规则预设属于 Project
当死亡不应该破坏测试用的物品、钥匙、Boss 奖励或进度工具时，就用这个预设。它在反复迭代冒险地图时特别有用，因为一次失败的战斗测试不应该逼着创作者去重建整个物品栏状态。
在保存命令之前，这条工作流程会让那条确切的 `keepInventory` 规则及其 `true` 值始终可见。这听起来是件小事，但它能避免一种常见的混淆：把仅供试玩方便的设置，误当成本应明确告知玩家的发行规则。复制出去的命令只有在周围的假设也清晰可见时才真正有用：选择器范围、世界状态、包内顺序，以及最终会被粘贴进 Minecraft 的那段确切输出。把这个预设当作检查点，让这些细节在命令离开 NBTForge 之前都能被审阅。
图集就是围绕这一思路搭建的。第一张截图展示 Workbench 状态，第二张突出那些会改变玩家可见行为的字段或配套模块，输出截图让命令或命令对保持可见。当预设有明确的可见结果时，游戏内截图会在还原的测试世界中再次确认同一件事，而不是只靠一张通用的覆盖图。
测试与作用范围检查
保留物品栏会掩盖真正的生存平衡问题。请在迭代阶段开着它，然后再决定最终地图究竟是要保持开启，还是把这条规则挪到只在调试初始化函数里使用。
用收窄的选择器和干净的世界状态跑第一次冒烟测试。环境、工具、路径和反馈命令看似无害，但它们往往会影响到每一位玩家或整个世界。先确认命令只改变了预期的状态，再把确切的输出与触发它的设置命令或解释其存在原因的后续命令保存在一起。
如果命令将成为函数文件或命令方块链的一部分，请测试复制出来的成品，而不只是 Workbench 中实时的状态。这样可以揪出陈旧的选择器、错乱的命令顺序、漏掉的设置行，以及那些只是因为上一次测试留下了残余状态才看起来生效的效果。
- 在完整命令包审核完毕之前，先把选择器范围收窄。
- 把世界设置类命令放在遭遇专用的覆盖类命令之前。
- 把反馈命令和触发它们的状态变更命令保存在一起。
接下来用在哪里
把它和奖励物品预设以及清理命令配成一组，这样每次重复测试都能从已知的物品栏状态开始。
对于相邻的初始化设置，可对照参考冒险地图的游戏规则预设、冒险地图关键物品预设以及用于清理的 Kill 命令预设。
FAQ
我可以把这条游戏规则命令直接粘贴到聊天里吗？
如果选择器范围安全而且这一行很短，用作单条命令的冒烟测试通常没问题。但要做出可重复的地图行为，请把它保存到 Project，再以有序的命令包或函数样式输出复制出去。
为什么连工具型预设也要附上结果截图？
结果截图证明命令真的改变了 Minecraft 里看得见的世界、HUD、路径或反馈状态，而不是只在输出面板里看着没问题。
在分享这个预设之前我应该检查什么？
检查选择器范围、命令顺序、目标版本，以及这条命令到底属于设置、遭遇逻辑、反馈还是清理类别。这些分类决定了它在 Project 命令包中的位置。
打开这个工作流
从相关 Gamerule 工作台开始，然后按你的世界调整预设字段。