找回密码
 点一下
查看: 6961|回复: 3

【翻译99%】w3g格式说明

  [复制链接]
发表于 2008-7-3 16:31:36 | 显示全部楼层 |阅读模式
写在前面的翻译附注
(...)
1.简介
2.头文件
2.1 版本0
2.2 版本1
2.3 版本信息
2.4 冰封王座beta版的replay信息
3.数据块
4数据分解
   4.1玩家记录
   4.2游戏名
   4.3字符编码
   4.4游戏设置
   4.5地图或地图创建名
   4.6玩家数
   4.7游戏类型
   4.8语言版本
   4.9玩家列表
   4.10游戏起始记录
   4.11时隙记录
   4.12随机种子
5.录像数据
6.一般注释
   6.1暴雪官方录像的注释
7
8文本版本历史
否认声明(好吧,请无视。。)
本篇中所有信息据说均是从录像文件中查找或通过猜测获得。所有关于游戏运行机理的内容来源于玩游戏时的体会。。这些都不关逆向工程和编辑修
改合法文件的事,咳咳。明确禁止利用本文提供的信息去干违法勾当,诸如黑客注入、作弊、盗版。感谢暴雪公司的伟大游戏和直接明了的魔兽录像
文件格式。
在你能够\遵从以上规则下,本文所提供的信息一切免费。允许在不更变下作原文转载(请将你发现的错误或意见发给我们,我们会集中处理)
在你的工程中提及对我们的引用或留一行邮件地址,我们希望知道这篇文档中的内容是否适用,非常感谢。
1. 简介
写在前面的重要文字
本篇中的有关信息资料是用于服务那些致力开发程序、工具和网页的开发者们,有助于丰富游戏内涵和“整个”魔兽界。
我们绝不宽恕黑客与欺诈行为。为此你要保证不将本文提供的信息用于以上用途。本文包含有对录像文件的描述和格式说明。关于单独模块和算法部
分的附加注释和解释说明将来某天会作为文件单独放出("w3g_notes.txt")。完整的文件仍在构造中。一些被认为是“未知”或已知的地方也许存在
错误。请及时联系我们,如果你发现任何的未知或和现有“已知”不合的情况。
引文惯例:
录像文件中直接数据引用部分用中括号[ ]
2.头文件
录像文件包含一个可分解为一系列压缩数据块的头文件,它遵从以下格式
偏移   |大小/类型    | 描述
0x0000 |28个字符     | 从零端开始"Warcraft III recorded game\0x1A\0"
0x001c |一个dword  | 第一个压缩数据块的定位(文件头大小)
              |                     | 0x40 魔兽争霸 1.06及以前版本(RoC)
              |                     | 0x44 魔兽争霸 1.07及以后版本,包括了资料篇冰封王座的录像
0x0020 |一个dword | 整个压缩文件大小
0x0024 |一个dword | 录像头文件版本
              |                     | 0x00魔兽争霸 1.06及以前版本(RoC)
              |                     | 0x01 魔兽争霸 1.07及以后版本,包括了资料篇冰封王座的录像
0x0028 |一个dword  | 整个解压后的数据大小(含文件头)
0x002c |一个dword  | 文件中的压缩数据块数目
0x0030 |n bytes       | 局部文件头(间 2.1和2.2节)
目前除去局部文件头后的头文件大小为0x30 bytes
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2.1 [局部文件头]对应头文件 版本0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
该文件头适用于魔兽争霸1.06及以前的录像档案。
偏移   |大小/类型   | 描述
0x0000 |一个单字word| 作用未知(似乎一直为0)
0x0002 |一个单字word| 版本号,(对应补丁的1.xx)
0x0004 |一个单字word| 主程序版本(参见2.3节)
0x0006 |一个单字word| 标识
              |                         | 0x0000  单人游戏
              |                         | 0x8000  多人游戏(局域网或者战网)
0x0008 |一个单字word| 录像长度,以毫秒计
0x000C |一个单字word| 头文件的crc32校验和
              |                          |(效验值计算了整个头文件,包括那些为0的部分)
版本0的整个文件头大小为0x40 bytes
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2.2 [局部文件头]对应头文件 版本1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
该文件头适用于魔兽争霸1.07及以后的录像档案。
偏移   |大小/类型    | 描述
0x0000 |一个单字word | 版本标识描述字符串:
              |                          | ‘WAR3’为魔兽争霸原始版本,’W3XP’为资料片“冰封王座”
              |                          | (注意,录像文件中字符格式little endian,低字节在前)
0x0004 |一个单字word| 版本号,(对应补丁的1.xx)
0x0008 |一个单字word| 主程序版本(参见2.3节)
0x0006 |一个单字word| 标识
              |                         | 0x0000  单人游戏
              |                         | 0x8000  多人游戏(局域网或者战网)
0x000C |一个单字word| 录像长度,以毫秒计
0x0010 |一个单字word| 头文件的crc32校验和
              |                         |(效验值计算了整个头文件,包括那些为0的部分)
版本1的整个文件头大小为0x44 bytes
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2.3 版本信息
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
游戏版本    | 录像文件版本  | 主程序war3.exe版本 |  放出的日期
--------------+-------------------+---------------------+----------------
    1.00      |    1.00.4448    |      1.0. 0.4448    |  2002-07-03
    1.01      |    1.01.4482    |      1.0. 1.4482    |  2002-07-05
    1.01b    |    1.01.4482    |      1.0. 1.4483    |  2002-07-10
    1.01c    |    1.01.4482    |                ?            |  2002-07-28
    1.02      |    1.02.4531    |      1.0. 1.4531    |  2002-08-15
    1.02a    |    1.02.4531    |      1.0. 1.4563    |  2002-09-06
    1.03      |    1.03.4572    |      1.0. 3.4653    |  2002-10-09
    1.04      |    1.04.4654    |      1.0. 3.4709    |  2002-11-04
    1.04b    |    1.04.4654    |      1.0. 3.4709    |  2002-11-07
    1.04c    |    1.04.4654    |      1.0. 4.4905    |  2003-01-30
    1.05      |    1.05.4654    |      1.0. 5.4944    |  2003-01-30
    1.06      |    1.06.4656    |      1.0. 6.5551    |  2003-06-03
    1.07      |    1.07.6031    |      1.0. 7.5535    |  2003-07-01
    1.10      |    1.10.6034    |      1.0.10.5610   |  2003-06-30
    1.11      |    1.11.6035    |      1.0.11.5616   |  2003-07-15
    1.12      |    1.12.6036    |      1.0.12.5636   |  2003-07-31
    1.13      |    1.13.6037    |      1.0.13.5816   |  2003-12-16
    1.13b    |    1.13.6037    |      1.0.13.5818   |  2003-12-19
    1.14      |    1.14.6039    |      1.0.14.5840   |  2004-01-07
    1.14b    |    1.14.6040   |      1.0.14.5846    |  2004-01-10
    1.15      |    1.15.6043    |      1.0.15.5917    |  2004-04-14
    1.16      |    1.16.6046    |      1.0.16.5926    |  2004-05-10
    1.17      |    1.17.6050    |      1.0.17.5988    |  2004-09-20
    1.18      |    1.18.6051    |      1.0.18.6030    |  2005-03-01
