dd

前排提醒：
1. 目前对GG3的研究基本上是原始水平，不要有太高的期待
2. 将三btl难度空前（肯定不绝后），本贴对新人极不友好
3. 为什么不发将三吧呢？
原因比较简单…你看那里的吧主
抛砖引玉，不喜轻喷～

前排提示2
虽然本贴发布btl结构，截至目前我并没有改出什么有意义的东西来，原因后面会说的

【基础】
本贴接下来用的数据类型：整数---char=1字节，short=2字节，long=4字节；小数Single=4字节
“指针”：百度百科定义如下
系统在内存中，为变量分配存储空间的首个字节单元的地址，称之为该变量的地址。地址用来标识每一个存储单元，方便用户对存储单元中的数据进行正确的访问。在高级语言中地址形象地称为指针。一个指针变量的值就是某个内存单元的地址，称为某内存单元的指针。
本人借用【指针】这个词，来定义在将三btl中常见的存储【从指针自身的位置向后找到目标数据所需偏移量】的变量
比如说如果一串十六进制数为0C 00 00 00 04 00 00 00 11 45 14 00 19 19 81 00，那么你可以从指针04 00 00 00 向【后】偏移4字节读取到它对应的实际数据11 45 14 00，从指针0C 00 00 00向【后】偏移0C字节读取到它对应的实际数据19 19 81 00.
另外一些时候，指针偏移是向【前】的，称这样的指针为【“反向指针”】，比如说如果一串十六进制数为08 00 06 00 08 00 04 00 08 00 00 00，那么你可以从反向指针08 00 00 00 向【前】偏移8字节读取到它对应的实际数据08 00 06 00.
指针永远都是long类型。

进入正题吧
1. 主数据
80字节，下面抄自stage10604.btl
20 00 00 00
00 00 1A 00
30 00 2E 00
28 00 24 00
20 00 1C 00
18 00 14 00
10 00 08 00
0C 00 04 00 以上为固定格式
1A 00 00 00 未知，一般都是这个数
2C 00 00 00 指针，指向Luac段的开头
F8 00 00 00 指针，指向未知A段的开头
F8 00 00 00 指针，一般和上一个数一样
4C 01 00 00 指针，指向未知B段开头
80 01 00 00 指针，指向单位段开头
BC 18 00 00 指针，指向建筑段开头
84 1F 00 00 指针，指向军团段开头
F0 2E 00 00 指针，指向接口段开头
38 2F 00 00 指针，指向胜利条件段开头
5C 21 00 00 指针，指向地形段开头
00 00 01 00 固定格式

2. 未知的部分
Luac脚本段 存储一部分加密脚本，Luac决定了将三战役的事件------但是我对这个无能为力
btl文件中未必包含Luac，因此这部分的内容分两种情况：
有Luac：（10604.btl）
C9 00 00 00 指针，指向luac结束处
(.......luac内容)
0D 24 02 28 luac的内容，意义未知（!!!!!!）
01 00 00 00 luac结束
无Luac：8字节（10101.btl）
04 00 00 00 指针，指向luac结束处
00 00 28 01 固定格式

未知A段
这部分甚至作用都是未知的，同样分有无实际内容两种情况
无实际内容：28字节（10601.btl）
94 EF FF FF 指针，指向一个未知的独立块，位置不定
3A EF FF FF 指针，指向建筑段结束
04 00 00 00 固定格式，也可以理解为指向条目总数的指针
00 00 00 00 总数，为0所以没有后续
0C 00 14 00
04 00 08 00
0C 00 10 00 段落结束，固定格式
*独立块：将三btl中存在大量意义未知的小块，由看起来没有什么意义的一组short变量组成，随机分布在Luac段后整个文件中。
有实际内容：10401.btl
34 E4 FF FF 反向指针，指向一个未知的独立块，位置不定
CE E3 FF FF 反向指针，指向建筑段结束
04 00 00 00 固定格式，也可以理解为指向条目总数的指针
02 00 00 00 未知A段的条目总数
28 00 00 00 指针，数量与上面的条目总数相同，指向第n个条目的开始
10 00 00 00 第二个指针，这里一共有2个
(00 00 0A 00 中间段，不一定有；不知道是什么，值不确定
0A 00 00 00
06 00 08 00)
0A 00 00 00 第一个指针指向的位置，条目开始
00 00 03 00
01 00 0A 00
0C 00 07 00
08 00 0A 00
0A 00 00 00 第二个条目
00 00 00 03
01 00 02 00
0C 00 14 00
04 00 08 00
0C 00 10 00 段落结束，固定格式

