FQ脚本错误在传奇M2引擎的报错记录里不算特别常见，但一旦出现往往让人摸不着头脑。这个错误通常与脚本中的非法操作、跳转逻辑混乱或引擎对特定命令的拦截机制有关。下面从错误产生的原因入手，结合具体排查步骤和修复方法，把这个问题讲透。
**第一层：搞清楚FQ脚本错误到底是什么**
FQ这两个字母在传奇脚本语境里没有官方定义，但从大量实际案例来看，它主要指向两种可能。一种是引擎对“非法请求”的英文缩写拦截提示，比如脚本试图执行超出权限的操作，或者调用了被引擎判定为不安全的命令。另一种是脚本逻辑中出现了无限循环或过度频繁的GOTO跳转，触发了M2的保护机制，用FQ作为代号记录在日志里。
在GOM、GEE、BLUE这些主流引擎中，FQ错误往往伴随着具体的位置信息，比如“FQ脚本错误：QuestDiary\活动脚本.txt 第88行”。这说明引擎在执行到这一行时，检测到了异常行为，主动中断了脚本运行并记录报错。
**第二层：查看错误日志锁定具体位置**
遇到FQ报错，第一步不是瞎改脚本，而是去翻M2的日志文件。路径通常在D:\MirServer\Mir200\Log\ErrorLog.txt或M2控制台直接显示的红色报错信息。用记事本打开ErrorLog.txt，搜索“FQ”关键词，找到对应的错误记录。
日志里会明确写出报错的文件名、行号和错误描述。比如“FQ脚本错误：QFunction-0.txt 第1256行，错误代码：502”。这个502代码在不同引擎里有不同含义，GOM引擎通常表示“GOTO跳转次数超限”，GEE引擎可能表示“变量操作越界”。记录下这些信息，后面修复时才有依据。
如果日志里只有时间戳没有具体行号，那就需要手动去脚本里加调试输出。在可疑脚本的每一段关键命令后面插入SENDMSG 6 当前执行到第N步，然后触发报错，看最后一条输出停在哪里，那个位置就是问题点。
**第三层：GOTO循环超限导致的FQ错误**
这是最常见的一类FQ报错。写脚本时为了简化代码，习惯用GOTO @XXX跳来跳去，但如果某个标签被反复调用，且没有设置退出条件，引擎会认为进入了死循环。默认情况下，M2的ScriptGotoCountLimit参数设置是10，意思是同一个GOTO跳转最多执行10次，超过就报FQ错误并终止。
解决办法有两个方向。一是修改M2的循环次数限制，在D:\MirServer\Mir200\!setup.txt里找到ScriptGotoCountLimit=10，把这个值改大，比如改成10000或50000，保存后重启M2。这个办法简单直接，但治标不治本。
二是从脚本逻辑上优化，尽量减少GOTO的使用。可以用DELAYGOTO 延迟跳转命令替代直接GOTO，比如DELAYGOTO 1000 @XXX，让脚本每间隔1秒才跳转一次，避免瞬间高频循环。或者用CALL命令调用子程序，把重复的逻辑写成独立的段，用#CALL方式加载，比GOTO更安全。
**第四层：命令不兼容或引擎版本问题**
FQ报错也可能源于脚本里用了当前引擎不支持的扩展命令。比如从网上下载的版本原本是用GEE引擎写的，里面用了GEE特有的变量类型<$STR(U0)>，但你现在用的是GOM引擎，GOM根本不认识U0变量，就会报错。
去引擎官方网站下载对应的命令手册，查一下报错行使用的命令是否在当前引擎的支持列表里。如果发现不兼容的命令，要么换成该引擎的等效命令，要么把整套引擎和登录器换成和脚本匹配的版本。
还有一种情况是引擎版本太老，不支持新版脚本的某些写法。比如0328版GOM对变量的支持就不如1108版完善。建议把引擎升级到稳定版本，比如GOM 1108，GEE 2020以后的版本。
**第五层：变量未初始化或类型错误**
FQ错误的另一个源头是变量操作出界。比如用DEC命令减少变量值，但这个变量本身是空的，或者用LARGE比较两个变量，其中一个根本没赋值，引擎在计算时发现数据异常，就会报FQ。
检查报错行附近的变量，看它们有没有在前面被正确初始化。比如S$任务计数这个变量，在脚本开头应该先写一句MOV S$任务计数 0，保证它有个初始值。后面再INC或DEC时才不会出错。
另外注意变量类型的区别。GOM引擎里P0、D0是数值型，直接比较用LARGE D0 5；S$开头的是字符串型，比较要用EQUAL S$变量名 某值。如果把字符串当数值比较，或者反过来，引擎也会报错。
**第六层：脚本编码格式问题**
用Windows自带的记事本编辑脚本后保存，默认编码可能是UTF-8带BOM，而传奇引擎只认ANSI编码。如果保存成UTF-8，引擎读取时会把文件头几个字节当成乱码字符，导致整段脚本解析失败，报FQ或别的诡异错误。
修复方法是用Notepad++打开脚本文件，在“编码”菜单里选择“转为ANSI编码”，然后保存。注意是“转为”不是“用ANSI编码打开”，因为文件本身已经是UTF-8了，直接打开再保存还会是UTF-8。必须先转换编码再保存。
**第七层：插件或DLL冲突**
有些FQ错误不来自脚本本身，而是插件引起的。比如挂了某些功能插件，但插件没有正常加载，或者插件版本和引擎不匹配，导致脚本调用插件命令时被拒绝。
在M2的“插件”列表里检查所有插件是否都打上了勾，状态显示为“已加载”。如果有未加载或加载失败的，先重新配置插件。如果某个插件确定用不上，就在PlugList.txt里把它删掉，避免干扰。
**第八层：实际案例修复步骤演示**
假设现在M2报错：FQ脚本错误：QFunction-0.txt 第520行。用Notepad++打开QFunction-0.txt，定位到520行，发现是一段[@Attack]触发下的脚本，里面写了一个循环：
```
#ACT
MOV P0 0
WHILE P0 < 100
INC P0 1
GOTO @检查物品
#ENDWHILE
[@检查物品]
#IF
CHECKITEM 回城卷 1
#ACT
TAKE 回城卷 1
GOTO @Attack
```
这段脚本的问题在于，每次[@Attack]触发都会执行WHILE循环，循环里又用GOTO跳到[@检查物品]，[@检查物品]最后又GOTO回[@Attack]，形成了无限循环的闭环。虽然WHILE本身有100次上限，但GOTO跳转把循环绕开了，导致M2监测到GOTO次数爆炸。
修复方法：删除GOTO跳转，把检查物品的逻辑直接写在WHILE循环里，或者用FOR循环替代GOTO。修改后：
```
#ACT
MOV P0 0
WHILE P0 < 100
INC P0 1
CHECKITEM 回城卷 1
#IF
CHECKITEM 回城卷 1
#ACT
TAKE 回城卷 1
#ENDWHILE
```
保存脚本，重启M2，再次触发[@Attack]就不会报FQ了。
**第九层：修复后的验证方法**
改完脚本不能直接开区，得用测试账号跑一遍所有相关功能。如果是攻击触发报错，就脱了武器砍怪物几十次，看M2还会不会报FQ。如果是拾取触发，就捡一堆东西测试。如果涉及变量累积，要反复操作直到变量值达到边界，比如从0加到1000，再从1000减到0，确认没有溢出。
同时打开M2的日志窗口，一边测试一边观察有没有新错误产生。最好连续测试半小时以上，确保稳定。
