汉化GMSV第四篇(关于家族修复)



  • 这一篇教程给大家主要介绍gmsv与数据库的关系问题,对于gmsv修好的基础知识以及mysql的基础知识在前三篇教程中已经大体上介绍过,这里凡涉及到以上内容的尽量简洁,读者莫怪。
    在gmsv与数据库修复过程中最耀眼的就是家族和名片系统了,由于名片系统以及排名等涉及到mlsv,本篇就以单数据库为依托的家族系统为例,来小议下gmsv是如何与数据库通信的问题。查看游戏数据库的表格,我们可以获得如下的list:
    tbl_addressbook
    tbl_addressbook_bak
    tbl_character
    tbl_character_bak
    tbl_duelranking
    tbl_guild
    tbl_guild_bak
    tbl_guildItemBox
    tbl_guildItemBox_bak
    tbl_guildItemBoxPet
    tbl_guildItemBoxPet_bak
    tbl_guildMonster
    tbl_guildMonster_bak
    tbl_item
    tbl_item_bak
    ............
    tbl_pet
    tbl_pet_bak
    tbl_playernum
    tbl_product
    tbl_user
    tbl_user_bak
    从字面上理解其中有那么几个表和家族有直接关系的如tbl_guild,tbl_guildItemBox,tbl_guildItemBox,tbl_guildMonster这四个表。利用第三篇结尾的方法,我们可以知道是由于breedingRoomQueryError的问题,这是数据库问题还是程序问题?如果说数据库问题,感觉无从下手,于是我就改了个方向,更换gmsv程序。机子上积累了很多的gmsv,挨个试验了下,可以说都很有特色,有的甚至连人物都不能登入,估计是要配套的cg吧,最后敲定使用名网的的那个端,上面的修改日期是2005年7月6日,够原始的了。。。。
    gmsv更换之后,家族算是创建起来了,当然是没有tbl_guildMonster记录啦,有的话就报breedingRoomQueryError错误。重启服务器,登入查看,刚才创建家族没了---真是祸不单行啊。再次翻看数据表格,发现tbl_character的guildId列没有填充完整,只有两个成员登陆了,怪不得家族在重启之后就没了,难道是使成员不足五个的原因?找到createGuildSuccess我们发现了下面一个做标记的好地方,程序如图所示:


    这段代码call了四个函数CHAR_getPartyArray[猜测是队伍信息]、GUILD_createGuildRoom[家族房间的创建]、_snprintf---LogGuild[猜测是输出到guild.log]、addGuildInitialMember[这个就是原始的家族人物添加]。作为束手无策的我第一时间就是看看log是不是执行过了,查看记录看到:
    GUILD: guildID=30001 CdKey=sanat registnumber=4 name=完美汉化 action=createGuild (guildName=完美家族 roomName=完美空间) (8/6/17 19:32:48)
    看来是在执行addGuildInitialMember函数期间出现了错误,才导致tbl_character的guildId列没有填充完整,不管重启gmsv家族失踪是何原因,这是我们一个着手点。重新创建家族,在服务器重启之前修改tbl_character的guildId列以及相关列,错误依旧存在,家族还是失踪了。。。。。(我都想报警了我)。。。。
    难道我走错了方向,还是家族相关的字段有很多?再次翻了遍数据库,没有增减过什么记录,还原数据库,开始无聊闲逛,并且异想天开的想,难道是五个游民申请受到了歧视?这是什么游戏啊。每个人人物都给了个职业背着"圣洁的灵魂"的称号再去申请,这次身份不一样了,不知道开家族的那个NPC是不是势利眼。小心的申请后,数据还是原来的那些数据,服务器重启之前修改了tbl_character的guildId列以及相关列,抱着侥幸的心,重启了服务器。。。。真是势利眼,居然进去了,而且家族还在,这个高兴啊。。。登出游戏翻看数据库,发现表tbl_character族长这一行出现了些变化,与其他四个人数据明显不一样,难道这就是族长的待遇?刚才光顾者高兴没有来得及看有什么变化来着了,再次登入,这次发现问题了:族长的称号变成了待定义17,而且那些权限都没有了。。好不容易建成了,还被人控股了不成?找到tbl_character表title列,这列貌似就是家族称号id?改为0,这才是老大的称号啊,重新进入服务器。。。。错误依旧,究竟是谁动了我的家族,这是个问题。
    向来是福无双至,祸不单行,这次也不例外。仔细琢磨了下,发现问题不只如此,家族称号这次还变成17了,看来刚才给我显示几个汉字还算是仁慈了。接连两个错误已经把我弄得头晕脑涨了,忽然突发奇想,会不会使它们也和物品显示一样有一个表格控制呢,如果是表格通过堆栈的位移来引用更改相应的字段,那么前面两个问题就迎刃而解了,是字段或者字段位置错误,也就是说,gmsv没有错。搜索关于tbl_guild表格的sql语句,发现我们可以做一些小的调整如下:
    CdKey CdKey
    RegistNumber RegistNumber
    serverNumber serverNumber
    roomType roomType
    guildName guildName
    roomName roomName
    createTime brief
    lastAccess createTime
    titleName0 lastAccess
    commition0 guildMark
    floorID titleName0
    titleName1 commition0
    commition1 ..................
    .................. ..................
    titleName31 ..................
    commition31 titleName31
    brief commition31
    guildMark floorID
    调整后清空store文件夹,运行服务端,登入正常,"待定义17"又出现了,虽然不是很理想,但是我们的猜测对了,这就意味着我们的冤路走得很长,但是至少我们还在前进,这就是好的征兆。
    调整了tbl_guild表格之后,我们开始研究谁动了我的家族这个问题,根据前面的经验,我们有理由怀疑,把tbl_character的某一列或两列做些调整就能达到我们的目的了,看着这个327个字段的表格,一脸的模糊。。。族长被篡权了,看看其他的几个吧。测试第三个帐号的时候,也就是手动修改的那个,再次惊爆出了个"待定义17",看来不止是族长罢工了。这次情况比较好的是在运行记录上出现了一小行黑色的错误。。。。titleid=164,titleid=164是什么?职业的称号哦,那个貌似家族的称号的字段title不可靠!还原表格到早一些时候,源字段titleId=164!问题貌似找到了,对换title和titleID字段位置,重新建立家族,获得错误"killitem+乱码"。登出,翻看数据库,发现tbl_character的guildId列填充完整,重启服务器,家族存在,称号好依然存在,再也没有篡权的悬念了。至此,家族部分修复基本完成,下面是家族宠物的修复。
    注:关于"killitem+乱码"的问题,感谢小男生提供帮助。知道是怎么回事了
    有了家族的支持(虽然在创建的时候屏蔽了GuildMonster的创建),进行下一步家族宠物的修复就方便多了。用gm代码生成点那个换领养证的什么石来着(瞧这记性。。。),换来证书先领养一个,整个过程没有反应,数据库也没有任何记录添加,难道就这么算了?可是家族宠物房间明明存在的,而且还可以进入呢。重启服务器,看看家族宠物会不会玩消失,结果证明他还在,翻遍数据库,没有!这个就奇怪了,难道通过虫洞走向外太空了。。。。偶然在翻store文件夹时,发现了这个文件:breedingRoom.txt,这个不奇怪,但是里面的代码让我大吃一惊:
    30001,0,sanat,4,1214273832,1,1,蛋 ,0,0,14900,1,0,0,80784,100,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,-1,-1,-1,-1,-1,1,67,60,24,9,95,0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
    30001,1,sanat,4,1214273832,2,1,蛋 ,0,0,14902,16,0,0,82944,100,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,-1,-1,-1,-1,-1,1,17,82,59,63,47,0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
    30001,2,sanat,4,1214273832,3,1,蛋 ,0,0,14903,5,0,0,82656,100,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,-1,-1,-1,-1,-1,1,100,93,22,119,77,0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
    这个难道就是我看到的那个记录?众里寻他千百度,那人却在灯火阑珊处!删除之,重启服务器,果然家族宠物又不存在了。通关前面这一步,我们们得到了最宝贵的资料,家族宠物数据资料!想想tbl_guildMonster的格式应该与之相符吧,为tbl_guildMonster表格补齐列,清空store文件夹,重新启动服务器,领养宠物,这次tbl_guildMonster数据记录基本正常,只是个别字段的对应上和前面的家族存在同样问题,修改之。至此,家族宠物领养部分修改基本完成,下面介绍家族物品箱的修复过程。
    修复这里,似乎一切都很顺利,我最高兴的是多了三个公用物品箱,那个是15个宠物格哦,开始把一个物品扔进家族物品箱,登出。。。重启服务端。。没有发现什么问题。这次次扔入两个物品,点击确定的时候出现了如下图的错误:


    修改的时候少了个逗号就变成上面的图。。。
    从图中错误中我们读到了两个信息:
    第一:数据表tbl_guildItemBox需要添加很多列
    第二:好像insert into table values (val1,val2...),(val1,val2...),...这个是标准的语法,而图片中得明显是在两条记录中间缺少了个逗号。
    第一个问题很好解决,增加列就可以了。主要是第二个问题,我们还得从GMSV当中来寻找答案。打开IDA导入GMSV,找到make_guildItemBoxSql函数,看着结构很漂亮,梯形的,呵呵,我们只看前面这几句句可以解决问题了
    xor eax, eax //清空ax
    cmp [ebp+arg_28], 0 //[ebp+arg_28],对照save_guildItemBox函数我们得出这是调用次数初始为0,与零做对比
    setnz al //对比结果如果大于零,即第二次及以上,al置1
    dec eax //eax自减
    and eax, 0FFFFD400h //相与
    add eax, 2C20h //相加
    push eax
    push offset aC ; "%c("//字符格式输出
    push [ebp+dest] ; s
    call _sprintf
    光看程序可能有点模糊,我们代入数据验证下:
    第一次:eax=20h
    第二次:eax=2c20h
    ......
    由此可以看出,问题可能是出在字符输出上,输出一个字符是不是代表着2c20h只能输出20h?如果是这样所有的疑问就都解决了。假设我们成立,那么我们把add eax,2C20H这句改成add eax,2CH,通过计算相应的把0FFFFD400h改成0FFFFFFF4H,保存,运行之,成功。其他数据库的修复亦同理,不断地尝试,不馁试验,总有成功的机会。今天就写到这里,谢谢各位看完。

    备注点东西:
    killitem %d,1,把gmsv这段原本的1前面空格去掉就可以成立时交出道具了.
    貌似不能建立右侧的人物啊?当输入好名字,配好属性后,点"创建"后,提示名字不能是空白???
    这个是tbl_user表格的问题,其实账号注册的时候应该是每隔一个seqnumber增加一个帐号,这样registnumber=seqnumber+dapaplace
    这个是猜测
    你修改下tbl_user中的seq打头的字段为一个偶数序列就可以了

    关于数据库无法创建第二个人物的解决方法:去掉tbl_user、tbl_character表格的唯一索引就可以了



  • 感謝分享~~~~



  • 看不明白哈哈!!



  • ddddddddddddddddddddd



  • 谢谢,获益匪浅



  • 谢谢楼主 慢慢看



  • 感谢楼主的分享 真是好东西不用自己琢磨了



  • 这太难了看完都不懂。。



  • 看起來好複雜阿


登录后回复