特殊版本的注释:
  o 1.02a的mpq文档命名为1.02c.
  o 1.04b单独作为一个独立补丁(无法流通于bn),单独增加了一个war3.exe的保护模块。
  o 以下war3.exe程序细分版本号并非与补丁号一致
    1.02, 1.02a, 1.04, 1.04b.
  o 暴雪发布的非独立版本补丁包括::
    1.01c, 1.04c, 1.10.
  o 1.14和1.14b版本的录像不相容
一般注释:
  o 各个细分版本的录像文件无差别。(除了1.14和1.14b)
    (except for patch 1.14 and 1.14b).
  o 你可以从war3.exe的文件属性中得到当前的魔兽版本
  o RoC和TFT在相同版本下无差别
  o 不同语言版本无差别.
  o 你可以通过在游戏中查看'war3.exe'的'创建版本号'来辨识录像版本
  o 你可以在文件资源的文件版本序列识别war3.exe的版本
  o 最早的补丁号与与程序版本号一致,后来分开了
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2.4 魔兽争霸3 冰封王座beta的录像信息
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2.4.1 冰封王座Beta 版详细 (version 1.07)
--------------------------------------------------
Beta 录像与混沌之丗/冰封王座最终版类似.
这里是一些版本列表、头文件版本号和主程序版本号:
版本   | 局部文件头版本| 程序版本# | 放出日期
--------+-------------------+--------+--------------
301    | version 0        |  6010  |  2003-03-04
302    | version 0        |  6011  |  2003-03-11
303    | version 0        |  6012  |  2003-03-14
304    | version 0        |  6013  |  2003-03-19
304a  | version 0       |  6013  |  2003-03-24
305    | version 1(*)   |  6015  |  2003-03-28
305a  | version 1(*)   |  6016  |  2003-03-30
306    | version 1        |  6018  |  2003-04-08
307    | version 1        |  6019  |  2003-04-11
308    | version 1        |  6021  |  2003-04-16
309    | version 1        |  6022  |  2003-04-17
310    | version 1        |  6023  |  2003-04-24
311    | version 1        |  6027  |  2003-04-30
312    | version 1        |  6030  |  2003-05-13
313    | version 1        |  6031  |  2003-05-19
314    | version 1        |  6034  |  2003-05-30
314a  | version 1        |  6034  |  2003-06-02
315    | version 1        |  6034  |  2003-06-10
(*) 305、305a仍使用旧版v0的游戏版本格式 (2 words).
  注释:
  o 313 的录像可认为转化为零售冰封王座1.07录像.
  o 315 的录像可认为转化为零售冰封王座1.10录像.
2.4.1 各个版本的Beta 版
--------------------------------------
这些版本只分布于'Westfall' 网关(beta测试).
版本   | 录像标示版本| 程序版本  | 放出日期    |作为测试版本beta
---------+--------------+-----------------+--------------+----------------
  1.15   | 1. 15.6041      |1.0.15.5900      |  2004-04-16  |  patch 1.15
  1.401  | 1.401.6042   |401.0. 0.5911   |  2004-04-22  |  patch 1.15
  1.402  |                         |                            |  2004-04-24  |  patch 1.15
  1.403  |                         |                            |  2004-06-23  |  Ladder XP
  1.404  |                         |                            |  2004-08-14  |  patch 1.17
  1.405  |                         |                            |  2004-08-19  |  patch 1.17
  1.406  |                         |                            |  2004-08-31  |  patch 1.17
===============================================================================
3.0 [数据块文件头]
===============================================================================
每个压缩数据块均包含有一个文件头,压缩数据紧随其后。
第一个数据块的始端地址由录像文件的头文件给出。
接下来的全部地址由位于始端的数据块文件头给出.
解压后的数据块表现为一个单独连续的数据流(除去块的头文件)。
(disregarding the block headers). 数据流(间第4节)的内容完全独立于原始块边界.
偏移   | 大小/数据类型 | 描述
-------+-----------+-----------------------------------------------------------
0x0000 |  一个单字word|   压缩数据块大小 (含头文件)
0x0002 |  一个单字word|   数据块的解压大小 (目前 8k)
0x0004 | 一个双字dword|  未知 (也许是效验字节)
0x0008 |  n bytes     |   压缩数据 (使用 zlib)
使用zlib进行解压
1. call 'inflate_init'
2. call 'inflate' with Z_SYNC_FLUSH for the block
数据块剩余部分填充’0’至8k. 这些字节可被忽略.
//TODO: 增加对解压数据的说明并将其单独列出。
 楼主| 发表于 2008-7-5 01:02:53 | 显示全部楼层

Section 4

===============================================================================
4.0 [解压出的数据]
===============================================================================
解压出来的数据是原来数据流中紧连数据单位的集合. 此类数据项的偏移由其大小确。
本小节的内容是录像数据流中起始记录的内容,其中记录有关于游戏设置与玩家的信息。游戏过程中的相关数据在第5节会讨论到
起始数据的格式如下::
# |  大小  | 名称
---+----------+--------------------------
1 |  4 byte | 未知 (0x00000110 - another record id?)
2 | 可变   |玩家记录 (见 4.1)
3 | 可变   | 游戏名称(0值结尾) (见 4.2)
4 |  1 byte | 空字节
5 | 可变   | 编码字符 (0值结尾) (见 4.3)
   |               |  - 游戏设置 (见 4.4)
   |              |  - 游戏创建或地图名 (见 4.5)
