Minecraft Command Pack审查清单
8 分钟阅读
即使每行都有效，Command Pack也可能会失败。顺序、选择器、缺少记分板目标、版本漂移和重置行为可能会破坏发布后的工作流程。此清单是共享 Project 包或函数式command block之前的最后一道检查。
指南结果
需要经受住Copy、测试和未来编辑的Command Pack的最终审查。
推荐路径
- 确认包目标：Java 版本、快照或 Bedrock Stable。
- 检查设置命令是否创建稍后使用的每个记分板、bossbar、团队、标签或存储密钥。
- 从上到下验证命令顺序，尤其是目标、标签和清理。
- 在测试完整包之前，运行破坏性命令的选择器测试。
- 复制来自 Project 的包并测试Copy 的文本，而不仅仅是实时构建器状态。
订单审核
创建状态的命令应出现在依赖于该状态的命令之前。记分板目标、bossbar、团队、标签和存储路径应在后面的行读取或修改之前创建。
清理命令通常应该放在最后，除非它们在全新设置之前有意清除测试状态。
- 在设定分数之前先制定目标。
- 在更新值之前创建 bossbars。
- Summon 或在定位标签之前标记实体。
- 检查成功条件后奖励Give。
选择者和范围审查
每个破坏性命令都需要进行范围检查。杀戮、清除、伤害、传送和数据合并命令应该针对已知的标签、玩家、团队或区域，而不是广泛的选择器。
对于地图发布，请在世界副本中进行测试，并在重复测试留下状态时包含重置命令。
复制评论
复制的包是用户将运行的工件。从 Project Copy后，粘贴到干净的文本缓冲区中并扫描丢失的行、损坏的顺序、意外的前缀或仍然引用仅测试名称的命令。
在线共享时，请在包旁边附上 Minecraft 版本。当前的 Java 包和 Bedrock 安全包应单独下载或单独部分。
运送Copy 的工件
使用本指南来生成玩家或地图制作者将实际运行的工件：Copy 的命令、订购的 Project 包或datapack资源。最终审查应该发生在 Copy 的Output上，而不仅仅是可编辑的构建器状态。
当工作流对版本敏感时，请在命令旁边标记目标版本。当它使用选择器、记分板、bossbars、标签、loot table或项目顺序时，请在发布设置之前在干净的世界中测试这些依赖项。
- 来自 Output 的 Copy 用于一个命令，来自 Project 的订购包。
- 将 Java、Bedrock 和快照变体分开。
- 首先用无害的Output测试破坏性的选择器。
- 当指南成为规范工作流程时更新相关预设。
相关指南与预设
常见问题
我应该测试每个命令还是只测试整个Command Pack？
两者都做。单独测试高风险行，然后测试Copy 的包作为最终工件，因为顺序和Copy格式很重要。
最常见的Command Pack错误是什么？
在其状态存在之前使用稍后的命令，例如在创建目标之前设置分数或在实体被标记之前定位标签。
本指南什么时候应该成为 Project 包？
当工作流需要多个命令、有设置和清理顺序或测试后必须再次编辑时，请使用 Project。一次性命令可以保留在 Output 中。