完全干掉原版EasyRPG.dll
源码还原度95%(剩下的太难了)

代码已基本全还原了,重写了源码,爆改了底层.同时也出现很多莫名其妙的问题

2天一夜的BUG1: 下线之后上线就是出问题,存档怎么对都是对的
UserInfo ID对应的是用户加入的顺序
还有一个是IDObj对应的是游戏加入的顺序
当时写错了,因为游戏第一次进入没问题,切存档也没问题,实在是不知道哪里错了,只能几万行代码里面找哪里有问题

2天一夜的BUG2:保存游戏之后小退再上线,卡死在重新进入游戏中
同样如BUG1没有任何报错,也没任何问题,也只能翻代码找问题
后来各种排查代码,都没发现任何问题,于是想到,我代码没问题,服务端肯定有问题
最后发现因为我把存档机制改了,服务端调用存档的机制居然特么不是调用的DLL代码,而***的sb复制的一模一样的代码读存档.原地吐血

断断续续将近一个礼拜的BUG3:NPC无法对话
不能对话还好说,***的鼠标放上去没变化,直接蒙了,这些查什么代码也莫得办法了
翻代码最多体力活,,这下就是只能一行一行重写验证是否逻辑有问题,***肯定是不可能的,工程量都用了这么多年了.
尝试1:哪能咋办吗,不可能也得重写,不过源码早滚瓜烂熟了,于是复制核心已经验证绝不会有问题的代码,搭建了个最精简的能进入游戏的框架,再跟之前的对比排除,无功而返.直接吐血升天
尝试2:既然小型化的框架也有问题,那就直接注入原版DLL,那总没问题,然后再一个一个函数替换,终于找到出错的地方了.
原因:因为用c++17重写源码,而原版是c++98.bool***用的BOOL(int)类型.
因为bool是一字节,而BOOL是4字节,返回的是bool但接受的返回对象值是int.
编译器编译出的大致伪汇编代码就会是:
如果一开始EAX被其他变量赋值了,假设是11 11 11 11
这时候赋值bool值 因为bool一字节的原因 就会变成11 11 11 01
返回的时候就出大问题了,对方接收的是一个int类型 这就是什么1跟0 true跟false了

新概念:
去除本地存档机制
所有物体,玩家,道具等等全部具备全球唯一ID
所有物体全部存到键值数据库
结果:
所有物体都是唯一的,可随时对任意时间物体还原
无视原机制存档大小
游戏内物体无限存在

工作忙,还没凉

2025年5月3日10:12:52 没错我回来了.
由于本人在上班,之前的一直处于未完善的bug版.
以前只会些编程相关的皮毛,自从工作之后才发现当初的我还是挺倔的,但是自我欣赏那份倔强.闲话就不说了.
天骄经历过好几个版本的迭代,也间接的反映了自我能力的变化.
1版:DLL修改
2版:内联汇编修改
3版:Hook函数修改
4版:Hook函数Lua桥接版
5版:Hook函数c++版
3-5版其实一直是Hook原Dll函数转入自定义代码层修改.
4-5版硬生生的把反汇编的伪代码转为纯开发代码.
耗时长但一直是迭代更新中.只是这个所谓的更新是看不到进展,可是不管怎么处理始终无法摆脱底层代码的限制.
后面工作了就一直处于封存状态了.
这几年能力有所提升,思维也不在被局限,刚好51没回家,抽个空折腾个全新版本.
新版预告:
实现方案:c++/clr桥接exe与dll的导出类,clr层定义dll层的c++导出类,构建原dll的c++导出函数中转到c#层,c#层通过clr层桥接c++类相互调用.
之所以要设计这一套方案,c#的反射及特性可以让自定义上升一个高维度,同时也大幅度降低开发难度.自主可控,可调试,mod开发不再是什么太难的事情了.
3天3夜加上之前研究储备的技术点终于从方案落地的可行性验证.核心逻辑的c++代码转c#,最小化框架进入游戏


之后呢,可能节假日结束又是封存状态了,但是这版将会不断完善.可也不会停止.没有业务逻辑,补充代码调整优化框架