6 |  4 byte | 玩家数 (见 4.6)
7 |  4 byte | 游戏类型 (见 4.7)
8 |  4 byte | 语言 (见 4.8)
9 | 可变 | 玩家哦列表(见 4.9)
10 | 可变 | 游戏起始记录 (见 4.11)
下面几小节将详细分述
除去这些静态数据项(上面的) ,后面数据块携带的可变信息在第5节说明
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4.1 [玩家记录]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
偏移   | 大小/类型 | 描述
-------+-----------+-----------------------------------------------------------
0x0000   |  1 byte    | RecordID:
                |                |  0x00 游戏主机
                |               |  0x16 额外玩家 (参见 4.9)
0x0001   |  1 byte  | 玩家id
0x0002  |  n bytes | 玩家名字 (0值结尾)
  n+2      |  1 byte  | 额外数据大小:
               |               |  0x01 = 自定义游戏
                 |             |  0x08 = ladder对战
游戏类型决定以下数据:
o 自定义游戏:
偏移   | 大小/类型 | 描述
  -------+-----------+---------------------------------------------------------
  0x0000 | 1 byte    | null byte (1 byte)
o ladder上的对战:
偏移   | 大小/类型 | 描述
  -------+-----------+---------------------------------------------------------
  0x0000 | 4 bytes  | 游戏记录的持续时间(以毫秒记)
  0x0004 | 4 bytes  | 玩家种族标记:
                |          |  0x01=人族
                |          |  0x02=兽人
                |          |  0x04=暗夜精灵
                |          |  0x08=天灾
                |          |  (0x10=daemon 进程守护?)
                |          |  0x20=随机
                |          |  0x40=种族 可选/固定 (参见 4.11的注释)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4.2 [游戏名称]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
游戏名的编码为0值结尾的纯文本(ASCII?)
只有在战网(battle.net)上的自定义游戏中能够自命名游戏, 其他情况下游戏名称是固定的(这类修改已做出来过了,比如可修改“本地局域网的游戏”)
o 战网的天梯对战(ladder)其名为”BNet”.
o 自定义局域网游戏则含有一个语言本地化的游戏创建者的名字.
  例如: 玩家“Blue”所创建的游戏:
          "Blue's game" :英文版的 Warcraft III
          "Blue的游戏" 这是中文版的
o单人的自定义游戏则是固定的本地语言标识.
          "local game"  :英文版
          中文版是“当地局域网内的游戏”(为啥?不过这是可以改的)
o 下面的是一些语言版本的字符串 (纯文本 ASCII 编码) ,取自魔兽1.06及以前版本,没有中文的(自己找去= =)。
顺便告诉你可以在哪里修改这类本地语言字符串
  (see war3.mpq\\UI\\FrameDef\\GlobalStrings.fdf: GAMENAME, LOCAL_GAME):
  English        : "%s's Game"        : "local game"
  Czech    (1029): "Hra %s"            : "M韘tn?hra"
  German  (1031): "Spiel von %s"      : "Lokales Spiel"
  Spanish  (1034): "Partida de %s"    : "Partida local"
  French  (1036): "Partie de %s"      : "Partie locale"
  Italian  (1040): "Partita di %s"    : "Partita locale"
  Polish  (1045): "Gra (%s)"          : "Gra lokalna"
  %s 为游戏创建玩家名字.
o 1.07以后的一些变动,似乎只提到了德语的?还是原文不全?或者是统一格式
(local game+PlayerName)?
  (see war3.mpq\\UI\\FrameDef\\GlobalStrings.fdf: GAMENAME, LOCAL_GAME):
  German  (1031): "Lokales Spiel (%s)"  : "Lokales Spiel"
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4.3 [字符串的编码]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
游戏设置和3个0值结尾的字符串靠在一起编成单一0值结尾字符串,
(令人费解!)
每个字节值都加1. 所有编码字节为奇.
一个控制字节储存后7个字节的变化信息.
如此一来所有空字节变成1, 它们永不会出现在编码字符内. 而空字节的作用是标记编码字符串的结末.
编码字符串起始于一个控制字节.
控制字节以一位比特为后7个字节标记出位段. Bit 1 (not Bit 0) 指向控制字节之后的紧连字节, bit 2 为再下一个 , 如此.
只有Bit 1-7 分给编码字符的关连指向. Bit 0 不使用
解码方式如下:
如果关联位为 '1'则字符直接移动(不变).
如果关联位为 '0'则字符减1.
在一个控制字节和随后的7字节后又是一个控制字节,直到遇到一个空字符为止。

一段解码的代码举例( 用C):

[codes=c]char* EncodedString;
char* DecodedString;
char  mask;
int  pos=0;
int  dpos=0;
while (EncodedString[pos] != 0)
{
  if (pos%8 == 0) mask=EncodedString[pos];
  else
  {
    if ((mask & (0x1 << (pos%8))) == 0)
      DecodedString[dpos++] = EncodedString[pos] - 1;
    else
      DecodedString[dpos++] = EncodedString[pos];
  }
  pos++;
}[/codes]

编码方式可以变相解释为:
每个字符中的’0’位移至控制字节,然后设为1.
TODO:也许可以通过这点构造更简易的解码算法。.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4.4 [游戏设置]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
首先你要解码游戏设置部分 (见 4.3).
游戏设置 (创建游戏时的扩展选项“高级选项”部分) 由总计13个字节的各种标志(flag)构成.
想了解详细设置的话看这里:
"support/Readme/(PC)UIMainMenus.html"
自己在你的魔兽安装目录下找.
下面列出的是已知的非空标志.
偏移 | 位值 | 描述
-------+-------+---------------------------------------------------------------
0x0000 |  0,1  | 游戏速度: 0 = 慢, 1 = 正常, 2 = 快, 3 = 未使用
-------+-------+---------------------------------------------------------------
0x0001 |  0  |可见度:隐藏地形
              |  1  |可见度: 探索过的地图
              |  2  |可见度: 总是可见(无战争烟雾)
              | 3  |可见度: 默认
              | 4,5 | 观察者  :  0 = 关闭或为裁判 (参见 0x0003 Bit6)
              |      |             1 = 未使用
              |      |             2 = 默认的观察者
              |      |             3 = 打开或为裁判
              |  6  | 共同队伍 (队伍成员的起始点相邻)
-------+-------+---------------------------------------------------------------
0x0002 |  1,2  | 锁定队伍: 0 = 关, 1 = 未使用, 2 = 未使用, 3 = 开
-------+-------+---------------------------------------------------------------
0x0003  |  0  | 完全单位共享
               |  1  | 随机英雄
               |  2  | 随机种族
               |  6  | 观察者为裁判 (另见观察者相关部分 0 or 3)
