御魂副本弹出“御魂达到上限窗口”时会卡住，但在探索副本弹出时会自动点击关闭

[FadingGlimmer]

在提问之前...

• 我已经搜索了现有的 issues
• 我在提问题之前至少花费了 5 分钟来思考和准备
• 我已经阅读了文档中的 常见问题(FAQ)
• 这个问题出现了至少三次，不是偶发的
• 我使用 OAS 的 dev 分支

描述你的问题

御魂副本弹出“御魂达到上限窗口”时，会卡住，没有按预期那样，发现窗口就调用“御魂整理”任务。
但在探索副本弹出时，会自动关闭该窗口。
看log好像是“GameTooManyClickError”发生在了发现“御魂达到上限窗口”之前。

如何复现

1. 前往 '...'
2. 点击 '....'
3. 滑动到 '....'
4. 出现问题

预期行为

No response

相关 Logs

──────────────────────────────── INVITE FRIEND ─────────────────────────────────
INFO     | 23:46:52.028 | INVITE FRIEND                                         
INFO     | 23:46:52.033 | Ensure enter invite page                              
INFO     | 23:46:52.643 | Room type: normal_3                                   
INFO     | 23:46:52.646 | Click add to invite friend                            
INFO     | 23:46:52.938 | Click (1040,  265) @ GI_ADD_2                         
INFO     | 23:46:53.245 | [F_LIST_1 0.018s] [好友]                              
INFO     | 23:46:53.319 | [F_LIST_2 0.051s] [最近]                              
INFO     | 23:46:53.404 | [F_LIST_3 0.067s] [察友]                              
INFO     | 23:46:53.486 | [F_LIST_4 0.067s] [路区]                              
INFO     | 23:46:53.519 | Friend class: ['好友', '最近', '寮友', '跨区']        
INFO     | 23:46:53.565 | Now find friend in 好友                               
INFO     | 23:46:55.686 | [FRIEND_NAME_1 1.104s] ['Iself-mmil', 'm清清忧心',    
         'Iself-sdy]', 's秋风与落叶', '贩早见琥珀主', '君辞丶']                 
INFO     | 23:46:55.691 | OCR [FRIEND_NAME_1] detected in [1]                   
INFO     | 23:46:55.699 | OCR [FRIEND_NAME_1] detected in (442.0, 206.0, 87.0,  
         18.0)                                                                  
INFO     | 23:46:55.704 | Click ( 496,  208) @ FRIEND_NAME_1                    
INFO     | 23:46:56.687 | [FRIEND_NAME_2 0.925s] ['[self-hual', 'h缨缨鼠',      
         '剑与心', '账中妖a', '轻芋']                                           
INFO     | 23:46:56.696 | OCR [FRIEND_NAME_2] detected in [2]                   
INFO     | 23:46:56.707 | OCR [FRIEND_NAME_2] detected in (735.0, 294.0, 69.0,  
         24.0)                                                                  
