OnmyojiAutoScript中结界突破战斗绿标生成机制解析与优化
2025-07-01 18:59:25作者:董宙帆
问题背景
在OnmyojiAutoScript项目中,用户在使用结界突破功能时发现了一个现象:只有第一场和第六场战斗会生成绿标(自动准备标志),而中间的战斗则不会生成。经过深入分析,这实际上是一个与游戏UI状态识别相关的技术问题。
技术原理分析
绿标生成条件
绿标生成的核心逻辑依赖于对游戏界面状态的准确识别。在代码中,general_battle.py文件通过检测"准备"按钮(I_PREPARE_HIGHLIGHT)的消失来判断是否可以生成绿标:
while 1:
self.screenshot()
if not self.appear(self.I_PREPARE_HIGHLIGHT):
break
状态识别机制
项目使用图像识别技术来判断当前游戏界面状态,主要依赖以下几个关键识别点:
- 好友列表图标(
I_FRIENDS) - 胜利图标(
I_WIN) - 失败图标(
I_FALSE) - 奖励图标(
I_REWARD)
这些识别点共同构成了战斗状态的判断依据。
问题根源
经过深入排查,发现导致绿标生成不稳定的原因主要有两个:
-
阵容锁定问题:当玩家锁定阵容时,准备按钮的状态会发生变化,导致识别失败。
-
UI元素变化:好友列表图标会因为新消息而变色(如从默认状态变为红色),这使得原有的识别逻辑失效。
解决方案
1. 优化状态识别逻辑
建议改进战斗状态判断机制,不再依赖易变的UI元素(如好友图标),转而使用更稳定的识别标志:
def is_in_battle(self, is_screenshot: bool = True) -> bool:
"""
优化后的战斗状态判断
"""
if is_screenshot:
self.screenshot()
# 使用更稳定的右侧聊天区域作为判断依据
if self.appear(self.I_CHAT_AREA) or \
self.appear(self.I_WIN) or \
self.appear(self.I_FALSE) or \
self.appear(self.I_REWARD):
return True
return False
2. 处理阵容锁定情况
对于阵容锁定导致的识别问题,有两种解决方案:
- 在脚本开始时自动解除阵容锁定
- 修改识别逻辑,使其能够识别锁定状态下的准备按钮
3. 增加容错机制
建议在绿标生成逻辑中加入多重验证:
- 检查战斗次数
- 验证突破券数量
- 二次确认界面状态
实施效果
经过上述优化后:
- 绿标生成稳定性显著提高,在大多数情况下能够正确生成
- 突破券耗尽时的异常行为得到修复
- 不同账号间的兼容性更好
最佳实践建议
- 环境一致性:确保测试环境和生产环境的UI设置一致
- 定期更新:随着游戏版本更新,及时调整识别参数
- 日志分析:详细记录识别过程,便于问题排查
- 多账号测试:在不同类型账号上进行充分测试
总结
OnmyojiAutoScript中的结界突破功能通过精细的UI状态识别实现自动化操作。理解其背后的识别机制和常见问题,有助于开发者更好地使用和维护这一功能。本文分析的解决方案不仅解决了绿标生成问题,也为类似UI自动化项目提供了可借鉴的思路。
对于普通用户,建议保持脚本更新,并注意游戏设置的一致性;对于开发者,可以从状态识别优化和异常处理两方面进一步提升脚本的稳定性。
登录后查看全文
热门项目推荐
相关项目推荐
GLM-5智谱 AI 正式发布 GLM-5,旨在应对复杂系统工程和长时域智能体任务。Jinja00
GLM-5-w4a8GLM-5-w4a8基于混合专家架构,专为复杂系统工程与长周期智能体任务设计。支持单/多节点部署,适配Atlas 800T A3,采用w4a8量化技术,结合vLLM推理优化,高效平衡性能与精度,助力智能应用开发Jinja00
jiuwenclawJiuwenClaw 是一款基于openJiuwen开发的智能AI Agent,它能够将大语言模型的强大能力,通过你日常使用的各类通讯应用,直接延伸至你的指尖。Python0201- QQwen3.5-397B-A17BQwen3.5 实现了重大飞跃,整合了多模态学习、架构效率、强化学习规模以及全球可访问性等方面的突破性进展,旨在为开发者和企业赋予前所未有的能力与效率。Jinja00
AtomGit城市坐标计划AtomGit 城市坐标计划开启!让开源有坐标,让城市有星火。致力于与城市合伙人共同构建并长期运营一个健康、活跃的本地开发者生态。01
awesome-zig一个关于 Zig 优秀库及资源的协作列表。Makefile00
项目优选
收起
deepin linux kernel
C
27
12
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
606
4.05 K
🔥LeetCode solutions in any programming language | 多种编程语言实现 LeetCode、《剑指 Offer(第 2 版)》、《程序员面试金典(第 6 版)》题解
Java
69
21
暂无简介
Dart
848
205
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
1.47 K
829
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
12
1
喝着茶写代码!最易用的自托管一站式代码托管平台,包含Git托管,代码审查,团队协作,软件包和CI/CD。
Go
24
0
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
923
771
🎉 基于Spring Boot、Spring Cloud & Alibaba、Vue3 & Vite、Element Plus的分布式前后端分离微服务架构权限管理系统
Vue
235
152
昇腾LLM分布式训练框架
Python
130
156