激活登录：条件判断与循环容错
你遇到的“首次激活后脚本报错停止”是典型的逻辑分支缺失问题。天骥脚本是顺序执行，必须对“激活对话框”这一状态进行前置判断。
解决方案：状态检测与跳转
不要直接写死“点击激活”命令。应在脚本开头使用条件判断检测登录状态，若已激活则跳过该步骤。天骥V1185支持触发器检测窗口标题或文本内容，建议采用以下逻辑结构：
:循环开始
如果[检测到窗口标题含“激活”]
点击[激活登录]
否则
// 什么都不做，继续执行后续登录
结束如果
// ... 后续登录步骤
转到[:循环开始]
若触发器功能受限，可采用时间戳标记法：首次运行后生成一个标记文件，后续循环读取该文件，若存在则跳过激活步骤。若已解决但仍需优化，建议在激活命令后增加 等待[2000] 毫秒级延迟，确保窗口完全响应，避免因网络延迟导致点击失效。
特修命令：后门指令与超时机制
“提示不支持命令却又能修”的现象，根源在于你使用了发送命令（前门命令），而非后门命令。
命令机制差异
• 发送命令：天骥在执行 发送命令[@002] 前，会先向服务器查询NPC是否支持该指令。由于部分服务端对 @002 这类自定义指令的响应不规范，天骥误判为“不支持”，故抛出错误停止脚本。但此时指令实际上已发送至服务器队列。
• 后门命令：该命令不进行前置检查，直接向服务器发送指令字符串。即使NPC不支持该命令，脚本也会继续执行，不会因误判而中断。
修复方案
将脚本中的 发送命令[@002] 和 发送命令[@S_REPAIR] 全部替换为 后门命令[@002] 和 后门命令[@S_REPAIR]。由于 后门命令 不检查NPC支持情况，会直接触发服务器端的修复逻辑，从而避免“该NPC不支持这条命令”的假阳性报错，消除脚本停止的隐患。
执行缓慢分析
“语句超后却修了”说明服务器端处理 @002 指令存在延迟，或NPC对话树层级较深。建议在两条后门命令之间增加 等待[500] 毫秒的间隔，给服务器留出处理响应的时间，确保 @002 完全生效后再执行 @S_REPAIR。
脚本稳定性增强建议
1. 异常捕获：在特修模块外围添加 异常捕获[开始] 和 异常捕获[结束] 块，当特修过程出现非致命错误时，脚本可记录日志并继续执行后续循环，而非直接崩溃退出。
2. NPC对话重置：部分版本特修需先打开NPC对话框。在执行后门命令前，先使用 说话[@main] 或 对话NPC[武器店老板] 重置对话状态，确保指令在正确的上下文环境中执行。
