风玫瑰模组制作信息

创作者: redfalcon

已更新:2026-10-17 22:43:53

11.8MB

关于此 MOD

我一直在维护的一份文档，记录了我在设计模组过程中发现的函数、调用以及其他小技巧。

风玫瑰 UE4SS 模组开发笔记
关于模组制作的持久、引擎级事实 风陀罗 （Kraken Express，UE 5.6）——两个相关但不同的工作流程，各一个文件： UE4SS （Lua脚本和编译后的C++模组，针对实时运行的游戏）以及一个 真正的虚幻编辑器/SDK存根项目 （离线内容创作针对生成的标头存根，不涉及实时游戏进程）。这不是教程，也不是封装库——只是那些来之不易、经确认可在实机运行的发现，否则每个模组制作者都会各自重新踩一遍坑：什么会导致崩溃，什么会静默失效，什么才真正有效，以及每一项的确切操作步骤。

这里的一切都是在构建真实、已发布的模组过程中学到的（强化生存基地 及其C++配套组件LivingBaseSpawnMenu），随后进行了泛化处理，剥离了那些模组自身代码中的任何特定内容。少数条目使用了一个具体的函数名作为应用某项技术的示例——真正具有持久价值的是技术本身，而非函数名。

GitHub： github.com/dgomiller/Windrose-UE4SS-Modding-Notes

里面是什么
风玫瑰_模组制作笔记.txt ——UE4SS 侧（Lua + 针对运行中游戏的编译 C++ 模组），按编号章节组织：

1. 生成一个真正可用的 actor
2. 外观合成系统——哪些会保留、哪些不会，一种为职业的身体原型/网格重新定向的实用技术（以及如何判断源职业是否真正稳定），还有控制体型的真实机制
3. 崩溃陷阱（每个都耗费了真实的调试时间）
4. 在世界加载过程中持久化并恢复Actor状态
5. 和平/阵营机制
5b. 移动——本游戏不使用虚幻引擎导航网格
6. 行之有效的开发工作流程
7. 有用的职业路线
7b. 对游戏自身生成的事物作出反应
8. 原生生成/侦察机制（部分探索）
9. 跨骨骼换皮——真正决定结果的是什么
10. 查找当前加载的是哪个“世界”（存档）
11. 内容替换包（资源覆盖）——Lua 中能做什么、不能做什么
12. 已编译的 C++ UE4SS 模组 — 安全渲染交互式叠加层
13. 相对于移动中的船只放置角色
14. 在活动角色上播放特定的预设动画
15. ExecuteWithDelay 的回调不会在游戏线程上运行——而将其嵌套在 ExecuteInGameThread 中是另一个不同性质的错误问题
16. 使用 == 比较两个独立获取的 UE4SS 组件引用并不可靠——应改为比较 GetFName()
17. 基于线迹的定位：对象类型查询并非基于通道查询的严格超集，而“该组件是否存在”的检查需要有效性校验，而不只是空值检查
18. 从零构建复合套装：真正的三级资源结构，哪些通过 Lua 构建是安全的，哪些会导致崩溃，以及如何从命令行自动化整个离线创作与烘焙管线
19. 与“R5 Mod Settings”配套模组集成——注册设置页面、回读数值、按键绑定与开关的实时更新规则（以及一个真实的崩溃陷阱），还有更具扩展性的自动生成清单模式
20. “尚未开始”的备注是快照，而非持久事实
21. 一个能正常解析但读出来是空的实时反射探针，可能意味着要读取的数据根本不存在，而不是属性路径写错了
22. 在断定实时写入被回退之前，先排除读取操作所查看的是其他对象的可能
23. 通过资产注册表解析蓝图自身生成的CLASS时，需要其精确的索引名称——而非裸资产名称
24. 本游戏的AI运行的是现代状态树，而非黑板/行为树——其编译树引用在运行时填充，而非预先烘焙；原生手段可将树强制挂载到运行时生成的控制器上，以及为何热重载永远不会重新部署你的文件
25. 追查了整整一个会话都没能捕获到的原生崩溃——原来是延迟定时器回调中捕获了控制台命令的输出对象导致的释放后使用问题，而不是大家所认为的网格重建问题。
26. 一个第三方外观替换模组悄悄弄坏了正在使用的自定义工具，还导致了一次间歇性原生崩溃——在追查引擎层面的理论之前，先检查已安装的内容模组
27. 对AI控制的NPC进行运行时身体形态变形无法从引擎外部实现——变形在构建时由编译后的骨骼绑定图一次性烘焙完成，之后不再重新计算
28. 延迟生成事务在Actor自身的构造期子系统初始化之前，有一个真实的窗口期可用于分配属性——应使用该窗口期，而不是事后对活动实例打补丁。
29. 类层次结构检查是一种廉价而果断的方式，可以在花费更多时间调整一个静默无效的属性之前，排除“这个类在结构上无法做到那件事”的情况。
30. 二进制资源编辑库需要显式加载游戏自身的类型映射文件，否则原生资源会静默降级为不可读的原始数据块
31. 在已发布的 Zen/IoStore 容器中修补单个包，无需其原始暂存树或完整重新烹饪
32. 在已烘焙的资产中从零构建一个真正全新的标记属性，需要额外提供一个类型描述符字段，编辑库不会为你推断该字段。
通过脚本反射绑定进行的原生函数调用，可能要求比其自身 C++ 签名所承诺的更严格的参数处理
34. 一个每帧被多次调用且使用字面量控件标识符的UI辅助函数最终会与自身发生冲突