INFO     | 23:46:56.713 | Click ( 798,  311) @ FRIEND_NAME_2                    
INFO     | 23:46:57.779 | Click invite ensure                                   
INFO     | 23:46:57.798 | Click ( 739,  563) @ GI_INVITE_ENSURE                 
INFO     | 23:47:00.115 | Start challenge and user only invite one friend       
INFO     | 23:47:00.419 | Click (1221,  640) @ GI_FIRE                          
───────────────────────────── GENERAL BATTLE START ─────────────────────────────
INFO     | 23:47:01.018 | GENERAL BATTLE START                                  
INFO     | 23:47:01.021 | Current count: 1                                      
INFO     | 23:47:02.939 | Click (1200,  607) @ GB_PREPARE_HIGHLIGHT             
INFO     | 23:47:03.846 | Click (1188,  566) @ GB_PREPARE_HIGHLIGHT             
INFO     | 23:47:04.444 | Add stuck record: BATTLE_STATUS_S                     
INFO     | 23:47:04.448 | Start battle process                                  
INFO     | 23:47:34.968 | Click (1025,  162) @ GB_WIN                           
INFO     | 23:47:35.256 | Win battle                                            
INFO     | 23:47:36.763 | Click ( 139,  219) @ C_REWARD                         
INFO     | 23:47:38.570 | Click (1110,  437) @ C_REWARD                         
INFO     | 23:47:40.376 | Click (  97,  229) @ C_REWARD                         
INFO     | 23:47:42.188 | Click (1197,  432) @ C_REWARD                         
INFO     | 23:47:43.996 | Click ( 895,  639) @ C_REWARD                         
INFO     | 23:47:45.799 | Click ( 102,  540) @ C_REWARD                         
INFO     | 23:47:47.604 | Click (1162,  522) @ C_REWARD                         
INFO     | 23:47:49.411 | Click ( 139,  254) @ C_REWARD                         
INFO     | 23:47:51.215 | Click ( 878,  626) @ C_REWARD                         
WARNING  | 23:47:53.022 | Too many click for a button: C_REWARD                 
WARNING  | 23:47:53.025 | History click: ['GB_WIN', 'C_REWARD', 'C_REWARD',     
         'C_REWARD', 'C_REWARD', 'C_REWARD', 'C_REWARD', 'C_REWARD', 'C_REWARD',
         'C_REWARD', 'C_REWARD']                                                
ERROR    | 23:47:53.028 | GameTooManyClickError: Too many click for a button:   
         C_REWARD                                                               
WARNING  | 23:47:53.064 | Saving error: ./log/error/1782920873064               
INFO     | 23:47:53.067 | 保存详细错误的日志和截图到路径:                       
INFO     | 23:47:53.069 |                                                       
         D:\Games\Onmyoji_AutoWork\minjie_OAS\OnmyojiAutoScript\log\error\178292
         0873064                                                                
WARNING  | 23:47:54.032 | Detect soul overflow, command: Orochi                 
INFO     | 23:47:54.035 | Task call: souls_tidy                                 
WARNING  | 23:47:55.069 | Game stuck, com.netease.onmyoji.wyzymnqsd_cps will be 
         restarted in 10 seconds                                                
WARNING  | 23:47:55.072 | If you are playing by hand, please stop Alas          
INFO     | 23:47:55.075 | Notifier: 1.YYS                                       
INFO     | 23:47:55.081 | Task call: restart

报错时游戏的截图/别的截图

还有别的吗？

No response

[github-actions]

Issue 概要

这是 dev 分支下 Orochi 任务的结算阶段问题:御魂副本出现“御魂达到上限”弹窗时,脚本还在按战斗奖励页逻辑持续点击,先触发 GameTooManyClickError,随后虽然识别到了 soul overflow,但异常分支又立即安排了 Restart,因此表现为卡住/重启,而不是像探索那样先把弹窗处理掉。

关键证据链

点击此处展开

观察1: issue 日志里在同一时间段先连续点击 `C_REWARD`,随后出现 `GameTooManyClickError`。 → 推论1: 问题发生在御魂副本的通用战斗结算点击阶段,而不是 `SoulsTidy` 任务本身。

观察2: tasks/Orochi/script_task.py 的 battle_wait() 在检测到 I_REWARD 后,会一直循环执行 appear_then_click(self.I_REWARD, action=C_REWARD_x, interval=1.5),没有对 I_UI_CONFIRM_SAMLL / “御魂达到上限”弹窗做前置分支处理。
→ 推论2: 一旦奖励页被“御魂达到上限”弹窗覆盖,脚本仍会继续按奖励区域随机点击。

观察3: module/device/device.py 的 click_record_check() 对同一按钮点击达到 10 次会抛出 GameTooManyClickError;日志中的点击历史正是多次 C_REWARD。
→ 推论3: 卡住的直接触发器是结算页误点保护,而不是 OCR 没识别到弹窗。

观察4: script.py 的异常分支里,exception_handler() 会调用 PostDiagnotor;tasks/Utils/post_diagnotor.py 在匹配到 I_ST_SOUL_OVERFLOW 且存在小确认按钮时,会记录 Detect soul overflow 并 task_call('SoulsTidy')。但 script.py 在同一个 except (GameStuckError, GameTooManyClickError) 分支里紧接着又执行 task_call('Restart')。
→ 推论4: 当前实现只是“异常后补救性识别溢出”,并没有阻止本次任务按异常流程重启,因此用户看到的是卡住后重启,而不是顺畅切到御魂整理。

