企业官网建设流程全解析

本文是对universal-modder知识库中 社区 Modding 工具集与 Assassin's Creed 家族先行艺术调研 的展开解读：它系统梳理了 Anvil / AnvilNext 引擎下 AC1、AC3、AC4 Black Flag、Rogue、Unity 各作的公开 Mod 工具生态、引擎谱系与多人在线分布，并回答"该选哪部作品、配哪套工具"的路线问题。读完本文，你将掌握整个 AC 家族的 modding 地图：原生插件框架、forge 资源管线、脚本引擎各自适用场景，以及为什么"AC 家族至今没有公共 co-op Mod"是这个方向最大的空白与机会。

这份调研笔记源自一个真实项目的前置侦察：在启动AC Rogue 的 co-op 复制层（replication layer）之前，先对 AC 家族的公开 modding 生态做一次完整盘点，结论直接服务于"选作品、选工具、评估工程量"。作为知识库中一篇典型的in-progress调研笔记，它遵循 知识库规则 中"agent 写给下一个 agent"的格式：精确版本、路线、引擎真相、验证边界、陷阱清单，宁可记录死路也不夸大成果。

调研背景：为什么先做生态盘点

知识库的定位是"下一个 agent 的起点"——每个笔记记录一个项目真正踩过的坑，包括精确版本、路线选择、引擎实际行为、验证方式与 gotchas。在 AC Rogue co-op 内部实现笔记 中，目标被明确为"AC Rogue 自由漫游 co-op"，而本调研笔记就是该项目的先行步骤：

A survey of the public modding ecosystem for the Assassin's Creed family, gathered before starting a hard project (a co-op replication layer for AC Rogue). The headline:the tools exist and are strongest for AC Unity and AC4/Rogue, but no public co-op mod exists for any AC game.

核心结论一句话：工具存在且对 AC Unity、AC4/Rogue 支持最强，但任何 AC 作品都没有公开的 co-op Mod。这意味着想做 co-op 要么自己从零搭，要么像本仓库后续笔记那样自研——事实上 AC4 幽灵分身（ghost avatar）笔记 已把这条自研路线跑通到working状态，详见后文交叉验证一节。

调研手段也值得注意：本次盘点仅用GitHub 搜索（web search 在本次不可用）。作为对比，仓库的 game-research-websearch 技能 规定了更完整的调研流程——先um kb search查知识库，再对 GitHub、Nexus、Steam Workshop、Reddit、YouTube 做多路检索，死链走 Wayback 归档，最后按证据等级（primary > 可复现社区报告 > 匿名声称）综合。当 web search 不可用时，GitHub 仓库搜索 + 直接读 README 是最低可行方案。

引擎谱系与多人在线分布（Setup）

调研首先锚定的是引擎血缘，这决定了后续一切地址与工具选择的合理性：

• 引擎谱系：AC1（2007）是原始Anvil（代号 "Scimitar"），32 位，DX9/10。从 AC2 起演进为AnvilNext：AC2 → Brotherhood → Revelations → AC3 → AC4 Black Flag → Rogue → Unity（AnvilNext 2.0）→ Syndicate → ……。其中Black Flag 与 Rogue 几乎共享同一引擎——Rogue 实质上是 Black Flag去掉多人二进制的版本（Rogue 由 Sofia 工作室开发，内部代号 "Comet"；Black Flag 的 MP 主程序AC4BFMP.exe为 32 位、仅竞技场模式，在 Rogue 内部笔记 中被明确仅作设计参考，从未运行或注入）。
• 谁带多人（涉及"是否需要联网化身 oracle 用于逆向"）：Brotherhood ✓、Revelations ✓、AC3 ✓（Wolfpack 合作 + PvP）、AC4 Black Flag ✓（Wolfpack + PvP）、Unity ✓（原生 4 人合作任务）。AC1 ✗（完全没有）、Rogue ✗、Syndicate ✗。
• 反作弊：这些单人作品无相关反作弊。仓库 安全规范 划出了明确红线——只做单人/离线或用户自建服务器，绝不注入在线客户端，内核/用户态反作弊（EAC、BattlEye、Vanguard 等）一律视为代码注入的停止标志。因此本调研与后续实践均严格限定在离线单人环境。
• 调研工具：GitHub 搜索（本次 web search 不可用）。