每一条都是具体且经过实机验证的发现——不是猜测，不是“理论上应该可行”。尝试过但失败的内容也同样记录在案，因为一个有据可查的死胡同能为其他人省下同样的时间：失效的UObject指针、无法被pcall捕获任何追踪的原生崩溃、Mercuna导航（而非UE导航网格）、为什么属性写入可能报告成功却从不渲染、DXGI/D3D钩取的陷阱，以及更多内容。

风玫瑰_虚幻_SDK_说明.txt —— 另一边：针对游戏自身反射类所生成的头文件存根，搭建一个真实、独立的虚幻编辑器项目，并利用它完全离线地创作、烘焙和打包真正全新的内容。涵盖项目搭建、无头 Python 创作与烘焙流水线、无头脚本的两个实际限制（从字符串构造 GameplayTag；将软对象引用设置为外部/未挂载的资产）及其变通方案、打包/安装、若干通用虚幻构建环境陷阱、两个完整的实战示例（重定向某个类解析到的身体原型/网格体，以及按尺寸控制材质/皮肤的真实机制）、通过以真实模块/类名重新实现游戏自身基类的存根来创作一个真正全新的原生类（而不仅仅是新的纯数据资产），以及将修复直接烘焙到蓝图自身的类默认值中而非在运行时处理——包括一种通过已烘焙包自身的导入表来重定向硬类引用（而不仅仅是软对象值）的技术。

还包括： pakcontents.xlsx — 游戏 .pak/.utoc 文件中所有资源名称的导出，每个文件一张表。无需自行翻查原始档案，即可方便地找到用于生成或引用的类/资源路径。

使用它
纯文本文件，随便选哪种适合你的工作流程：

读一下它们 — 直接在 GitHub 上浏览任一文件。
将仓库作为子模块拉取到你自己的项目中，所以当仓库更新时它也会更新：
git submodule add https://github.com/dgomiller/Windrose-UE4SS-Modding-Notes.git external/windrose-notes
克隆或通过 curl 下载原始文件 如果你只是想要一份本地副本：
curl -O https://raw.githubusercontent.com/dgomiller/Windrose-UE4SS-Modding-Notes/main/Windrose_Modding_Notes.txt
curl -O https://raw.githubusercontent.com/dgomiller/Windrose-UE4SS-Modding-Notes/main/Windrose_Unreal_SDK_Notes.txt

这不是一次性的快照——每当活跃的模组开发中有新发现时，它都会更新。如果你想获取最新内容，请定期拉取/重新获取（或关注 GitHub 仓库）。

需求
没有。这是一个知识库，不是可安装的模组——没有任何内容需要加载、启用或放入你的 Windrose 安装目录。无论使用什么工具或引擎版本覆盖，它对任何为 Windrose 编写 UE4SS Lua 或编译 C++ 模组的人都很有用。

权限/许可
公有领域（CC0） ——使用它、复制它、分叉它、镜像它、基于它构建，无需署名。它旨在免费为整个 Windrose 模组社区服务，而不仅仅是为这个项目服务。

制作人员
建造过程中收集到的发现 活性基地增强 以及它的 C++ 配套组件 LivingBaseSpawnMenu。与 Claude 一起迭代构建。