Build 42 终于把 Mod 管理当成正式系统。官方 Mod Manager 可以搜索与收藏 Mod、调整加载顺序、显示依赖与不兼容项,并通过剪贴板保存/分享预设。只要真正利用这些功能,过去那种“勾80个 Workshop 条目然后祈祷能启动”的流程,就能变成可记录、可复现的配置。
快速结论
为“原版增强”“联机”“测试”分别创建预设,不要每次手动勾一整页 Mod。
调整加载顺序前先读依赖和不兼容提示;框架类 Mod 通常应该排在依赖它们的 Mod 前面。
Build 42 热修后,先用该预设跑一个测试存档,再让不可替代的长期世界加载。
重点速览
表格可左右滑动,查看完整内容。
| 管理器功能 | 主要用途 | 能预防的问题 |
|---|---|---|
搜索 + 收藏 | 把已验证的小型 Mod 池固定下来 | 重复订阅同名/相似 Mod |
加载顺序 | 把框架放在依赖 Mod 之前 | 缺类 / UI 启动错误 |
依赖显示 | 安装真正必需的 Workshop 项 | 静默缺框架失败 |
不兼容信息 | 启动前发现已知冲突 | 两个 Mod 同时重写一个系统 |
预设 | 冻结可复现的 Mod 组合 | 忘记服务器上周到底用了什么 |
从“已知可用预设”开始
创建一个最小预设,只放已经验证过的框架和 QoL Mod。尝试新 Mod 前复制这个预设。如果新东西导致崩溃,可以立刻退回基线,而不是重新拆整套列表。
改顺序之前先读依赖
加载顺序不是装饰。如果 Mod B 依赖 Framework A,那么 A 应该更早加载。官方管理器会显示这些关系,而 Build 42 的管理器设计本身也加入了顺序控制、自动排序和缺失 Mod 提示。
给团队直接分享预设
服务器改变 Mod 栈时,导出/分享预设,不要只发 Workshop 合集截图。预设不仅告诉别人启用了哪些 Mod,也能表达它们应该使用的顺序。
补丁日流程
先备份存档,让 Workshop 更新完成;启动游戏检查管理器警告;使用一次性测试世界运行预设;确认没问题后再开长期世界。跳过测试时,第一个“不兼容证据”很可能就是坏掉的正式存档。
故障排查与常见错误
表格可左右滑动,查看完整内容。
| 问题 | 处理办法 |
|---|---|
预设显示缺少依赖 | 打开依赖列表,安装必需项,重启后再检查。 |
Mod 显示启用但没有效果 | 确认它属于正确 Build,并且所需框架确实先加载。 |
朋友 Workshop 订阅一样但仍不匹配 | 比较真正启用的预设和加载顺序,而不是只看订阅列表。 |
补丁后 UI 突然坏了 | 先禁用最近的 UI 栈改动,从已知可用预设重新测试。 |
常见问题
Build 42 有官方 Mod Manager 吗?
有。官方 42.20 功能页明确描述了搜索、收藏、加载顺序、依赖/不兼容和可分享预设。
预设会包含加载顺序吗?
Build 42 开发说明明确描述了连同顺序一起分享 Mod 预设。
联机应该统一使用同一个预设吗?
服务器要求的 Mod 建议统一,这是减少客户端/服务器漂移最干净的方法之一。
