使用方法: 

1。用WIL工具打开你找到的含有新怪物的Mon**.wil文件,然后找到这个怪物所在的第一个位置和最后一个位置,即这个怪物的图片号是第几个。比如:现在我们找到的新蚂蚁中的蚁后的图片是在1000—1500 

2。选“菜单”—->“连续输出图片…..” 

—->输入你要输出的图片的第一个图片号(这里我们输入1000) 

—->输入你要输出的图片的最后一个图片号(这里我们输入1500) 

—->最后要输入的是生成的图片号的偏移数字(注意:如果你要把现在输出的新怪加到别的*.wil文件里面,你就在要这里输入偏移数字{偏移数字可以是正负数,如果是0生成的图片就是从1000.bmp—-1500.bmp命名,如果输入-1000生成的图片就是从0.bmp—-500.bmp命名},这里我们输入0) 

—->生成图片后,选“菜单”—->“生成一个新物品库….” 

—->在Image Folder中输入刚才我们输出图片所在的位置 

—->在Labrary (.wil)中输入你要生成的wil文件名 

—->在Index (.wix)中输入你要生成的wix文件名—->在Start Image中输入刚才生成的*.bmp图片的开始号(默认是0) 

—->在End Image中输入刚才生成的*.bmp图片的结束号(这里输入500) 

—->Fast HDD IO Mode如果你的硬盘快的话就勾上吧—->点Build就生成了我们新制作出的蚁后单独的怪物DATA文件了 

—->我们命名为Mon10.wil和Mon10.wix 

3。最后在数据库Monge.db蚁后的APPR就是90 

4。关于APPR和DATA文件对应的关系,首先打个比方,鹿在Mon17.wil中的怪物排位是第2个,那么他的APPR就是161 

发现规律了吗?其实就是,Mon**的数字-1乘以10=APPR 

5。只要Mon**.wil里面的怪不满10个就可以加~~~~!!!!!!!!!!! 

6。补充: 

(以下载的40个新怪物的WIL为例) 

大多数情况下,在WIL里每个APPR对应的图片范围 

第一个APPR 0–>339 

第二个APPR 360–>699 

第三个APPR 720–>1059 

第四个APPR 1080–>1419 

第五个APPR 1440–>1779 

第六个APPR 1800–>2139 

第七个APPR 2160–>2499 

第八个APPR 2520–>2859 

第九个APPR 2880–>3219 

第十个APPR 3240–>3579 

这是结构比较标准的,如Mon13.wil 

又如Mon2.wil,它的APPR是间隔出现的,具体结构如下: 

图片范围 APPR 

第一个0–>209 11 

第二个230–>649 13 

第三个690–>1109 15 

第四个1150–>1489 17 

我按照这个规律在1610–>2225位置按顺序添加了以前”血魔兽”的所有图片(就是长牛角,吐舌头那个),APPR为19.进传奇后可以正常显示,就是打SI了的显示不正确(SI亡动作结束后又重新站起). 

所以产生疑问,每个APPR的确切图片范围究竟是多少?或者说APPR在WIL里是怎样定位的? 

那些不是标准”站走攻伤SI”8方向图片(共256张,加上空白图片间隔共340张)结构的WIL中APPR又是如何定位的呢?(如”妖之树”,Mon1.wil中的绝大多数) 

7。对应5种姿态为: 

站–每方向4张图片,一共32张 

走–每方向6张图片,一共48张 

攻–每方向10张图片,一共80张 

伤–每方向2张图片,一共16张 

SI–每方向10张图片,一共80张 

下面是hulake000发表的在WIL中添加图片也就是重建WIL文件的方法: 

先把你自己现在用的StateItem.wil里的图片2.0编辑器全部导出来,再把你编辑好的图片和图片坐标文件放到一起,生成一个新的StateItem.wil就好了。 

具体操作如下:我本沉默的StateItem.wil(。。。这个比较通用) 

一:打开StateItem.wil后选择批量导出图片,软件会提示里输入第一张的编号这里输入0,接着再输入最后一长图片的编号547,再下一个偏移量输入0后。编辑器会提示你输出的图片放到哪个目录下。(自己看着办,JAV、KAV、CAV目录下都可以,只要自己能找到) 

二:输出后会产生0、1、2三个文件夹。把自己编辑好的图片改成000548.bmp,坐标文件也改成000548.txt,分别放到2文件夹里。注意假如你StateItem.wil里图片多的话就看你最后一张编号是多少。如00550.bmp那么你的bmp就相应改为000551.bmp以此类推,Placements里的坐标文件也是一样。 

三:编辑好的后在2.0编辑器里选生成新的数据库文件,指定好你存放图片的目录(KAV、JAV、CAV什么的)数据文件和编码文件的名字可以不改,输入图片结束编号550(如果只加了3张进来),最后点创建,你的StateItem.wil就生成了

1.5传奇Hum文件(人物动作模型)解析 

在传奇Data目录下,Hum.wix、Hum.wil 是两个很重要的文件,它里面是游戏中人物一切动作的模型.包括静止、走、跑、攻击、挖肉、死亡等动作.下面我把自己在研究过程中所积累的一些发现写出来,供大家参考一下.如果有不对或欠妥当的地方,也请你给予指正: 

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个方向,分别是上、右上、右、右下、下、左下、左、左上. 

在这些动作中,每个模型所占图片数是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帧的动作柔和、协调一些. 

本来传奇的游戏引擎是90度的,其45度的效果完全是用图片做出来的.至此,通过上面这些数据,我们对传奇人物的动作已经大体了解了.因此大家如果想要自己添加衣服,除非你的原始图片数符合上面的数据或者你自己亲自操笔美工,如果不符,我建议你不要搞.我想你恐怕不愿看到人物在站立不立的时候,竟然能够自己自动”换”衣服吧 ^_^ 

还有一个问题,关于衣服在StdItem.DB中的Shape值.抛开这个问题,我们先研究一下Hum文件中的数据.它共有7203张图片,而且每一性别人物模型所占的图片数是600.即600是一个基数.但在程序中,它是这么处理的,它把男女做成一个块儿处理.即男女裸身、男女着衣,如果按这样的话,基数应该是1200.用”/”命令,所得的数值是0、1、2、3、4、5,正好对应裸身-0、布衣-1、轻(中盔)-2、重(战)盔-3、魔(恶)-4、灵(幽)-5.OK,StdItem.DB中衣服的Shape值出来了.也可能我这样说不太清楚,不过如果还不明白的朋友你可以看一下上面那些文字和数据,再对照一些图片,我想应该很明白了. 

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。