OnmyojiAutoScript组队探索异常处理机制分析

OnmyojiAutoScript组队探索异常处理机制分析

OnmyojiAutoScript Onmyoji Auto Script | 阴阳师脚本 项目地址: https://gitcode.com/gh_mirrors/on/OnmyojiAutoScript

问题背景

在OnmyojiAutoScript项目中，用户报告了一个关于组队探索功能的问题：当两个账号组队进行困难28层探索时，经过几轮战斗后会出现卡住现象。具体表现为两个账号都返回庭院不动，随后脚本开始报错。

问题现象分析

从日志中可以观察到以下关键行为序列：

1. 战斗结束阶段：队员账号完成战斗并获得奖励后，系统检测到"队伍表情未出现"的警告
2. 异常处理触发：脚本启动了一个10秒的定时器来验证队员是否真的离开
3. 定时器到期：10秒后定时器触发，系统判定队员已离开
4. 退出处理：队长和队员账号都执行了退出探索的操作

技术原理剖析

该问题源于项目中的异常处理机制设计。在组队探索功能中，开发者实现了一个队员中途跑路的检测机制：

1. 检测条件：当系统检测不到队伍表情时，会认为队员可能已经离开
2. 验证机制：启动一个10秒的定时器进行二次确认
3. 处理逻辑：如果定时器到期仍未检测到队伍表情，则执行退出探索的操作

问题根源

在实际运行中，这种设计存在一个潜在缺陷：在战斗通关后的特定场景下，系统可能会误判为"队员离开"。具体表现为：

1. 战斗通关后的界面切换过程中，队伍表情可能暂时不可见
2. 系统将此状态误判为队员离开
3. 定时器到期后强制执行退出操作
4. 导致两个账号都异常返回庭院

解决方案建议

针对这一问题，可以考虑以下改进方案：

1. 增加状态验证：在检测队伍表情前，先确认当前是否处于组队探索场景
2. 延长验证时间：适当延长定时器时间，避免短暂界面切换造成的误判
3. 多重验证机制：结合其他界面元素共同判断队员状态
4. 异常处理优化：在退出前增加额外的状态确认步骤

技术实现考量

在实际代码修改时需要注意：

1. 保持原有异常处理的可靠性，不能因为修改而降低对真实异常的检测能力
2. 考虑不同设备和网络环境下的响应时间差异
3. 确保修改后的代码不会引入新的竞态条件
4. 在保证功能稳定的前提下，尽量减少额外的检测开销

总结

这个问题展示了在自动化脚本开发中常见的状态误判情况。通过分析日志和代码，我们可以理解到在复杂的游戏界面交互中，简单的元素检测可能不足以准确判断当前状态。需要设计更加鲁棒的检测机制，结合多个界面元素和时间因素来做出更准确的判断。这也提醒我们在开发类似功能时，要充分考虑各种边界情况和异常场景。

OnmyojiAutoScript Onmyoji Auto Script | 阴阳师脚本 项目地址: https://gitcode.com/gh_mirrors/on/OnmyojiAutoScript