未知B段 56字节 这里似乎是固定的，贴一个上来吧
0C 00 00 00
24 00 00 00
1C 00 00 00
10 00 00 00
04 00 00 00
04 00 00 00
00 00 28 01
04 00 00 00
00 00 28 01
00 00 00 00
00 00 00 00
00 00 0A 00
10 00 08 00
0C 00 06 00

3.单位
重头戏来了~
总纲：
大部分段落都遵循【固定格式开头】--【总数】--【指针】--【数据】--【固定格式结尾】的格式。
将三btl的一大特点就是每一条信息（比如一个兵，一个城市/工事）在btl中的长度是不一定的，相对复杂的元素会占用更大的体积。
所以这两条叠加在一起时.....
当你试图给地图上的小兵添加一个将领，这个单位在btl中的长度就增加，从而所有指针的偏移量都要重新计算（！！！），这也导致了十六进制直接手改将三btl 【基本上没有可能】。
那么如果到这里还有耐心 就往下看吧~

部队（单位）信息的——
固定格式开头：16字节
0A 00 00 00 固定格式
00 00 62 00 未知意义的总数，=第一个单位的序号+1
20 00 00 00 指针，指向单位总数
04 00 00 00 指针，指向未知C数据总数
未知C数据的指针段
05 00 00 00 未知C总数
AC 01 00 00 以下为指针，指向第N条未知C数据的位置，数量与未知C总数相同
(...)
24 01 00 00
单位数据的指针段
47 00 00 00 单位总数
A8 0E 00 00 以下为指针，指向第N条单位数据的位置，数量与单位总数相同
(...)
90 00 00 00
未知C数据的数据段，每一句以指针指到的位置为开头
注意每一段长度未必是一样的，这部分数据是什么意义目前还不知道
90 FF FF FF 反向指针，本段中所有指针指向同一个位置
00 00 05 00 序号
04 00 00 00
06 00 00 00
04 00 10 00
21 00 22 00
42 00 43 00
单位数据的数据段，每一句以指针指到的位置为开头
注意单位是不按顺序写的，每一段长度未必是一样的。
固定部分：28字节
90 F3 FF FF 反向指针1，指向【收尾独立块】
00 00 50 01 short1=？ short2=？
B7 00 01 00 short1=坐标 short2=军团
60 00 65 00 short1=单位序号（倒序，未必是连续的） short2=兵种
00 01 01 06 char1=等级 char2=编制 char3=朝向 char4=移动力
50 00 50 00 short1=当前血量 short2=最大血量（？）
64 00 00 00 short1=血量倍率 short2=？
指针部分：标配44字节，可能增减
指针1-3都指向有实际意义的块，顺序为：AI，特殊兵，将领，三种都有时基本结构如下：
20 00 00 00 指针3，第一个出现的指针一定是指向AI的
10 00 00 00 指针2，指向特殊兵种
04 00 00 00 指针1，指向将领
7E FD FF FF 反向指针2 指向未知验证块，这些验证块通常是夹在指针1与反向指针2之间的
00 00 3B 04 short1=将领星星 short2=将领id，请查json
96 FE FF FF 反向指针3 指向未知验证块，这些验证块通常是夹在反向指针3与反向指针4之前的
00 00 00 02 short2=特殊兵的等级，0级则该4字节消失
A0 01 91 00 short1=特殊兵种id，short2=血量
91 00 64 00 short1=特殊兵种血量，short2=血率？
D6 FF FF FF 反向指针4 指向未知验证块，同反向指针3
00 02 75 01 short1=AI相关，玩家的单位没有这4字节
单位信息的收尾
00 00 0E 00 这里前两个字节不固定，可能是前一个单位的AI
14 00 04 00
08 00 00 00
0C 00 10 00 固定格式