路线选择：先选作品，再选工具（Route and why）

原文档给出了四条可操作的决策规则，这是整篇调研最直接的产出，完整继承如下：

1. 需要一个可复制的联网化身？选带多人二进制的作品——AC4 Black Flag（AC4BFMP.exe，本身已是好目标）或AC3。避开 AC1 和 Rogue（无 MP 二进制可抄）。
2. 想尽量减少新引擎工作量？AC Unity拥有最成熟的原生插件框架且自带原生 co-op，是 AnvilNext 系列中支持最好的作品。
3. 做数据/资源 Mod？用 AnvilToolkit + 资源（覆盖整个家族）、ACExplorer（Unity forge）。
4. 需要在 AC4/Rogue 上做原生运行时控制？先研究LionAG/ScriptEngine，再考虑手写裸插件。

这条"以可抄的 MP 二进制为 oracle"的决策，与仓库 oracles 方法论 一脉相承：判断一个 Mod 是否真的工作的最佳手段，是"游戏自身或最接近游戏的机械参照物"——本案例中，AC4BFMP.exe的NetPlayer字段复制偏移（0x80/0xe8/0x128/0x1f8/0x170、移动模式+0x398）在 AC4 变换读取笔记 中被列为跨机实体身份与复制层的设计参考。

家族工具组织：每个仓库提供什么

这是调研的主体部分，逐项完整继承，并补充仓库内可交叉验证的实现证据：

ACUFixes（NameTaken3125/ACUFixes，AC Unity 1.5.0，C++）

一个玩法 Mod 兼原生 DLL 代码补丁 Mod 的 Plugin Loader，核心能力：

• 通过version.dll代理实现自动注入；
• 自带 ImGui 界面、游戏内控制台、崩溃日志；
• 关闭游戏的主完整性校验、允许 VS 调试器附加；
• 附带一套小型逆向工程 C++ 类库"ACU-RE"。

示例插件：AssetOverrides-ACUnity（运行时加载 AnvilToolkit Mod，免去 forge 重打包）、ACUPluginLoader-ExamplePlugins、Halzold98CPP。

对 co-op 项目而言，ACU-RE 是否暴露实体/变换访问，被原文档列为关键未决问题（见 Open questions）。

ACExplorer（gentlegiantJGC/ACExplorer，Python，已归档）

.forge格式的浏览器/导出器，从 AC Unity 起步——网格、纹理、装配好的世界网格、低 LOD 网格，并设计为可扩展其他 forge 系游戏。

AnvilToolkit（Kamzik123/AnvilToolkit-Resources + VELD-Dev/AnvilToolkit-AT）

社区 forge解包/回包 GUI，附带教程、文件/哈希列表与扩展资料——是全家族数据/资源 Mod 的实操路径。在 Rogue 内部笔记 与 AC4 变换读取笔记 中，AnvilToolkit 都承担了.forge/.data数据获取职责，佐证了其作为数据侧标准工具的地位。

ScriptEngine（LionAG/ScriptEngine + AC4 与 Rogue 相机工具）

一个原生脚本引擎（.scrx），已能控制相机与世界时钟（世界停止、慢动作、时段），外加 DoF/FOV/HUD——同时覆盖 Black Flag（UC 1.07）与 Rogue（UC 1.1.0）。注意原文档的诚实标注：.scrx脚本是二进制格式，所以ScriptEngine 的 API 表面（暴露实体/位置，还是仅相机/时间）尚未确认——这是原文档认为"下一步最值得验证的一件事"。

AC1

除字幕工具（bloxtbc/SubtitleSynchAC1）外基本没有公开工具。原文档明确警告：AC1 无 MP、无框架、社区极小，做功能型项目等于从零造工具。

构建步骤：按目标选择（Build steps）

没有"装一个就全搞定"的统一安装。按目标拆解为三条：

• AC Unity 原生 Mod：针对 ACUFixes loader 构建插件 DLL，放入ACU.exe所在目录的ACUFixes/plugins/（loader 由version.dll+ACUFixes-PluginLoader.dll组成）。
• Forge 资源：AnvilToolkit GUI（或 ACExplorer 用于脚本化/导出）。
• AC4/Rogue 运行时控制：ScriptEngine loader + 放在游戏根目录的.scrx脚本。

