关于君望LE汉化问题的初步进展

做rUGP相关的工作最初是为了MLA。不过,如果能为君望汉化出一份力,我自然是在所不辞的,怎么说也是对我影响深刻的几部文艺作品之一。之前做了文本提取,反过来替换rio文件中的文本就是水到渠成。然后模仿yusjoel的做法,修改dll中的IsDBCS、CharSet和特殊字符处理,把SJIS用的函数换成GB的。到现在为止,已经可以把君望LE中的日文替换成自定义的GB码中文,并正常显示。第一张显示中文的图如下:

不管怎么说,现在算是迈出了第一步。界面汉化等问题先不提,文本本身还有个致命的问题:无法修改字符串长度。君望LE会检查字符串长度(也可能是对象长度?),不符合就报错退出。MLA就不检查!结果就是,虽然可以用结束符等效地缩短字符串,却无法增长。而缩短其实也不意味着后面剩的部分自动消失:剩余部分会以下一句的形式出现。后面还是得研究一下这个长度怎么校验的,才能得到一个能用的方案吧。

PS:才发现词背错了…平仄都没对上……

PS2:又经过一天的奋斗,搞定了改动单句长度的问题。从实验结果做出的猜测果然是正确的。现在单句的改动已经不受长度限制,只是脚本整体仍然要保持长度不变。这样一来至少可以用补空格的方式解决了。整体的校验看起来是在脚本外部,下一步就是争取找到跳过去。

备忘:rUGP相关进展,关于资源替换和脚本解析

六月底歇工以来,零零碎碎有一些进展。最近改论文改得不爽,也写了点代码换换心情。主要做了两件事,一是资源替换,二是脚本解析。

资源替换方面,主要是尝试了一下用插件方式动态替换几个dll中的字符串资源。这也是Nagato的补丁做的两件事之一——另一件事是钩住函数替换文本/图片资源。现在我的做法是:先用Passolo翻译,然后用一个bat根据修改后的dll生成所需C++代码,最后编译出插件,动态替换内存中加载的dll。实验的结果,替换本身是成功的,但是显示有问题。推断是字体问题:SJIS字符集里没有简体中文。将系统默认字体改为中文字体,主窗口的菜单就正常了。但是选项页和S/L界面仍然无法显示部分汉字。从种种迹象看,这部分界面使用的字体应该就是嵌在rio文件内的那两个MS P Gothic字体,一下子还真无从下手了。这就是汉化比英化麻烦的地方啊…只要不是内嵌自定制字体,哪儿会没有英文字形嘛……作为后续,字体的替换是一个问题,当然钩子是另一个问题…现在对OD仍然生疏,两者都不容易吧。

脚本解析方面,设计了新的文本识别算法,相对RioX-1.1.89.524发布的那一版,错误率有显著的降低。之前的算法是在解码的二进制脚本中搜索具有SJIS编码特征的部分。算法对脚本结构信息用得很少,而字符串特征偏弱(比如有时选项字符串可能只有4字节,如“違う”),错误会多一些,粗估在千分之几。这次借鉴了RIODecode的思路和alterdec提供的结构知识,采用假设—判定/归谬的思路(跟我当年那个地图匹配算法主要思想一致……),设计了脚本内对象识别分割的算法,把脚本的构成对象分离开并确认类型,然后分别对CVmGenericMsg和CVmMsg类对象进行解析识别文本。这样一来用到了较多的结构信息,错误率粗估在万分之五左右,可能更低。

错误率到这个数量级的话,大约相当于游戏中读一个小时的文本中有一条解错,对人工修正来说负担比较轻了。我想这一版的文本提取结果可以拿来给汉化组的初翻用了。为了适应可能的汉化任务,也做了进一步修正的接口——读入错误记录的偏移列表,就可以在解析时修正错误。提取仍不完美是个遗憾,不过或许没有办法,毕竟找不到足够强的特征。RIODecode在很多脚本上单独设置了参数才完成解析;alterdec的思路要扩展到其他游戏,则需要对该游戏做大量的针对性解析工作。作为一个age社作品通用文本提取方案来说,我想,对rio文件中脚本的一般性解析可以告一段落了,文本提取也基本算实用化了。

下一步要做的,就是测试封包,尝试替换原始脚本,看看好不好使。这正是yusjoel那套工具的功能。我这里不同的是,不再是基于alterdec的MLA专用工具,也可以用于age社其他作品。如果测试顺利,或许,君望汉化的长久怨念就只剩下翻译的工作了。虽然现在还无法修图换图,虽然现在的补丁方式还不够漂亮,但是,这些没有那么重要。我当年也有过等汉化望眼欲穿的经历,最重要的还是文本翻译。