-------+-------+---------------------------------------------------------------
0x0004 |      | 0
0x0005 |      | 未知 (0 出现在战网ladder对战,自定义游戏中没有)
0x0006 |      | 0
0x0007 |      | 未知 (0 出现在战网ladder对战,自定义游戏中没有)
0x0008 |      | 0
-------+-------+---------------------------------------------------------------
0x0009 | 4Byte | 地图效验  //TODO: 算法呢?
-  0C     |      |
-------+-------+---------------------------------------------------------------

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4.5 [地图或游戏创建名]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
你需要先解码这部分内容 (见 4.3).
先是地图名, 然后是游戏创建者 (ladder对战中是"Battle.Net")再接下来是空值字符串.
编码的字符自此结束,接下来该不会有何未处理的解码字节 (了吧?).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4.6 [玩家数]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4 bytes – 玩家数目或可加入玩家槽数
  战网对战中指玩家确切数目
  自定义游戏中, 是加入游戏屏幕上显示的玩家槽数(最大,和是否关闭无关)
  单人自定义游戏为12

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4.7 [游戏类型]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
偏移 | 大小/类型 | 描述
-------+-----------+-----------------------------------------------------------
0x0000 |  1 byte  | 游戏类型:
              |          | (0x00 = 未知,曾在1、03以前的一些版本里出现过)
              |          |  0x01 =  Ladder对战 -> 1v1或 FFA混战
                              或者是Custom -> Scenario(指有暴雪签名的自定义地图)  (不能完全确定)
              |          |  0x09 = 自定义游戏
              |          |  0x1D = 单人游戏
              |          |  0x20 = Ladder组队作战 (战友组队或随机队伍, 2v2、3v3、4v4等)
0x0001 |  1 byte  | 自定义游戏的私有标志:
              |          |  0x00 - 当为公开的局域网/战网自定义游戏时
              |          |  0x08 - 当为战网自定义游戏设为私人游戏时
0x0002 |  1 word  | 未知 (总为 0x0000 )
TODO:
  1.07后的数值:
    01 00 00 00 : ladder 1v1 / 暴雪签名的自定义地图
    20 00 00 00 : ladder 组队
    09 00 00 00 : 自定义游戏
    09 A8 12 00 : 自定义游戏
    09 A0 12 00 : 自定义游戏
    09 A8 42 00 : 自定义游戏
    09 A8 14 00 : 自定义游戏
    09 A0 14 00 : 自定义游戏
    01 40 13 00 : 自定义游戏
    09 A0 42 00 : 自定义游戏
    09 A8 44 00 : 自定义游戏
(是指后来版本的自定义游戏标志曾多次改变?)


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4.8 [语言id]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4 byte - (独立于地域(指语言区?),地图,游戏类型 !)
也许是别的效验码或经过编码的语言.
手中的一些录像文件中找到的数值:  (ger=通用,eng=英文?)
C4 F0 12 00 - patch 1.10 ger
90 F1 12 00 - patch 1.06 ger
90 F1 12 00 - patch 1.05 ger
A0 F6 6D 00 - patch 1.04 ger
24 F8 12 00 - patch 1.04 eng(?)
A0 F6 6D 00 - patch 1.03 ger
C0 F6 6D 00 - patch 1.02 ger
//TODO: 这部分内容尚且不明确,也许你能找出答案.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4.9 [玩家列表]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
这里的玩家列表是由所有加入游戏玩家的记录数组。
(除去游戏主机和电脑玩家).
这意味着如果只有一个人类玩家(难道不能全电脑么)的话这里啥都没有..
每个加入游戏的玩家以以下结构记录:
偏移  | 大小/类型 | 描述
-------+-----------+-----------------------------------------------------------
0x0000 | 4/11 byte | 玩家记录 (见 4.1)
0x000? |    4 byte | 未知
              |          |  (总为 0x00000000 对于1.07以后说来;
              |          |  若是 0x00000001 是1.06及以前的)
当玩家记录标记为“加入玩家” (第一字节0x16 同见 4.1)时就以这份样式进行记录.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4.10 [游戏起始记录]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
偏移  | 大小/类型 | 描述
-------+-----------+-----------------------------------------------------------
0x0000 |  1 byte  | 记录ID - 总为 0x19
0x0001 |  1 word  | 以下数据的编号
0x0003 |  1 byte  | 录像记录的玩家数目  == 玩家槽数目(创建游戏时所见的)
0x0004 |  n bytes | nr * SlotRecord (see 4.11) (这啥?)
  n+4     |  1 dword | 随机种子 (见 4.12)
  n+8     |  1 byte  | 选择模式
              |          |  0x00 - 队伍和种族可自由选择 (常规的自定义对战)
              |          |  0x01 - 队伍锁定
              |          |          (地图设置: 编辑器中锁定势力选项)
              |          |  0x03 - 队伍和种族不可选
              |          |          (地图设置: 编辑器中固定玩家选项) (都自己找找吧:)
              |          |  0x04 - 固定的随机种族
              |          |          (创建游戏时的高级选项: 随机种族)
              |          |  0xcc - 自动匹配比赛(ladder对战)
  n+9     |  1 byte  |  起始点数 (地图设置的起始点..没啥好说的)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4.11 [玩家槽记录]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
偏移 | 大小/类型 | 描述
-------+-----------+-----------------------------------------------------------
0x0000 |  1 byte  | 玩家 id (电脑玩家是0x00)
0x0001 |  1 byte  | 地图下载类型: 0x64 自定义游戏, 0xff ladder对战
0x0002 |  1 byte  | 玩家槽状态:
              |          |  0x00 空的
              |          |  0x01 关闭
              |          |  0x02 使用
0x0003 |  1 byte  | 电脑玩家标志:
              |          |  0x00 人类的话..
              |          |  0x01 标识电脑
0x0004 |  1 byte  | 队伍号:0 - 11
              |          | (队伍 12 是观察者或裁判)
0x0005 |  1 byte  | 颜色 (0-11):
              |          |  其值+1 为WE里的玩家颜色(和bj一样..):
              |          |  (red, blue, cyan, purple, yellow, orange, green,
              |          |    pink, gray, light blue, dark green, brown,这些就是颜色..)
              |          |  第12号颜色 == 观察者和裁判的(白色对吧?)