这与 native 引擎 playbook 给出的通用路径完全吻合：代理 DLL（version.dll、dinput8.dll等）→ 静态/动态分析定位 hook 点 → SafetyHook/MinHook 中钩子 → 每帧回调内做轻量工作。需要补一句 playbook 与实操笔记反复强调的通用前提：ASLR 下永远以模块基址 + RVA 计算地址，绝不硬编码绝对地址；AC4 笔记 还给出过一个具体教训——相机管理器全局地址0x02abe588，基址0x400000下 RVA 应为0x026BE588，算错一位会静默读到错误地址而不崩溃、且无任何数据输出。

与仓库内自研笔记的交叉验证

本调研的"空白点"在仓库后续笔记中被逐一验证与推进，这正是"先行艺术调研→自研"工作流的完整闭环：

• AC Rogue 内部实现笔记（in-progress）：证实 Rogue 的ACC.exe没有任何复制/会话代码（*Online*字符串属 Ubisoft OSDK；"Desynchronization" 是任务失败提示），因此 co-op必须合成而非解锁。同篇记录了两条经验证失败的路——"Spawn … Dude" 调试作弊对象被管理器每帧消费删除（1→5→0/1），是瞬态相机标记而非持久角色；char+0x800/+0x811是幽灵/传送保存位而非实时变换——并找到了有价值的一条：接口 0xD 的 set-world-transform 路径（char+0x20组件 → vtable+0x90取接口 id 0xD → 接口 vtable+0x28验证 /+0x30应用 64 字节 4×4 矩阵，平移在matrix+0x30末行）。
• AC4 幽灵分身笔记（working）：在 AC4 单人版AC4BFSP.exe中找到角色权威世界变换对象，证明写入即可移动角色，随后劫持一个普通人群角色、用 72 字节 UDP 姿态包每帧驱动它，使第二个"玩家"在真实世界可见地走动；假对端脚本让 NPC 绕玩家画圈，包停止后 NPC 交还 AI。验证证据包括四重 oracle：断点捕获自证、+20 m 写入目击瞬移、假对端绕圈循环计数 2839/2839 双向 UDP 包、以及两台 PC（Radmin VPN，约 105 ms ping）互见对方的驱动人群身体。
• AC4 变换读取笔记（in-progress）：x86 ASI 插件实测读取实时世界坐标与单位四元数（pos=(-536.8,281.0,2.8)→(-490.3,358.7,3.3)，quat=(-0.019,-0.018,0.675,0.738)），并用运动学分析确认"相机绕固定世界点（玩家身体）旋转"。

这三篇笔记共同印证了调研的路线判断：无 MP 二进制的作品（Rogue）必须合成复制层，而引擎的相机/变换/任务调度结构是可以稳定读取与驱动的——从源码结构看，AnvilNext 的任务图调度器注册机制（Rogue 笔记 中Ai::UpdateCamera等具名 RVA）与 AC4 笔记 中相机管理器 5 槽环（帧计数器%5、位置/四元数槽位偏移）是同一套结构在两个二进制中的重现。

验证与证据边界（Verification）

原文档对"知道什么"与"不知道什么"的划分极其严格，这是知识库笔记的纪律要求：

• 本次已验证：上述仓库存在、公开，且其 README 直接描述了上述能力（原文档作者逐份读过 README）。Star 数与最后更新日期均以 2026-10 调研时点为准（例如 ACUFixes 约 113★、ACExplorer 约 79★）——这些数字是调研时点的快照，不代表当前实时状态，引用时请以仓库现状复核。
• 未验证：作者没有构建、安装或运行任何这些工具。.scrx脚本为二进制，因此 ScriptEngine 的API 表面是否暴露实体/位置尚未确认——被明确列为"最值得下一步验证的一件事"。
• 明确缺失：任何 AC 游戏都没有公开 co-op Mod（GitHub 搜索只返回 trainer 与垃圾内容）。这与本文交叉验证一节的自研成果互为印证：调研时点（2026-10-05）确实无公共先行艺术，随后仓库自研才在 AC4 上跑通working的幽灵分身。

陷阱清单（Gotchas）

原文档六条陷阱完整继承，并在必要处补充仓库证据：