这里补充一下，关于独立块
已经发现在【每条信息的最后】 或者【指针与它所指的信息之间】 有时候会插入独立块，分析10101.btl最后一个单位如下：
04 02 04 02 64 00 00 00 这个显然是血量和血率（100%）
28 00 00 00 0C 00 00 00 00 00 06 00 08 00 06 00 28和0C 对应上述指针部分的AI和将领
06 00 00 00 00 00 37 04 10 00 0A 00 00 00 00 00
00 00 07 00 00 00 08 00 10 00 00 00 00 00 00 02
那么分析指针0C 00 00 00指向的字节为：06 00 00 00，这是一个反向指针，往前数6字节 得到00 00 【06 00】，这就是一个独立块，共有8个字节（00 00 06 00 08 00 06 00），其长度为6 但由于凑4的倍数而变成了8；
下一组字节为 00 00 37 04，查stringtable可知将领（4*256+3*16+7= 1079）为古德里安；
查上楼可知再下一组字节应该是AI，但实际上是是 10 00 0A 00，又看不懂了；分析指针 28 00 00 00 指向的字节为10 00 00 00，这是一个反向指针，向前推【10h】个字节即找到独立块（10 00 0A 00 00 00 00 00 00 00 07 00 00 00 08 00)
把独立块去掉，将三的btl还是很有规律的

4. 建筑
将三中工事也算建筑；建筑是按右下往左上的顺序写的（地块id越来越小）
开头，至少32字节 这实际上是一组指针结构
0E 00 00 00
1C 00 00 00 指针1 指向建筑总数
14 00 00 00 指针2
0C 00 00 00 指针3
04 00 00 00 指针4 这三个指针好像没啥意义
00 00 00 00
00 00 00 00
00 00 00 00
41 00 00 00 建筑总数
指针区
FC 09 00 00 建筑指针，指向第N条建筑数据的位置，数量与建筑总数相同
(...)
内容
工事 基本结构：20字节
26 F8 FF FF 反向指针 一般指向收尾的独立块
00 00 07 02 short2=坐标
04 00 00 00 指针，指向反向指针-工事
0A F9 FF FF 反向指针-工事 一般指向该反向指针与上面一行之间插入的独立块
00 00 00 02 char4=工事类型（fort...json) 这部分可能被独立块挤成2字节
建筑 基本结构：48字节
8C F7 FF FF 反向指针 一般指向收尾的独立块
(00 00 00 01 未知的验证块，很少见；暂时不知道怎么处理）
00 00 F2 01 short2=坐标
04 00 00 00 指针，指向反向指针-建筑
42 F7 FF FF 反向指针-建筑 一般指向该反向指针与上面一行之间插入的独立块
01 00 70 00 char1=阵营，short2=建筑类型(building...json)
01 03 00 00 未知
14 00 00 00 本段长度？
0C 00 00 00 指针，指向反向指针2
04 00 00 00 指针，指向反向指针1
34 F7 FF FF 反向指针1
00 00 00 00
3C F7 FF FF 反向指针2 反向指针1/2之前可能会插入独立块，这两个指针指向独立块的位置
？？ 征服模式中特有的建筑，8字节
9C D9 FF FF 反向指针？
51 0B 59 01 short1=位置？
收尾
1C 00 00 00 收尾A，32字节 本部分在最后一条【城市】后出现，不一定在整段最后，因为最后一条建筑信息可能是工事
10 00 00 00
08 00 00 00
04 00 04 00
04 00 00 00
00 00 00 00
04 00 06 00
04 00 00 00
00 00 06 00 收尾B,8字节，固定出现在建筑大段最后
08 00 04 00