0x0006 |  1 byte  | 玩家种族标志 (如你在游戏中所选):
              |          |  0x01=人类
              |          |  0x02=兽人
              |          |  0x04=暗夜精灵
              |          |  0x08=亡灵天灾
              |          |  0x20=随机
              |          |  0x40=种族可选/固定 (见下面的注释)
0x0007 | 1 byte | 电脑ai等级: (1.03以上版本才有)
              |          |  0x00 for 简单级
              |          |  0x01 for 普通级
              |          |  0x02 for 疯狂级
              |          |  对非AI玩家来说这里是 0x01 (意思人类的水平就相当于普通级别的ai..)
0x0008 |  1 byte  |  玩家设置的生命自虐障碍百分比 (如你在游戏中所见)
              |          |  可用数值: 0x32, 0x3C, 0x46, 0x50, 0x5A, 0x64 (50=100)
              |          |  (当然在1.07以上版本才有)
注释:
  o 1.03以前,这部分记录只有7字节.
    最后两项是没有的.(谁还管1.03以前的版本啊,有么..)
  o 1.07版本以前是8字节最后一项没有.(..同上)
  o 是否锁定队伍和颜色部分(指加入游戏后是否可由玩家调整队伍和颜色)未能确定.
  o 1.06以前版本的规则:
    当玩家种族标志第6位为1 (0x40 added) 则认为是地图固定了种族 (参见 4.10).
  o 1.07以后:
    当玩家种族标志第6位为1 (0x40 added) 认为是可选择的(与以上相反)。否则为ladder对战或
    地图固定了种族(同见4.10) (话说我怎么没见到什么..)
   
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
4.12 [随机种子]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
这部分可谓是魔兽3引擎初始化随机种子采取的最佳措施. 录像数据的运转需要这样一个设好的随机种子
(起始点和种族这些数据这时已经设置好).
队自定义游戏来说(无论战网还是局域网) 这个随机种子的双字看起来是游戏主机魔兽程序的运行时间(毫秒计).
ladder对战里要严格些 - 也许通过服务器传来一个“真”的随机种子 (至少不像游戏运行时间这样一下就被猜到)。


===============================================================================
回复

使用道具 举报

 楼主| 发表于 2008-8-1 23:25:52 | 显示全部楼层

关键的第5章

===============================================================================

5.0 [录像数据]
===============================================================================
这章开始讲静态数据(4 节)后跟着的录像数据(貌似终于到重点了?),所描述的是游戏过程
中的信息。录像数据被分成了好几块,大小有的固定有的不固定..而且这些数据块的用途也
不固定,并非所有找到过类型的数据块都要出现在一个录像文件中。(大约就是讲除了静态
数据信息内容,后面的数据是不固定的样子..)
这类数据块以一个标记块id的字节起始,这个id的作用是查找特定的数据块(如根据大小)。
以下所有已知数据块按其id列出,作用描述写在后面就是。中括号里标出的是每个块的大小。
(含第一个id字节)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0x17  - 离开游戏                                                  [ 14 byte ]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  1 dword - 原因
            0x01 - 远程游戏的连接被关闭 (玩家失去链接?)
            0x0C - 本地链接被关闭       (本地主机自己的离开?)
            0x0E - 未知 (少见) (几乎都是情况1)
  1 byte  - 玩家ID
  1 dword - 结果 - 见下表
  1 dword - 未知 (该录像在魔兽中的被保存编号?)

关键字表:
  player = 指向玩家ID
  saver  = 录像保存者 ( = 录像中显示最后离开游戏的玩家)
  INC    = 使最后离开游戏动作增加了1的未知参数
          (和之前的离开动作相比)
  [?]    = 每个均由这个符号标记行是正常录像的常规情况;但我们至少遇到过一例非常格式的录像。
  [O]    = 当录像保存者为观察员时通常结果值为0x01
         
  原因      | 结果   | 描述
===========+========+=======================================================
    0x01    |  0x01  | 玩家离开 (断线或录像保存者是观察者)    [O]
  (远程端)  |  0x07  | 玩家离开
            |  0x08  | 玩家失败 (彻底滴被灭掉)
            |  0x09  | 玩家胜利
            |  0x0A  | 平手 (折磨人的游戏。。)
            |  0x0B  | 玩家离开 (观者者)                        [?]
-----------+--------+-------------------------------------------------------
    0x0E    |  0x01  | 玩家离开                                        [?]
  (远程端)  |  0x07  | 玩家离开                                        [?]
            |  0x0B  | 玩家离开 (观察者)                        [?]
===========+========+=======================================================
    0x0C    |  0x01  | 保存者断线或作为观察者离开                        [O]
(非最后离开)|  0x07  | 保存者败北, 没有进一步的该玩家信息              [?]
            |  0x08  | 保存者败北 (erased,是指建筑全灭的情况输掉?), 没有进一步的该玩家信息
            |  0x09  | 保存者胜利,  没有进一步的该玩家信息
            |  0x0A  | 打平 (吐槽参见上文。。)
            |  0x0B  | 保存者(又)输了 (其实是默认的观察者游戏结果为失败)                  [?]
-----------+--------+-------------------------------------------------------
  last 0x0C |  0x01  | 保存者断线
(rep的保存者|  0x07  | 有  INC字段 => 赢了
最后离开)  |        | 没有  INC   => 输了
            |  0x08  | 保存者输掉 (完全抹杀)
            |  0x09  | 保存者胜利
            |  0x0B  | 有  INC字段 => 大多是胜利的情况,但并非一定是。。  [?]
            |        | 没有  INC   => 保存者离开 (作为观察者)  [?]