1. 假设无 co-op 先行艺术。搜索 "AC co-op / multiplayer mod / Black Flag coop" 无真实结果，必须自行预算工程量。
2. 联网化身的最佳 oracle 是官方 MP exe。Black Flag（AC4BFMP.exe）与 AC3 有，AC1 与 Rogue 没有。不要在无可抄 netcode 的作品上启动复制层项目。
3. 版本钉死是全部。ACUFixes 针对 AC Unity1.5.0；ScriptEngine 相机工具针对AC4 1.07 / Rogue 1.1.0。其他构建会破坏地址。Rogue 笔记 正是用固定 MD5（a323729f3799a808c8148b695e1e23b8，镜像基址0x140000000）保证全部 RVA 有效；AC4 笔记 同样钉死AC4BFSP.exeMD52058342866688F780C8B34526A65BC35。固定构建下优先模块基址 + 固定 RVA，而非模式扫描——签名漂移时会静默跳过 hook。
4. AnvilToolkit XML 只是 sidecar。只改导出的.xml无效——游戏读的是二进制资源。正确做法：改二进制 → 回包.data→ 再回包 forge，全程游戏关闭，并对字节差异。
5. AC1 是功能型项目的陷阱。无 MP、无框架、社区极小，工具基本要从零造。
6. 不要收录 Black FlagResynced（重制版）仓库——刻意排除。

此外，调研涉及的游戏内自研实践还叠加了另一层陷阱，见 Rogue 笔记 的完整清单：hook 回调内一次内存错误会让该回调被框架 SEH 保护永久禁用（日志显示 "Hook callback crashed — permanently disabled"）——因此每次解引用前用VirtualQuery等可读性检查守卫指针，并把每个实验放进独立 hook。另注意 AC4 笔记 中的工程细节：AC4BFSP.exe是 x86，ASI loader 必须是 32 位版；Ghidra 对 43 MB x86 exe 需要 20 GB 堆（8 GB 会 OOM）；g_MainPlayerPosition是 shader uniform 而非 CPU 全局，看似诱人实则不是要找的玩家位置；upc.exe（Ubisoft Connect）必须运行否则游戏静默退出。

成本、产出与未决问题

• 产出：本调研不含游戏文件（toolchain only），不适用 Assets 一节。
• 成本：单次会话（GitHub 调研 + README 阅读）；Rogue 笔记 补充了后续自研的成本结构——多数墙钟时间消耗在启动循环（见 强制退出导致僵尸进程的技术笔记）与两条廉价化身路线的证伪上。
• 未决问题（照抄自原文档，是下一个 agent 的接力点）：
  1. ScriptEngine.scrxAPI 到底暴露什么——仅相机/时间，还是实体与变换？若是后者，将是 AC4/Rogue 原生 Mod 的重大捷径。
  2. ACUFixes 的 ACU-RE 类库是否暴露可用于复制层的实体/变换访问？
  3. 在任意 AnvilNext 作品中，是否存在干净地生成/驱动第二个角色的方法（这是 AC Rogue co-op 工作中未打开的门）——Rogue 笔记 的领先思路是实体创建路径（FUN_1400c8c40/FUN_1400c8740）上的捕获-重放；AC4 笔记 则把引擎的CharacterSkinsComponent/ActionSwapSkin换肤路径（存在于AC4BFMP.exe）列为真模型替换的下一步。

小结

这份调研笔记的价值在于把"AC 家族 modding 地图"压缩成了一张可决策的表：引擎谱系决定了作品亲缘（Rogue≈Black Flag 减 MP），多人分布决定了 oracle 可用性（AC3/AC4/Unity 有、AC1/Rogue 无），工具矩阵决定了路线（ACUFixes→Unity 原生、AnvilToolkit/ACExplorer→forge 数据、ScriptEngine→AC4/Rogue 运行时）。而"无公共 co-op Mod"这一空白，结合仓库内三篇自研笔记从in-progress到working的推进，恰好示范了知识库的工作方式——调研先行、诚实标注验证边界、把死路写下来留给下一个 agent、用机械 oracle 而非自信判断来确认成果。对于任何准备涉足 AC 家族原生 Mod 或跨作品复制层项目的开发者，这份地图都是正确的起点。