《来自边境

这款游戏采用的是rpgsave格式储存，也是基于平台开发而来，加密部分较少，恰好游戏内的刷刷刷让我有了一点厌烦，于是我萌生了一点修改的想法。

游戏内的升级后会获得sp值，我想用CE修改增加这个数，数值*2搜索，然后搜索变化数值，努力几次后，无果。

于是去网上寻找修改，网址的，软件的，在变量列表里看见了许许多多眼花缭乱的变量，逐一修改验证，无果。

发现有人借助查找游戏源文件修改，简单思索，应该从角色升级入手，于是打开CommonEvents.json，全局搜索lvup，共22处，逐一看过，无果。

也许应该搜索lv，共77处，无果。

搜索过程中突然想到，也许搜索sp更好，共193处，成功搜索到一处代码的注释为“SP加算処理”。细看，发现参数为parameters":["STS ADD SP(5) ACTOR(\\v[29])"]，推测STS为技能树，ADD为增加，SP(5)为增加5点sp，actor为角色。于是修改SP括号内数值，测试，成功。

注意： SP加算処理 在该文件中存在于2个地方，其中一个地方是测试用例，在修改时需注意，或者2个地方都修改，就没有这个烦恼了。

我没有接触过rpg制作，不清楚其机制原理，所以以下均为猜想：

    我截取了 SP加算処理 的前半部分内容，用正则简单格式化了一下，介绍一下我修改时的思路。

初看马上就能定位到code356部分，很明显code356是负责sp增加的接口，不过第5，10，13，20行均为重复内容，常理上推测不应出现，有可能的推测是ifelse的编译导致的，为了健壮性采用ifelse确保成功执行，一种常见的代码写法，表现出来的就是重复内容，但前后有看不出什么联系，令人疑惑，暂且略去。

接着猜测升级相关应该是与角色位置有关系，从图中可以很清晰地看出，涉及Actor的地方有4位角色，恰好对应队伍中的4个角色，如果是采用角色id进行计算，那么方法应该是循环，遍历，指定这3种中的一种，涉及Actor的地方应该为1次，或者是角色数量20次，或者主要人物11次。图中Actor共出现了4次，那么采取队伍位置计算的可能性更大。ACTOR(\\v[29]) 这种形式的参数，\\v 极有可能是变量池，池中的第29个位置应该存放的是队伍中第一个角色，即主角，第30个位置存放队伍第二个角色，以此类推。回过头思考，也有可能因为主角身上挂载了其他事件，导致code356需要多次执行才能生效，存疑。

至于图中多次出现code355，主要是关于参数池中参数37的修改，查询参数表，发现这个参数的注释表明此参数没有多大意义，推测应该是一个中间参数，紧接着参数37的就是主要角色SP总值的参数，推测参数37为中间参数，极有可能是通过参数37来计算其他角色的SP总数。但是为什么我没有修改code355里传参部分里的+5，却仍成功修改了SP值呢？不清楚原因，如果当时修改失败的话，我下一步必然是修改这块内容。

code355还涉及了参数720，通过上面的推测，估计也是一个中间参数，后面传参部分的+1，应该是对应记录角色等级。

而图中的其他部分，应该是定位角色，更新参数变量等等操作。

当然这个猜想还是充满了漏洞，且不论总体方向的对错，ACTOR(\\v[29]) 多次出现就是个谜，19行的code108中的※肯定有着特殊作用，因为※这个符号在文件中多次出现，可能是区分主角和其他人的升级，但印象中两者并无区别。另外code355的出现频率过高，有许多地方我推测不出出现的必要性。

如果有人在修改的时候产生了疑惑，希望我修改时的思路能帮上忙。