个人注释(原文的):
  o 直到现在我们还未能找出一个对玩家是否胜利的有力判断方法
    (100%的) :(
    在检测的6000余份rep中. 普通的ladder对战好办,
    但特别对FFA多人乱战而且保存者为观察者的情况是那么的&?#$.
    所以我们还有事可作...
注释:
  o 别用标记行 ([?],[N]) 来作胜利判断.
    这样的确挺省事,不过错误率也是蛮可观的
    没标记的行被认为安全系数要高些 (至少现在如此).

  o 只要有一个玩家得到打平的结果,整个游戏都是这个结果.

  o 从录像保存者的结果看来 - 可以不止一个因为所有本地离开动作
    (reason=0x0C)都归这类结果 - 这并不矛盾(除非打平)。同时不会出现胜利与
    失败一起的情况(使用非标记行来判断的话)
   
  o 所有在离开游戏动作中的结果值都是针对玩家的结果.
    比方一个玩家在组对战中退出了,被判负 - 就算
    他在的队伍之后赢得胜利也一样.

  o 如果组对战中一个玩家得到胜利的结果那么肯定他所在队伍最后胜利了而别的组被打败了
     
  o 如果小组中每个玩家都是“输”,那么整个队伍的结果只能是败.

  o 就算是魔兽争霸也无法预见未来~ ;). 如果组对战录像保存者是自己先行退出,
    你只能得到“保存者输了”这个结果.
    这就无法检测究竟是谁取得最后胜利.
    很不幸这常发生. 想象一下在2v2的比赛中,一队即将被击败
    然后双方队员互道‘gg’并离开. 如果录像保存者 (输掉的一方)
    比他的队友早一秒退出, 你就无法仅通过录像数据检测究竟是谁获胜了
     
    在此情况下我们采取的策略是假设保存者所属队伍输掉。
    这个判断也许不可能完全正确 (但我们无法得到真正的答案)
     
    一个变通的方法: 判队伍中所剩人数最多者获胜
    这当然也可能是错误的. 比如2v2中一方接近胜利而其中一人断线,但剩下一人继续能打扫
    局面。

    在2v2中两种方案处理的结果一样.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0x1A      - unknown (第一起始数据块)                              [ 5 byte ]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  1 dword - unknown (always 0x01 so far)
Notes:
  o 这似乎总是游戏开始后的第一块数据.
    从不再次出现.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0x1B      - unknown (第二起始数据块)                              [ 5 byte ]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  1 dword - unknown (always 0x01 so far)
Notes:
  o 这似乎总是游戏开始后的第二块数据.
    从不再次出现.(怎么听起来这么耳熟呢)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0x1C      - unknown (第三起始数据块)                              [ 5 byte ]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  1 dword - unknown (always 0x01 so far)
