Hero 换版本后脚本报错：五个已废弃的写法

Hero 系引擎这些年改过不少命令。老版本写好的脚本，搬到新 M2 上，有时候能加载，但点了 NPC 什么也不发生；有时候直接报一个行号，让你对着几千行脚本找问题。

一、为什么老脚本会突然报错

三个原因：命令改名、参数顺序变了、以及旧命令被合并到新命令里。

改名和删除还好办，报错会告诉你。最麻烦的是“命令还在，但什么都不做”，这种不报错，只能靠结果判断。

所以迁移脚本，不能只看能不能加载，要看每个功能实际跑一遍。

二、写法一：旧的变量取值

早期脚本取值常用一套简写，新版里这些简写有的被废弃，有的含义变了。

表现是取到的值永远是零，或者取到的是别人的数据。脚本不报错，但判断全部走偏。

处理办法是把取值改成显式的写法，写清楚取哪个对象的哪个属性。啰嗦一点，但不会因为版本变化而失效。

排查时先找一个用到变量的判断，打印出来看值对不对。值不对，后面的逻辑全是错的。

三、写法二：命令参数顺序

有些命令的参数在新版里调了顺序，或者增加了可选参数。老脚本按老顺序传，命令能执行，但作用对象错了。

这类问题最隐蔽。比如给物品的命令，参数一换，变成给了别人或者给了空气。

处理办法是对照新版命令说明，逐个核对参数。不要凭记忆，记忆最容易出错。

核对时把参数写成一行一个，加注释说明每个参数是什么。下次再迁移，直接看注释，不用重新猜。

四、写法三：NPC 对话跳转

对话跳转的写法改动最频繁。老的跳转标签、新的跳转格式，混在一起就会出现“点了没反应”。

表现是对话框能打开，点按钮没动静，或者点了跳到别的 NPC 去了。

处理办法是把对话拆开，一段一段测。先测打开，再测每个按钮，最后测跳转回来。

对话量大的 NPC，建议重写成结构清晰的分段，不要用一大段嵌套。嵌套越深，迁移越难。

五、写法四：物品与怪物调用

物品和怪物的调用，依赖名字或者编号。新版如果改了默认编号，或者增加了命名空间，老写法就找不到了。

表现是给物品没给成、召唤怪物召唤不出来，或者召唤出来是另一个东西。

处理办法是统一用编号，不依赖名字。编号相对稳定，名字容易改。

如果必须用名字，迁移后先做一次全量检查，把所有引用的名字列出来，逐个确认存在。

六、写法五：定时器与延迟

老的定时器写法在新版里可能精度变了，或者触发时机变了。表现是“该一秒后执行的，变成十秒后”，或者根本不执行。

定时器还容易和地图切换冲突。玩家换图之后，定时器丢了，脚本就卡在半路。

处理办法是给定时器加一层判断：执行前先确认玩家还在原来的场景，不在就跳过。

延迟执行的时间不要写得太短。太短在老机器上会被合并，看起来像没执行。

七、批量排查的方法

第一步，把所有脚本按功能分类：NPC 对话、装备、活动、传送。分类之后，一类一类测。

第二步，准备一份检查清单，每类脚本列出必测的动作：打开、点击、给东西、传送、结束。

第三步，测一个勾一个。不要凭印象认为“这个应该没问题”，没测就是没测。

第四步，把所有报错行号记下来，对照命令说明。同一类错误往往会重复出现，改一处就能举一反三。

八、回退与并存

迁移不要一次全换。先在一个测试区跑，跑顺了再换正式区。

测试期间保留老版本的脚本备份。新脚本出问题时，能立刻切回去，不至于开不了区。

如果两个版本要长期并存，建议把差异部分单独抽出来，按版本加载。公共逻辑不动，只换差异，维护成本最低。

换版本本身不难，难的是那些不报错的失效。把每个功能实际跑一遍，比看一百行报错有用。

九、迁移前的五步清单

第一步，备份。整个脚本目录复制一份，按日期命名。迁移出问题，直接覆盖回来，不用凭记忆撤销。

第二步，列清单。把脚本按功能分组，标出哪些是核心、哪些是可选。核心的先迁，可选的可以后补。

第三步，查命令。把脚本里用到的命令一条条列出来，对照新版说明，标出改名、改参数、废弃的。

第四步，单点验证。每改完一类，就在测试区实际跑一次，不要攒到最后一起测。

第五步，灰度上线。先在一个小分区跑一天，确认没有异常，再推全服。

五步里最容易省掉的是第一步和第五步。省掉备份，出问题只能重写；省掉灰度，问题会在人最多的时候爆发。

迁移这件事，慢一点反而快。一次只动一类，出问题时能立刻定位到是哪一类。

最后留一个习惯：每次换版本前，把当前能正常跑的功能列成清单，换完逐项对照。清单在手，迁移就从“凭感觉”变成了“照单核对”。

清单越具体，迁移越省心。