观察5: tasks/Exploration/base.py 在多个循环里显式处理了 self.appear_then_click(self.I_UI_CONFIRM_SAMLL, interval=1)。
→ 推论5: 探索场景之所以会“自动关闭”,是因为探索流程本身把这个小确认框当作正常流程弹窗处理;御魂战斗结算没有对应分支,所以两边行为不一致。

结论: 根因不是“发现不到溢出弹窗”,而是 Orochi 结算循环没有在正常路径处理该弹窗,导致先被 C_REWARD 连点保护打断;之后虽然诊断器能识别溢出,但异常分支又立刻调度 Restart,覆盖了用户预期的“直接整理后继续”。

最终 bug 原因

• 直接结论:tasks/Orochi 的结算逻辑缺少对“御魂达到上限”弹窗的正常路径处理,导致弹窗覆盖奖励页后持续点击 C_REWARD,触发 GameTooManyClickError;异常后的溢出识别又被统一 Restart 流程覆盖。
• 证据链:日志中的 C_REWARD 连点与报错顺序,tasks/Orochi/script_task.py 的结算循环,module/device/device.py 的点击保护,tasks/Utils/post_diagnotor.py 的异常后识别,以及 tasks/Exploration/base.py 的显式弹窗处理逻辑,共同指向这一点。

给用户的建议

• 用户现在可以直接尝试的动作:短期内只能先避免在御魂副本运行时接近御魂上限,比如提前手动整理一次御魂,避免触发该弹窗。
• 是否建议升级 / 重下完整包 / 同步资源 / 重置配置:这个问题看起来不是资源缺失或配置损坏,重下完整包的收益不大。
• 是否需要等待开发者修复:是,这更像代码路径缺失,而不是单纯环境问题。
• 是否有临时绕过方案:可以在跑御魂前先清理低星御魂,或把需要长时间挂机的任务改到不会频繁触发御魂溢出的场景。

给开发者的修复方案

点击此处展开

- 代码层建议:在 `tasks/Orochi/script_task.py` 的 `battle_wait()` 奖励结算循环内,优先检测并处理 `I_UI_CONFIRM_SAMLL` / `I_ST_SOUL_OVERFLOW`,不要等到 `GameTooManyClickError` 后才走 `PostDiagnotor`。 - 行为层建议:如果确认是御魂溢出,应直接结束当前 `Orochi` 流程并切到 `SoulsTidy`,避免在 `script.py` 的异常分支里同时 `task_call('SoulsTidy')` 和 `task_call('Restart')`。可以考虑让 `exception_handler()` 返回一个状态,通知上层跳过默认重启逻辑。 - 一种稳妥修法是复用探索里的处理思路:把小确认框作为正常流程弹窗优先关闭/分流,而不是依赖异常后诊断。 - 需要补充的测试:至少补一个“奖励页出现 soul overflow 弹窗时,不会累计 `C_REWARD` 点击到保护阈值,并能正确切换到 `SoulsTidy`”的回归测试;同时验证探索与御魂两条路径行为一致。

---

分支: dev
代码范围: tasks/Orochi
相关类似 Issue: #578(相关需求背景,非同一个 bug)

Warning

Firewall blocked 2 domains

The following domains were blocked by the firewall during workflow execution:

• api.github.com
• github.com

[!TIP]
api.github.com is blocked because GitHub API access uses the built-in GitHub tools by default. Instead of adding api.github.com to network.allowed, use tools.github.mode: gh-proxy for direct pre-authenticated GitHub CLI access without requiring network access to api.github.com:

tools:
  github:
    mode: gh-proxy

See GitHub Tools for more information on gh-proxy mode.

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "api.github.com"
    - "github.com"

See Network Configuration for more information.

Generated by Issue Handle Bug for issue #1660 · 184.3 AIC · ⌖ 3.41 AIC · ⊞ 18.2K · ◷