|
|
在传奇Data目录下,Hum.wix、Hum.wil 是两个很重要的文件,它里面是游戏中人物一切动作的模型.包括静止、走、跑、攻击、挖肉、死亡等动作.下面我把自己在研究过程中所积累的一些发现写出来,供大家参考一下.如果有不对或欠妥当的地方,也请你给予指正： 内容来自dedecms Hum.wix是wil的一个索引文件,我们暂不考虑它.在Hum.wil文件中共有图片7203个.按衣着依照图片顺序依次是裸身男(0-599)、裸身女(600~1199)、布衣男(1200~1799)、布衣女(1800~2399)、轻(中)盔男(2400~2999)、轻(中)盔女(3000~3599)、重盔(战神盔甲)男(3600~4199)、重盔(战神盔甲)女(4200~4799)、魔法长袍(恶魔长袍)男(4800~5399)、魔法长袍(恶魔长袍)女(5400~5999)、灵魂战衣(幽灵战衣)男(6000~6599)、灵魂战衣(幽灵战衣)女(6600~7199|7203).共包括静止、走、跑、一般攻击、双手攻击、强行攻击、施展魔法、挖肉、被攻击、死亡共9个动作.人物动作分8个方向,分别是上、右上、右、右下、下、左下、左、左上. copyright dedecms dedecms.com
在这些动作中,每个模型所占图片数是600个.各动作与占图片数及它在文件中数序位置是按照一定规律来的.我们就以裸身男(0-599)为例来看看它有什么规律： 织梦内容管理系统
人物静止动作从0开始,代码段是0~63.每个方向的动作是4[8]张图片.
人物的走动作从第64开始,代码段是64 ~127.每个方向的动作是6[8]张图片.
人物的跑动作图片从128开始,代码段是128~191.每个方向的动作是6[8]张图片.
人物的攻击动作从192开始,代码段是192~263.每个方向的动作是1[0]张图片.
人物的双手攻击动作是从264开始,代码段是264~327.每个方向的动作是6[8]张图片.
人物的强行攻击动作是从328开始,代码段是328~391.每个方向的动作是8[8]张图片.
人物的施展魔法动作是从392开始,代码段是392~455.每个方向的动作是6[8]张图片.
人物的挖肉动作是从456开始,代码段是456~471.每个方向的动作是2[2]张图片.
人物的受攻击动作是从472开始,代码段是472~535.每个方向的动作是3[8]张图片.
人物的死亡动作是从536开始,代码段是536~595.每个方向的动作是4[8]张图片. 织梦内容管理系统
织梦内容管理系统
从上面这几行文字中的数据我们可以看出来,每一个动作都是由几张图片组成的,邻居的两张图片在动作上按人物运动的规律绘制原始图像,当然这是美工的工作了~不同的动作图片数不同,但在这里有一个问题,大家注意到上面几句话中"每个方向的动作是6[8]张图片"这句话中的数字了吧~ 其中6是我们可以看到的图片数,而中括号中的8是这个动作在这个方向上所有的图片数,也就是说在这个动作上,传奇的韩国美工只绘制了6张图像,还留有2张空图片的位置(是懒工呢还是有别的用途),不知我这样理解正确不正确~ 对动画略微了解点的朋友肯定都明白,同一段动画,30帧肯定要比10帧的动作柔和、协调一些. dedecms.com
dedecms.com
本来传奇的游戏引擎是90度的,其45度的效果完全是用图片做出来的.至此,通过上面这些数据,我们对传奇人物的动作已经大体了解了.因此大家如果想要自己添加衣服,除非你的原始图片数符合上面的数据或者你自己亲自操笔美工,如果不符,我建议你不要搞.我想你恐怕不愿看到人物在站立不立的时候,竟然能够自己自动"换"衣服吧 ^_^ 织梦内容管理系统 内容来自dedecms
还有一个问题,关于衣服在StdItem.DB中的Shape值.抛开这个问题,我们先研究一下Hum文件中的数据.它共有7203张图片,而且每一性别人物模型所占的图片数是600.即600是一个基数.但在程序中,它是这么处理的,它把男女做成一个块儿处理.即男女裸身、男女着衣,如果按这样的话,基数应该是1200.用"/"命令,所得的数值是0、1、2、3、4、5,正好对应裸身-0、布衣-1、轻(中盔)-2、重(战)盔-3、魔(恶)-4、灵(幽)-5.OK,StdItem.DB中衣服的Shape值出来了.也可能我这样说不太清楚,不过如果还不明白的朋友你可以看一下上面那些文字和数据,再对照一些图片,我想应该很明白了. copyright dedecms
内容来自dedecms
还有我在这儿也简单说一下3.0中的Hum文件.在3.0中,游戏把男性和女性的模型已经分开了,即M-Hum.wix、M-Hum.wil和WM-Hum.wix、WM-Hum.wil文件.其中有一些动作的图片数已经比1.5增加了,例如人死亡的时候图片数达到10个,我想不会有人愿意欣赏自己死时的样子吧!呵呵~ 图片数的增加,相应地游戏中人物的动作也更加协调更加柔和了.另外,由于2.0中增加了一些法术,因此,多了很多的动作,比如战士的倾天剑法、岁月长刃、一种旋空踢腿的动作(漂亮极了),还有钓鱼、骑马等.对3.0的研究还在进行中. 内容来自dedecms 织梦内容管理系统
推荐一些工具：
1---十六进制编辑器 这个可是破解的主要工具啊。推荐使用HEDIT，华军主页上有。
2---图象处理程序 这个是用来处理图片的。主要是生成我们要的图片框架。这个，用WINDOWS自带的画笔就成。
3---计算器 这个是用来转换16进制和10进制的，这个在很多时候都用的到的。WINDOWS自带的就行了。
4---记事本 用来记录破解过程的重要数据。
5---一种可以处理二进制文件的编程工具 这个是用来写破解程序的。因为手工从文件拷贝图象文件实在是太累了。特别是数据比较大的时候。
6---然后呢，一点预备知识在PC里面存储的数据是高位在前低位在后。也就是说 十六进制 0xf8890 在十六进制编辑器中是这样的： 90 88 0f 00。这个相当重要啊。 织梦内容管理系统
织梦好，好织梦
好了，下面我们开始了。 copyright dedecms
首先呢，打开了一个WIL文件看一下，没有头绪。然后打开了一个WIX文件，在两个文件文件头，发现了这样的文字。
#ILIB v1.0-WEMADE Entertainment inc（这个是WIL文件头）
#INDX v1.0-WEMADE Entertainment inc（这个是WIX文件头）
从这个上面我们可以看出，WIL就是LIB的意思，也就是库的意思。
WIX就是INDEX的文件，也就是索引的意思。
这样，初步知道数据是存放在WIL中的，数据索引是存放在WIX中的。 本文来自织梦 copyright dedecms
索引就是类似地址簿的东西，你从索引中查找数据所在的地址（这个地址不是内存地址，而是文件里面的地址）。那么通过这个地址，你就可以在库中找到数据了。好了，现在知道了数据索引存放的地方，那么，就开始找到这些索引吧。 织梦好，好织梦 织梦内容管理系统
用HEDIT打开两个WIX文件进行比较，发现在OFS=36之前的数据都是固定的，那么，看后面的数据。找了一个比较小的WIX文件。然后从OFS=36的地方选择。这里用的是DNITEMS的WIX。 copyright dedecms dedecms.com
发现，选择的字节数是1656，而我们清楚，一个文件位置一般是用4个字节存放，也就是说，这里总共可能有的图象数是1656/4 = 414个，用计算器算出16进制是0x19E，这时，在开头找16进制的 9E 01，发现，在OFS= 44 的地方有一个 9B 01 的很接近 9E 01 那么，后面的信息不都是文件地址。因为还要记录图象的个数啊。所以从数据的尾部开始选择，看着右下角的数字到了0x19b时，停下，发现正好停在 0X44前面。这些数据都是文件位置，这个9B 01就是图象个数。 dedecms.com
本文来自织梦
第一个文件位置的通途分析，我打开了两个WIX文件，发现在相同的位置，就是OFS = 44后面的文件位置信息开始的地方，数据总是38 04 00 00，哦，明白了，这个就是图象数据的开始位置。也就是第一副图象的开始位置。 内容来自dedecms 内容来自dedecms
那么把这个开始位置转换一下，0X438 = 1080，也就是说，在WIL中的前面1080字节不是图象数据。根据经验，我们知道，BMP文件里面的调色板一个就是一个4字节的DWORD值，那么256个位置就是1024字节，哈，很接近了啊。然后我比较了两个WIL文件，发现，前44字节是很相似的。所以我们减去44字节就是1036字节。那么剩下的12字节是什么呢？呵呵，我也不清楚，不用管他了。我们只要图象。 本文来自织梦
copyright dedecms
在WIL的0X438的位置上，发现了14 00 0D 00的数字。图象猜测超不过65535大小的，所以猜想这是两个USHORT的图象大小的数据。把他们相乘，然后我又找了0X438后面的一个文件位置，然后相减，得到了数据的长度。减去图象大小的数据，多出来4个字节。用途未知。 织梦内容管理系统 织梦内容管理系统
然后把图象数据复制，打开了画笔，把图象属性设定成0X14*0X0D，然后存成256色的位图。接着用HEDIT打开位图，在0X1078的位置把数据粘贴到这个位置。然后存盘，退出。然后用画笔打开这个图象文件。看到图象了。看样子象一个符。不过颜色不对。恩，进入了传奇。用PAUSE截了一张图，然后用HEDIT打开，在54的位置选择了1024字节的东西。然后复制，再打开那个图象文件，在54的地方粘贴，然后存盘，退出，用画笔打开。是一本书。 本文来自织梦
从上面的动作中得到了下面的结论。
1 图象位置索引在*.wix中
2 图象信息在*.wil中。
3 图象索引从OFFSET 0X2C开始，有一个DWORD的图象总数
4 然后是DWORD的OFFSET值，第一副图象的OFFSET值固定为0X438，= （1080）10
5 那么，就是说在WIL中，开头有1080 字节的空余。
6 在WIL中，文件开头的44字节都是相同的。所以，就是说有另外的1036字节是另有用途。
7（这个没有解决）1036中有1024是一个256色的调色板，那么，剩下的12字节是干什么用的呢？
8 在传奇下，有一个截图功能保存的图象里面的调色板就是是游戏图象数据的调色板。 织梦好，好织梦 dedecms.com
那么，剩下的工作就是写代码来抠图象了。
这方面的问题我就不再阐述了，因为知道了图象存储的数据格式，程序就很好写了。 织梦好，好织梦
还有一点补充：我没有说清楚，这些图象是完全用8BIT位图方式存放在文件里面的。没有经过任何压缩或者是编码 内容来自dedecms |
上一篇：脚本常用模块标准格式下一篇：转换引擎替换命令之hero与leg
|
发表于 2021-11-24 03:00:42
变色卡
发表于 2021-11-24 06:00:39
