书接上回，Prilo 已经正式立项了。
2 月 21 日，运营突然宣布要出 9.11 版本。原定 Prilo 是要以关服前的最后一版安装包作为基底修改的，但是 22 日 9.11 版本公开之后，解压一对比，发现增加了 2023 年 3 月 31 日 UTC 7 时以后封面画面不再播放 bgm，以及（无视年份）3 月登录奖励日历 4 月格子显示为空白，这样两项充满了关服气息的更新内容。那么 9.11 版本就不再适合作为 Prilo 的基底了。
因此，Prilo 的基底就决定是 9.10.1 版本了。
这件事情决定之后，接下来就是要在 9.10.1 版本可以登录游戏的最后期限内（2 月 28 日下午定期更新前），把游戏内的各种下载资源做一个终极大备份。
以 alay 为参考，搞清楚了 0=bootstrap，1=live，2=scenario，等等到 6 为止各种类型的包。0～4 包都有批量获取下载链接的 api，下载完了。5 和 6 包只能挨个下，过两天再说，反正量也不算大。
统计一下全部资源大小，0 包 694MB，1 包 198MB，2 包 1.81GB，3 包 2.06GB，4 包 6.94GB，5 包和 6 包未知。
目测 SIF 全部资源大小在 11～12GB 之内。
Prilo 发包时应该要做大刀阔斧的删减，这个之后再说。这个 api 下载机制我估计都能写上两星期代码才能写出来。
与此同时，由于时间紧张，我们绝对没办法写完所有的 api。首先，SM、协力、RC 基本上直接判死刑了。散拉判无期，因为手头几乎没有任何可以参考的 api 资料。剩下的再分轻重缓急，目前我认为，只要通常打歌和卡池和组队这几个 api 就绪了，Prilo 就可以直接发初版了。剩下的什么段位啊饰品啊通通可以以后再看情况。
修打歌 api 时遇到了问题，明明往 external 里覆盖了新的 db 文件进去，但是客户端就是不认，非得去 install 里面找 db。这个是非常反经验的。
思来想去，过了好久好久，突然灵机一动，想到了以前做客户端安装包 diff 的经验。在做这个 diff 时，其实一直以来都是要把每个文件的前 16 字节剃掉，只对剩下的算 md5/sha1，以此来 diff 的。那么这些字节里可能有鬼。
进一步打表分析，发现这个加密文件头部竟然含有数据包版本号。而以往所用的反加密器是写死版本 17.0 的，难怪识别不出来。
这个答案好像又进一步给写下载分发模块增添了新的复杂度。那就拖到三个星期去吧。
在这段时间还遇到了新的问题，就是怎么把日服客户端给改成北京时间。因为 Prilo 服务器应当是以北京时间为基准的。客户端如果继续按东京时间，就会在每天 23:00～23:59 期间，出现看不到日替歌曲之类的错误。
先找了 game_mater.db_，没找到关于时区的配置。
然后又找了 const.lua，里面也没看到相关的配置。
然后干脆直接暴力搜索 32400，搜到了 datetime.lua 文件。
拿来 SQ 的 datetime.lua 文件，一对比，奇怪居然一模一样一点都没改。这是怎么回事？
次日才发现 SQ 另有一个 shengqu.lua 文件，里面魔改了——
Datetime.getEstimatedServerTime_oldShengQu = Datetime.getEstimatedServerTime
Datetime.getEstimatedServerTime = function ()
return Datetime.getEstimatedServerTime_oldShengQu() - 3600
end
这个文件另外还魔改了登录机制等很多东西，肯定不能整个文件照抄过来了。
那么唯一的出路就是把原本 datetime.lua 文件里面的 32400 给强制改成 28800。
这就需要对已编译的 lua 文件进行强改了。
以 hex 打开这个文件，试着搜索了一下 32400 的 hex 值，居然没找到。奇了怪了这个常量到底是乍存的……
网上搜索 lua 5.2 的字节码，中文搜索（百度）有效资料为零，英文搜索（Bing）搜到一份资料：https://blog.tst.sh/lua-5-2-5-3-bytecode-reference-incomplete/
这个标题里的 Incomplete 很让人不安啊……
文件开头，1b 4c 75 61 等等，都对得上，嗯至少版本正确。
然后 main 以下的就完全对不上号了，根本不知道哪是哪了。
emm……
干脆对着反编译出来的代码，看清楚 32400 这个数字的位置，看看它前后有什么字符串常量，然后去找。
数字还是没找到，前后的字符串倒是不难找。对比了一下资料里说的，每个 const 首先有一个 u8 的 type，4 表示字符串。然后资料里就直接说后面是跟 string value 了——但是实际比较了一下发现，04 后面首先跟一位表示字符串长度（含结尾 \0，例如 os 的长度就是 03，time 的长度就是 05），然后跟 00 00 00，然后就是字符串本体。
顺藤摸瓜，32400 这个数字所在位置的前一个函数，那个函数里应该有五个常量，前四个是字符串，第五个根据反编译的结果应该给出数值常量 -3600。在四个字符串编码后面，首先蹦出来一个 03，资料说 03 就是 number 的类型了，这确实没错。但是后面的是 00 00 00 00 00 20 AC C0，这就是 -3600……这怎么看都不像啊……
这个文件里应该还有更多的数值常量，但是不太好找了。想来想去写了个脚本，直接输出这个文件里所有 03 的位置。然后再去看，嗯，找到了更多的常量：3600=20AC40，32400=A4DF40，86400=18F540。
找规律，请问 28800=？
emm……
根本看不出来，最后决定暴力试。我们现在唯一的好消息就是 32400 这个数字存在这个文件里的哪几位上，已经是能找到的了。稍微改一点点，然后再拿去反编译。一看结果，嗯，确实在该变的位置上变了。
再一点一点凑过去，总算是把 28800 给凑出来了，直到完工都还没搞懂这个数字到底乍编码出来的。
客户端时区的问题可能解决了？但是没测试。反正这个想测试也得等 23 点再来测试，干脆就拖着先了。
记一下现在仍然没有解决的问题：
（1）字体问题。日服字体不能显示部分简中文字，国服字体不能显示部分符号（你游最重要的两个符号，音符符号和波浪线符号，居然都不能显示），都不理想，都得换。
（2）下载打包发包。这玩意真属于相当复杂的了。慢慢来。
（3）本来应该在前一篇里写的，关于客户端向第三方发送消息的事情。
主站可能会很快就宣布 eis Project P（仮）。预计 3 月释出 2 键 EXPERT 曲的静态截图，4 月 1 日释出 2 键 EXPERT 曲的视频，瞄准 4 月 15 日或者 5 月 7 日完工。