【免费下载链接】ReSkate项目地址https://gitcode.com/gh_mirrors/re/ReSkate点击查看免费下载ReSkate 是一款面向 skate.Frostbite 引擎的开源增强工具它能离线运行游戏、自建服务器并把你放进Mods/文件夹里的 Mod 在启动时自动合并进游戏。本文将带你彻底搞懂 ReSkate 是如何解析 Frostbite 的三大核心数据格式——EBX、TOC 与 CAS再把多个 Mod 的修改缝成一个干净补丁的完整原理。ReSkate 是什么为什么值得研究ReSkate 是玩家自制项目非官方包含三大部分组件作用ReSkateLauncher.exe启动器校验游戏版本、安装游戏文件、管理 ModReSkate.dll运行时注入游戏提供菜单、控制台、Mod 合并等ReSkateServer.exe专用服务器无需游戏与 Steam 的无头大厅其中最有技术含量的部分就是Mod 合并系统你放进Mods/的每个 Mod 本质上都是对游戏原始数据层的增量修改而游戏引擎一次只认一层补丁。ReSkate 的工作就是把这些增量翻译成引擎能读懂的 Frostbite 数据格式再合成为唯一的一层补丁。要理解这个过程先要认识 Frostbite 的三个数据格式。一、Frostbite 的三层数据格式Frostbite 引擎组织游戏资源的方式可以概括为EBX 是内容TOC 是目录CAS 是仓库。1. EBX游戏资产的对象文档EBX 是 Frostbite 的序列化对象格式。游戏里的滑板、角色、物品、关卡配置本质上都是 EBX 资产里的实例instance。ReSkate 在 Engine/Resource/ebx_document.h 中完整实现了 EBX 的读取核心结构Document包含反射数据reflectionTypeDescriptor与FieldDescriptor描述每个类的字段名、字段类型整型、字符串、GUID、指针、数组等见FieldType枚举——这是 EBX 能自描述的关键实例InstanceRecord真正的对象数据每个实例有自己的 GUID可被导出、被其它文档引用导入表ImportReference跨文档引用靠fileGuid classGuid定位这是 Mod 之间互相指认资产的基础数组区ArrayRecord根对象上的列表比如本关卡包含哪些对象就存在这里Mod 添加物品往往就是往这些数组追加条目。也就是说改一个 EBX要么是改某个值一个数字、一个字符串要么是加一个实例一个新物品要么是往根数组追加引用把新物品挂进游戏的主列表。这三种变化正是后面合并算法要处理的全部情形。2. TOCSuperbundle 的目录清单单个 EBX 文件很小游戏内容被组织成bundle捆绑包再打包进superbundle超级捆绑包。而 TOCTable of Contents就是超级捆绑包的总目录定义见 Engine/Resource/toc.hTocBundle目录中每个 bundle 的条目TocChunk每个 chunk 的 GUID、在 CAS 中的位置CasIdentifier、字节偏移与大小bundleHashMap/chunkHashMap两张哈希索引表引擎靠它快速定位资源。toc_hash使用的 FNV 种子0x811C9DC5与引擎完全一致——合并后重建的哈希表必须让引擎原样解析这正是 write_patch_toc 能写出引擎可解析的补丁 TOC的原因。3. CAS压缩存储的集装箱TOC 里的位置最终指向磁盘上的cas_NN.cas归档文件。CAS 是 Frostbite 的分块压缩容器ReSkate 的编解码器见 Engine/Resource/cas_codec.h支持 Oodle 的kraken、selkie、leviathan三种压缩模式运行时直接链接 External/ 下的 lz4、zstd、minizOodle 则复用游戏自带的oo2core模块。bundle 的资产清单manifest也存放在 CAS 里结构见 Engine/Resource/binary_bundle.h一份 manifest 列出三类资产——ebx、resources如音频、Lua 脚本、chunks流式纹理块每个资产带 SHA1、GUID 与所在 CAS 文件的偏移。 一句话总结TOC 回答资源在哪CAS 回答字节在哪、怎么解压EBX 回答资源长什么样。二、Mod 合并原理把 N 个 Mod 缝成 1 层补丁引擎对每个 superbundle 只合成一个补丁层所以两个 Mod 都改了同一个 bundle时谁都不能直接覆盖谁。ReSkate 的合并入口是 merge_mods它把所有启用的 Mod 合成为Mods/.reskate/下的统一补丁。整个流程分四步第 1 步重新编号 CAS 归档。每个 Mod 出厂时都假设自己的cas_00.cas是1 号归档多个 Mod 放一起必然撞号。合并器给每个 Mod 的归档分一个专属编号并重写 Mod 补丁内的所有引用mod_merge_internal.h 中的ArchivePlacement。由于位置用 32 位偏移寻址单个归档不能超过 4 GB一个 Mod 一号段恰好让合并后的补丁没有自己的大小上限。第 2 步合并物理材质网格。这是最精巧的一步。地图 Mod 可以定义自己的碰撞表面每份地图都从游戏网格的第 116 号槽位开始追加自己的行——两个 Mod 都声称第 116 号是它的。material_grid.h 的Combiner把每个 Mod 的新增行依次拼接到一张网格的尾部并返回槽位重映射表把每个 Mod 的碰撞数据改写为新槽位号。这样引擎读到网格里的每个槽位都合法——因为引擎对槽位表不做越界检查读错一格就是碰撞瞬间崩溃。第 3 步逐个 superbundle 合并 bundle。这是主体工作由 mod_merge_combine.cpp 完成核心是逐资产比较资产情形合并策略游戏有、Mod 没动保留原版多个 Mod 都改了同一个 EBX调用 EBX 三向合并见下Mod 新增的资产追加进 manifest连同它引用的新文档一起搬走无任何 manifest 可读的 bundle整体透传优先级最高的 Mod 胜出纹理chunk还有一层细节chunk 元数据列表必须按 chunk GUID 排序、且替换的 chunk 要继承原版记录的首层 mip否则流式加载会出错merge_chunk_metadata。第 4 步写出补丁与指纹。合并结果带一份指纹SDK 版本 各 Mod 文件 被合并的原始文件。下次启动若指纹没变直接复用上次的Mods/.reskate/秒进游戏mod_merge_stamp.cpp。报告结构MergeReportmod_merge.h还会记录每个 Mod 的失败原因日志里能点名是哪个 Mod 拖累了哪个关卡。核心算法EBX 三向合并两个 Mod 都基于同一份原版 EBX 各自修改后如何合成merge_documents 以原版为 base做三向合并规则非常克制新增实例各 Mod 添加的实例全部保留根数组追加两边都追加的同一个引用只记一次原地改值同一字段被多个 Mod 改成不同值时按优先级顺序应用最后一个赢其它形状的变化指针改指别处、列表中间插值无法安全合并保留原版并在MergeSummary里记录是哪份编辑没被采纳。MergeSummary::exact()会告诉你这次合并是否每个编辑的每处改动都完整落地为日志与排查提供依据。三、进阶游戏运行中也能热合并更妙的是ReSkate 支持活合并live merge在游戏不重启的情况下于两次关卡加载之间重新合并。难点在于引擎不会释放已挂载的归档所以活合并不替换任何已打开的文件——新清单追加到 1 号归档末尾superbundle TOC 每次挂载都会重读、因此可以放心重写mod_merge.h。这就是为什么大多数 Mod 变更无需重启游戏即可生效。四、想深入源码从这里开始想看的模块路径EBX 解析与三向合并Engine/Resource/ 下的ebx_document.*、ebx_merge.*TOC 读写与哈希Engine/Resource/toc.cppCAS 压缩编解码Engine/Resource/cas_codec.cppMod 合并主流程Engine/Vfs/mod_merge.cpp、mod_merge_combine.cpp归档重编号Engine/Vfs/mod_merge_cas_store.cpp材质网格合并Engine/Resource/material_grid.cpp总结ReSkate 的 Mod 合并本质上是一套格式级的三向合并系统——用 EBX 反射数据理解内容用 TOC 哈希表重建目录用 CAS 归档重组存储最后把 N 个 Mod 的差异收敛成引擎唯一接受的一层补丁。理解这三套格式后你不仅能看懂 ReSkate 的日志也具备了给 skate. 开发或调试 Mod 的底层知识。赞分享【免费下载链接】ReSkate项目地址https://gitcode.com/gh_mirrors/re/ReSkate点击查看免费下载相关推荐Czkawka完整指南如何快速清理电脑垃圾文件释放存储空间Czkawka完整指南如何快速清理电脑垃圾文件释放存储空间 你是否经常遇到电脑存储空间不足的困扰 重复的照片、无用的临时文件、空文件夹...这些数字垃桌面应用CLINullAway数据流分析揭秘深入理解null安全检测原理NullAway数据流分析揭秘深入理解null安全检测原理 NullAway是一款强大的Java空指针异常NPE检测工具通过静态分析技术帮助开发者在编译Google Java Format 核心架构解析代码格式化原理揭秘Google Java Format 核心架构解析代码格式化原理揭秘 Google Java Format 是一款强大的 Java 代码格式化工具它严格遵循开发工具格式化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/16 11:19:14 · 阅读 1.2k 用ReSkate解析Frostbite数据格式：EBX、TOC与CAS的Mod合并原理全揭秘
【免费下载链接】ReSkate项目地址https://gitcode.com/gh_mirrors/re/ReSkate点击查看免费下载ReSkate 是一款面向 skate.Frostbite 引擎的开源增强工具它能离线运行游戏、自建服务器并把你放进Mods/文件夹里的 Mod 在启动时自动合并进游戏。本文将带你彻底搞懂 ReSkate 是如何解析 Frostbite 的三大核心数据格式——EBX、TOC 与 CAS再把多个 Mod 的修改缝成一个干净补丁的完整原理。ReSkate 是什么为什么值得研究ReSkate 是玩家自制项目非官方包含三大部分组件作用ReSkateLauncher.exe启动器校验游戏版本、安装游戏文件、管理 ModReSkate.dll运行时注入游戏提供菜单、控制台、Mod 合并等ReSkateServer.exe专用服务器无需游戏与 Steam 的无头大厅其中最有技术含量的部分就是Mod 合并系统你放进Mods/的每个 Mod 本质上都是对游戏原始数据层的增量修改而游戏引擎一次只认一层补丁。ReSkate 的工作就是把这些增量翻译成引擎能读懂的 Frostbite 数据格式再合成为唯一的一层补丁。要理解这个过程先要认识 Frostbite 的三个数据格式。一、Frostbite 的三层数据格式Frostbite 引擎组织游戏资源的方式可以概括为EBX 是内容TOC 是目录CAS 是仓库。1. EBX游戏资产的对象文档EBX 是 Frostbite 的序列化对象格式。游戏里的滑板、角色、物品、关卡配置本质上都是 EBX 资产里的实例instance。ReSkate 在 Engine/Resource/ebx_document.h 中完整实现了 EBX 的读取核心结构Document包含反射数据reflectionTypeDescriptor与FieldDescriptor描述每个类的字段名、字段类型整型、字符串、GUID、指针、数组等见FieldType枚举——这是 EBX 能自描述的关键实例InstanceRecord真正的对象数据每个实例有自己的 GUID可被导出、被其它文档引用导入表ImportReference跨文档引用靠fileGuid classGuid定位这是 Mod 之间互相指认资产的基础数组区ArrayRecord根对象上的列表比如本关卡包含哪些对象就存在这里Mod 添加物品往往就是往这些数组追加条目。也就是说改一个 EBX要么是改某个值一个数字、一个字符串要么是加一个实例一个新物品要么是往根数组追加引用把新物品挂进游戏的主列表。这三种变化正是后面合并算法要处理的全部情形。2. TOCSuperbundle 的目录清单单个 EBX 文件很小游戏内容被组织成bundle捆绑包再打包进superbundle超级捆绑包。而 TOCTable of Contents就是超级捆绑包的总目录定义见 Engine/Resource/toc.hTocBundle目录中每个 bundle 的条目TocChunk每个 chunk 的 GUID、在 CAS 中的位置CasIdentifier、字节偏移与大小bundleHashMap/chunkHashMap两张哈希索引表引擎靠它快速定位资源。toc_hash使用的 FNV 种子0x811C9DC5与引擎完全一致——合并后重建的哈希表必须让引擎原样解析这正是 write_patch_toc 能写出引擎可解析的补丁 TOC的原因。3. CAS压缩存储的集装箱TOC 里的位置最终指向磁盘上的cas_NN.cas归档文件。CAS 是 Frostbite 的分块压缩容器ReSkate 的编解码器见 Engine/Resource/cas_codec.h支持 Oodle 的kraken、selkie、leviathan三种压缩模式运行时直接链接 External/ 下的 lz4、zstd、minizOodle 则复用游戏自带的oo2core模块。bundle 的资产清单manifest也存放在 CAS 里结构见 Engine/Resource/binary_bundle.h一份 manifest 列出三类资产——ebx、resources如音频、Lua 脚本、chunks流式纹理块每个资产带 SHA1、GUID 与所在 CAS 文件的偏移。 一句话总结TOC 回答资源在哪CAS 回答字节在哪、怎么解压EBX 回答资源长什么样。二、Mod 合并原理把 N 个 Mod 缝成 1 层补丁引擎对每个 superbundle 只合成一个补丁层所以两个 Mod 都改了同一个 bundle时谁都不能直接覆盖谁。ReSkate 的合并入口是 merge_mods它把所有启用的 Mod 合成为Mods/.reskate/下的统一补丁。整个流程分四步第 1 步重新编号 CAS 归档。每个 Mod 出厂时都假设自己的cas_00.cas是1 号归档多个 Mod 放一起必然撞号。合并器给每个 Mod 的归档分一个专属编号并重写 Mod 补丁内的所有引用mod_merge_internal.h 中的ArchivePlacement。由于位置用 32 位偏移寻址单个归档不能超过 4 GB一个 Mod 一号段恰好让合并后的补丁没有自己的大小上限。第 2 步合并物理材质网格。这是最精巧的一步。地图 Mod 可以定义自己的碰撞表面每份地图都从游戏网格的第 116 号槽位开始追加自己的行——两个 Mod 都声称第 116 号是它的。material_grid.h 的Combiner把每个 Mod 的新增行依次拼接到一张网格的尾部并返回槽位重映射表把每个 Mod 的碰撞数据改写为新槽位号。这样引擎读到网格里的每个槽位都合法——因为引擎对槽位表不做越界检查读错一格就是碰撞瞬间崩溃。第 3 步逐个 superbundle 合并 bundle。这是主体工作由 mod_merge_combine.cpp 完成核心是逐资产比较资产情形合并策略游戏有、Mod 没动保留原版多个 Mod 都改了同一个 EBX调用 EBX 三向合并见下Mod 新增的资产追加进 manifest连同它引用的新文档一起搬走无任何 manifest 可读的 bundle整体透传优先级最高的 Mod 胜出纹理chunk还有一层细节chunk 元数据列表必须按 chunk GUID 排序、且替换的 chunk 要继承原版记录的首层 mip否则流式加载会出错merge_chunk_metadata。第 4 步写出补丁与指纹。合并结果带一份指纹SDK 版本 各 Mod 文件 被合并的原始文件。下次启动若指纹没变直接复用上次的Mods/.reskate/秒进游戏mod_merge_stamp.cpp。报告结构MergeReportmod_merge.h还会记录每个 Mod 的失败原因日志里能点名是哪个 Mod 拖累了哪个关卡。核心算法EBX 三向合并两个 Mod 都基于同一份原版 EBX 各自修改后如何合成merge_documents 以原版为 base做三向合并规则非常克制新增实例各 Mod 添加的实例全部保留根数组追加两边都追加的同一个引用只记一次原地改值同一字段被多个 Mod 改成不同值时按优先级顺序应用最后一个赢其它形状的变化指针改指别处、列表中间插值无法安全合并保留原版并在MergeSummary里记录是哪份编辑没被采纳。MergeSummary::exact()会告诉你这次合并是否每个编辑的每处改动都完整落地为日志与排查提供依据。三、进阶游戏运行中也能热合并更妙的是ReSkate 支持活合并live merge在游戏不重启的情况下于两次关卡加载之间重新合并。难点在于引擎不会释放已挂载的归档所以活合并不替换任何已打开的文件——新清单追加到 1 号归档末尾superbundle TOC 每次挂载都会重读、因此可以放心重写mod_merge.h。这就是为什么大多数 Mod 变更无需重启游戏即可生效。四、想深入源码从这里开始想看的模块路径EBX 解析与三向合并Engine/Resource/ 下的ebx_document.*、ebx_merge.*TOC 读写与哈希Engine/Resource/toc.cppCAS 压缩编解码Engine/Resource/cas_codec.cppMod 合并主流程Engine/Vfs/mod_merge.cpp、mod_merge_combine.cpp归档重编号Engine/Vfs/mod_merge_cas_store.cpp材质网格合并Engine/Resource/material_grid.cpp总结ReSkate 的 Mod 合并本质上是一套格式级的三向合并系统——用 EBX 反射数据理解内容用 TOC 哈希表重建目录用 CAS 归档重组存储最后把 N 个 Mod 的差异收敛成引擎唯一接受的一层补丁。理解这三套格式后你不仅能看懂 ReSkate 的日志也具备了给 skate. 开发或调试 Mod 的底层知识。赞分享【免费下载链接】ReSkate项目地址https://gitcode.com/gh_mirrors/re/ReSkate点击查看免费下载相关推荐Czkawka完整指南如何快速清理电脑垃圾文件释放存储空间Czkawka完整指南如何快速清理电脑垃圾文件释放存储空间 你是否经常遇到电脑存储空间不足的困扰 重复的照片、无用的临时文件、空文件夹...这些数字垃桌面应用CLINullAway数据流分析揭秘深入理解null安全检测原理NullAway数据流分析揭秘深入理解null安全检测原理 NullAway是一款强大的Java空指针异常NPE检测工具通过静态分析技术帮助开发者在编译Google Java Format 核心架构解析代码格式化原理揭秘Google Java Format 核心架构解析代码格式化原理揭秘 Google Java Format 是一款强大的 Java 代码格式化工具它严格遵循开发工具格式化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考