Notes:
  o 这似乎总是游戏开始后的第三块数据.
    从不再次出现。。。
  o 极少的情况:出现一个对话数据块(chat block)(0x20) 或离开游戏的数据块(LeaveGame block) (0x17)
    在二 (0x1B) 与三 (0x1C)之间

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0x1E      - 时隙数据                                      [ n+3 byte ]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
详细见 块 0x1F
注释:
  o 在低于1.02的版本这个代替块 0x1F.
  o 在1.07以后版本很稀奇的出现过,该情况下随机种子
    RandomSeed block (0x22)并不跟在后面了.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0x1F      - 时隙数据                                      [ n+3 byte ]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  1 word  - n = 后面的字节数
  1 word  - 时间增量 (毫秒计)(普遍操作延迟,一些相关内容参详http://www.islga.org/bbs/read.php?tid=7754)
              战网环境大约250 ms
              局域网或单机时大约100 ms
  n-2 byte - 普通数据块(s) (n=2时不存在)
对每个玩家来说在此时隙至少会触发一个动作(比如退出?),因此至少留下一个 '普通数据块'.
普通数据块:
  1 byte  - 玩家ID
  1 word  - 动作块长度
  n byte  - 动作块(s) (详见文档 'w3g_actions.txt' )
Notes:
  o '时间增量' 只对应录像游戏所用fastest这个速度.
  o 通过积累所有'时间增量'来计算当前动作的时间(s).
  o 该块后面紧跟'随机种子' 块 (0x22)
  o 1.02前块ID为 0x1E.在文档  'w3g_actions.txt'中 (啊呀,我已经想丢下这篇去找那篇了 ^ ^)
   

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0x20      - 玩家聊天数据 ( 1.07之后 )          [ n+4 byte ]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  1 byte  - 玩家ID (消息发送人)
  1 word  - n = 以下紧跟的数据字节数
  1 byte  - flags标志
              0x10  延时后显示的消息? (见注释)
              0x20  常规消息
  1 dword  - 聊天模式 (flag = 0x10时不出现):
              0x00  对所有人说
              0x01  对盟友说
              0x02  对观察者和裁判说
              0x03+N 向特定玩家N发送消息(N是玩家序列号)
  n bytes  - 0端收尾格式的文本消息
注释:
  o 这个块随 1.07出现.
  o 只有录像保存者发送和受到的消息会保存在录像中
     
  o 对观察者说的话不会被保存.
  o 玩家序号对应录像中的编号,见 4.11
    0起头 (玩家 0).
  o 得到对话发送的时间, 需要将'时隙' 块中所积累的'时间增量'加起来
     (见前文, 块 0x1E and 0x1F).
关于聊天消息标志的注释 flag = 0x10:
  o 只出现在第二与第三起始块之间0x1B and 0x1C.
  o '聊天模式' 的dword不存在. 消息文本紧接标志之后,长度值也是修正的。
     
  o 用魔兽程序看录像时该消息不出现.
  o 该类消息只在自定义游戏中出现. 也许这些是在等待开始屏幕时打的消息,而因为延时而未
    在游戏开始前未能发送成功

(话说jass中有DisplayTimedTextFromPlayer()一条,一直没弄明白和常用的DisplayTimedTextToPlayer()的区别呢)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0x22      - unknown (效验值或下一帧的随机数/种子)  [ 6 byte ]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  1 byte  - 之后的字节数 (always 0x04 so far)
  1 dword - 未知 (随机性很高)
Notes:
  o 1.02以前这块的 ID为 0x20.
  o 这个信息总能同步于随机种子参与的之前与随后帧各连接之间的各种计算。
    也许是作为游戏全局的效验值.
  o 这块数据总跟在 '时隙' 块之后.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0x23      - unknown                                                [ 11 byte ]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
不太确定的:
  1 dword - unknown
  1 byte  - unknown (always 4?)
  1 dword - unknown (random?)
  1 byte  - unknown (always 0?)
注释:
  o 很少见.
  o 在一个 '离开游戏' 动作之前.
Examples:
  23 4C 0D 00 00 04 0B B0 B1 FC 00  ->  "#L........."    3404 4 4239503371 0
  23 64 07 00 00 04 AC 34 28 7E 00  ->  "#d.....4(~."    1892 4 2116564140 0
  23 FB 0D 00 00 04 DD B8 B1 87 00  ->  "#.........."    3579 4 2276571357 0
  23 D5 15 00 00 04 19 ED 43 72 00  ->  "#.......Cr."    5589 4 1917054233 0
  23 1B 03 00 00 04 D8 2E 81 4F 00  ->  "#........O."    795 4 1333866200 0
  23 F2 04 00 00 04 91 7F C6 01 00  ->  "#........."    1266 4  29786001 0

  all following back-to-back in a single replay:
  23 3A 03 00 00 04 B5 1F DC 80 00  ->  "#:........."    826 4 2161909685 0
  23 3B 03 00 00 04 DE A7 93 77 00  ->  "#;.......w."    827 4 2006165470 0
  23 3C 03 00 00 04 A9 A6 78 3B 00  ->  "#<......x;."    828 4  997762729 0
  23 3D 03 00 00 04 25 87 97 9C 00  ->  "#=....%...."    829 4 2627176229 0
TODO: 需要进一步解构

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
0x2F      - 强制游戏结束的倒计时               [ 9 byte ]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  1 dword - 模式:
            0x00 正在倒计时
            0x01 倒计时over  
  1 dword - 剩余时间 以秒计
Notes:
  o 在 1.07以后出现.
  o 只在战网上的痛苦僵持局中出现过.
  o 一般倒计时以4:58开始数据块每30秒报一次时
    (4:58, 4:28, 3:58, ..., 0:58, 0:28, 0:00, now).
  o 这块内容出现时 "战争迷雾"就被关掉了
    (全部地图对所有玩家可见).
回复

使用道具 举报

 楼主| 发表于 2008-9-8 14:28:55 | 显示全部楼层

最初的与最后的

===============================================================================
6.0 最常见的问题注释
===============================================================================
o 下面的信息是不能从录像中获得的啦:
    + 战网是哪个国度(Asia or North America)
    + 游戏的日期与时刻
    + 天梯ladder对战中玩家的级别、经验、胜负记录那啥
o 你可以在录像文件末尾追加自己的数据- 魔兽程式会忽略它们
  (除了暴雪的官方录像, 见 6.1).
  这条会很有用,比如录像数据分析工具可以在此直接加上(那些没有的)描述游戏的附加信息
   
o 录像文件保存者是“最后离开的人”(至少录像文件这么认为). 关于“离开游戏”动作
   (see 5.0) 也是每个录像的收尾动作.
  如此算来,保存者的id就是解压数据后倒数第9字节(你大可不必从整块动作块来分析保存者
  是谁)。当然这个方法对暴雪官方录像文件无效(对自己加了额外数据的也是--应该吧)
  
o 在用魔兽回放录像时,是以主机玩家为视角.
o 一些游戏类型在录像文件中表现的还不明悉:
  - 对AT 组队(arranged team) 和RT 随机组队(random team)的ladder game 来说rep中找不到差别
     
  - 可以从队伍序号来检查是否组队游戏
  - 可以从多人(>2)时检查各个玩家所属队伍是否迥异来确定FFA大乱战
     
o 可以在启动魔兽程式时使用参数'-loadfile' 来立即放录像:
  War3.exe -loadfile "replayfilename"
  在1.14前有个副作用: 单人游戏下的玩家帐号自行更便为'WorldEdit'.

o 关于1.07, 1.08 和 1.09  对原始版本(ROC)来说是不存在的。补丁从1.06直接跳到
  1.10 。这要归咎于TFT发布后一时间造成的混乱

o 寒冰王座 1.07起,然后直接patch到1.10,同样没1.08或1.09的补丁.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
6.1 有关暴雪官方录像的注释
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
这些指的是高级别的ladder对战和锦标赛决战,在被战网自动收集然后出现在Battle.net
的网页上供下载,这些录像文件有些不同于用户自保存的

差别在于:
o 版本号 (see 2.2) 总为0.
o 文件实际大小较之文件头的标识大出132字节(见以下).
o 地图设置记录 (see 4.4) 总为 '01 01  01 F9 01 01  FF FF FF FF'.
o 这里玩家列表中那个未知项(4字节的那个) (see 4.9) 等于语言id (see 4.8).

o 玩家数目记录 (Byte 0x0003 of [GameStartRecord] in section 4.10)
  总为0 - 目前为止无玩家槽记录(see 4.11).
o 起始点数 (see [GameStartRecord] in section 4.10) 总为 0xCC.
o 录像末尾有加个签名块:
    1 dword  : 4E 47 49 53 = 'NGIS' <=> 'SIGN'
    128 Byte : 128字节的签名
Notes:
o 由于缺少了所有有关玩家槽的记录, 构建数据只能这样推敲:
  遍历玩家记录中所有槽序号的记录 (see 4.1)
    玩家 id    = 槽序号
    玩家状态   = 0x02                  (used)
    所控者标志 = 0x00                  (human player)
    队伍序号  = (槽序号 -1) mod 2  (team membership alternates in
                                                            PlayerRecord)
    颜色        = 未知                (玩家得到随机的颜色)
    种族        = 在玩家记录中
    AI等级      = 0x01                  (没有ai)
    生命百分比  = 0x64                  (100%)
o 锦标赛录像名字是“暗金”的:(其实是指遵从格式而已)
    'YYYYMMDDhhmmxxxxx-TAG-TYPEp.w3g'
  那些:
    YYYY  - 游戏开始年代 (格林威治时间)
    MM    - 月 ...
    DD    - 日 ...
    hh    - 时 ...
    mm    - 分 ...
    xxxxx - 序号 ID
    TAG   - 标志 'W3XP'  冰封王座, 'WAR3' for Classic 混沌之世
    TYPE  - 常规或是 所限种族/地图,...
              无限制的 (在一个星期中的日期):
                FRI - 星期五
                SAT - 星期六
                SUN - 星期天
              限种族的锦标赛:
                HUM - 人族
                ORC - 兽人
                NLF - 暗夜精灵
                UND - 亡灵
                RND - 随机
              限地图的锦标赛:
                CLD - 冰冷之心
                FLD - 沼泽之原
                GNW - 豺狼人树林
                LST - 失落神庙
                RCK - 海龟岛
                WET - 湿漉大地
    p    - 每组的人数
  文件名举例:
    20030816204000041-W3XP-SAT1.w3g
                        寒冰王座1v1 锦标赛 于 8月 16日 星期六打响
                        (round started at 20:40 GMT)
    20030817222400050-W3XP-SUN2.w3g
                        寒冰王座的2v2 锦标赛 于8月17日星期天
    20030820205400081-W3XP-LST1.w3g
                        寒冰王座1v1 "Lost Temple"锦标赛  8月20号

o 在不改变录像文件名的基础上,我们可以得到一个供签名的效验值
   (或者就包含在数据中).
o 这项功能在暴雪发布1.12补丁后不久才正式被宣布,但之前也一直有在用

TODO: - 给我看签名方法。。

===============================================================================
7.0 鸣谢帮助
===============================================================================
让我们在此对帮助解码w3g 格式的人们致谢
(字母表顺序):
o BlackDick for
  - 提供头文件效验算法的信息
  - 提供1.10补丁变化信息
  - TFT的beta录像的版本、程序信息
  - 许多提示与细节更新
o DooMeer for
  - 关于'-loadfile' 的参数
o Ens for
  - 提供聊天模式的信息 (观察者,特殊玩家)
o Mark Pflug for
  - 找到动作块 0x1E and 0x23
o Kliegs for
  - 基于他的注释文本做出的本文档
  - hosting a CVS for replay format related documents
o ShadowFlare for
  - WinMPQ
  - developer forum论坛主持者
o Soar
  - 一些TFT的信息
o Ziutek for
  - Total Commander MPQ plugin (插件)

===============================================================================
8.0 版本更新历史 (请看原文。。)
===============================================================================
o general notes
+ information added
- information changed
version 1.15 - 2005-04-30
-------------------------
2005-04-30: - fixed build number for patch 1.15 (final)
2005-04-29: - some minor addition on GameSettings
2005-04-26: + added build number for patch 1.18
2005-04-26: + added section 2.4.2 on beta patches
2005-04-26: - corrected contact information in file header
2005-04-26: - translated german note on encoding scheme in section 4.3

version 1.14 - 2004-10-02 (internal)
-------------------------
2004-10-02: + added build numbers for patches 1.15, 1.16 and 1.17
2004-10-02: - some minor cleanups

version 1.13 - 2004-08-?? (internal)
-------------------------
2004-08-06: - restructured sections 4.3, 4.4 and 4.5
              (the encoded string starts earlier)
2004-04-19: + added build numbers for patches 1.15(beta)
2004-02-15: - fixed build numbers for patches 1.14 and 1.14b

version 1.12 - 2004-01-18
-------------------------
2004-01-17: + added build numbers for patches 1.14 and 1.14b

version 1.11 - 2004-01-02
-------------------------
2003-12-20: + added build numbers for patches 1.13 and 1.13b
2003-12-15: - fixed developer forum URL in header

version 1.10 - 2003-12-14
-------------------------
2003-12-14: - fixed even more grammar/spelling mistakes
2003-12-05: - fixed various grammar/spelling mistakes

version 1.09 - 2003-12-02
-------------------------
2003-12-02: o killed a lot of trailing spaces
2003-12-02: + added BETA patch release dates (section 2.4)
2003-11-25: + added patch release dates (section 2.3)
2003-11-23: - updated notes on version determination
2003-11-11: - fixed some typos/grammar mistakes
2003-11-11: - extended description of general block structure
2003-11-06: + added many notes on winner detection (LeaveGame section)
2003-11-03: + added version section (section 2.3)
2003-10-11: - renamed "game creator" to "game host" in some places
2003-10-11: - various minor layout improvements
2003-10-05: + added note and examples on block 0x23
2003-09-25: - changed one LeaveGame result
2003-09-24: + added flag 0x10 description of chat blocks
2003-09-24: + added note on third startblock

version 1.08 - 2003-09-20
-------------------------
+ added info on official Blizzard replays
+ added action blocks 0x1E and 0x23
+ added patch 1.12 build number
+ added note on loadfile-parameter
+ vastly improved leave game command (0x17) description
- fixed error in header ID string
- changed description of version number fields for subheaders version 0
- renamed action block 0x1F to 'TimeSlot' and improved description
- many minor updates and fixes

version 1.07 - 2003-07-31
-------------------------
+ added missing chat modes (thx Ens)
+ added size information to all blocks in section 5
+ improved introduction part of sections 4 and 5
- fixed 'referee' bug in map settings section
o various layout improvements

version 1.06 - 2003-07-22
-------------------------
+ added replay data block 0x2F
+ added some additional notes to disclaimer
+ added some more build numbers (thanks to blackdick)
+ added version/build information on TFT beta replays (thx BlackDick)
- renamed mostly all 'patch 1.10' to 'patch 1.07',
  because first TFT release was 1.07 and the replays had the same structure
  as in 1.10

version 1.05 - 2003-07-01
-------------------------
- fixed error in description of new chat message block (0x20)
+ added information on fixed races in patch 1.10
+ added some minor notes related to patch 1.10

version 1.04 - 2003-06-30
-------------------------
+ added note on game type in section 6.
+ added some minor notes
+ added patch 1.10 format changes:
    o new header (section 2)
    o handicap field (section 4.11)
    o referee type observers (sections 4.3 and 4.11)
    o chat message block (section 5)
+ added some patch 1.10 example records

version 1.03 - 2003-06-16
-------------------------
+ added build numbers for all released patches
+ added some minor notes in various sections
+ added some patch 1.06 example records
- fixed missing dword (section [LeaveGame])
+ added some language strings (section [GameName])
+ added notes about replay saver

version 1.02 - 2003-06-14
-------------------------
o removed all "//*" marks for better readability
- fixed some typos
- fixed patch version for blocks 0x1E and 0x20 in section 5
  (patch <= 1.02 instead of <1.05)
- minor cleanups of various sections

version 1.01 - 2003-06-12
-------------------------
o differences and additions to kliegs notes.txt are marked with //*
o minor layout improvements in section 5
- renamed 'Player Actions block' to 'Player commands block'
  and updated whole paragraph

version 1.00 - 2003-06-06
-------------------------
o first public release
o differences and additions to kliegs notes.txt are marked with //*
+ added info on header checksum calculation (thx BlackDick)
+ added info on first unknown field in header (thx BlackDick)

version 0.90 - 2003-06-04
-------------------------
o beta release
o differences and additions to kliegs notes.txt are marked with //*
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 点一下

本版积分规则

Archiver|移动端|小黑屋|地精研究院

GMT+8, 2024-11-21 21:47 , Processed in 0.060420 second(s), 18 queries .

Powered by Discuz! X3.5

© 2001-2023 Discuz! Team.

快速回复 返回顶部 返回列表