桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载导读吼吼饼铺是《绝区零》大世界中布亚斯特城区的一处纯签到型每日玩法玩家通过与「吼吼先生」交互领取每日「零食盲盒」奖励。在 ZenlessZoneZero-OneDragon绝区零一条龙项目中它被实现为hou_hou_bakery应用与刮刮卡scratch_card、卦象集录trigrams_collection共同构成「每日签到」应用家族共享每日领取次数。本文以 docs/game/screens/吼吼饼铺.md 为主线结合 hou_hou_bakery_app.py 等源码完整讲解该模块的界面状态流转、单节点自循环 OCR 分发策略、screen_info 画面锚点以及已知的建档限制帮助你理解该项目如何用「最小化的坐标锚点 最大化的 OCR 文字分发」实现一个无固定按钮布局的签到界面自动化。一、功能定位纯签到的「零食盲盒」吼吼饼铺在游戏中的表现是一台「集卡机」式的盲盒领取机器每日刷新后玩家最多可领取一次零食盲盒奖励。在 ZenlessZoneZero-OneDragon 中其应用标识定义在 hou_hou_bakery_const.py常量值含义APP_IDhou_hou_bakery应用唯一标识APP_NAME吼吼饼铺应用显示名DEFAULT_GROUPFalse默认不归入通用分组PRIORITY330调度优先级NEED_NOTIFYTrue运行完成需通知从模块性质看它是**纯签到无战斗**玩法流程中不包含任何战斗节点与刮刮卡、卦象集录同属「每日一次」的轻量日常。其运行记录 hou_hou_bakery_run_record.py 继承AppRunRecord以game_refresh_hour_offset游戏刷新时间偏移小时为基准按每日刷新管理签到状态保证同一天内不重复领取。二、入口与完整状态流转原文档给出的玩家侧入口为大世界 →Transport(布亚斯特城区, 吼吼饼铺)→interact(F)吼吼先生 → 领奖界面 → 领取盲盒 → 返回大世界。对应的应用侧节点链定义在HouHouBakeryApphou_hou_bakery_app.py中四个operation_node依次串联节点名起始标志职责关键实现传送is_start_nodeTrue传送到布亚斯特城区-吼吼饼铺调用Transport(self.ctx, 布亚斯特城区, 吼吼饼铺, wait_at_lastTrue)由 Transport 等待大世界加载完成移动交互—与吼吼先生交互打开领奖界面传送点已足够近无需移动time.sleep(1)后controller.interact(pressTrue, press_time0.2, releaseTrue)领取奖励—单节点自循环 OCR 分发node_max_retry_times20核心逻辑见下节返回大世界—领取完成后回城调用BackToNormalWorld(self.ctx)其中「移动交互」节点前的time.sleep(1)并非随意为之源码注释明确标注其为“防止交互无效”的补偿关联 issue #2405 / #2395 / #2328说明传送落点后立刻交互存在概率性失效需要短暂等待稳定后再按下 F 键交互。这属于自动化脚本处理游戏操作时序的典型经验。三、核心机制collect单节点自循环 OCR 分发吼吼饼铺领奖界面的难点在于除「盲盒」格子外其余领奖流程没有固定按钮布局各子态集卡机可领、盲盒居中开盒、卡片揭示确认、今日已领取均以动态文字呈现。因此collect节点采用单节点自循环 OCR 文字分发策略每个轮次对最新截图做 OCR按命中文字决定走哪个分支未命中任何目标文字则round_retry重试最多重试 20 次。源码中collect的分支顺序与判定条件如下「同类型奖励」领取终点调用round_by_ocr(last_screenshot, 同类型奖励)。一旦命中即视为流程终点返回round_success(status领取成功 if self.claimed else 今日已领取)。它兼容两种已签到场景今日已在吼吼饼铺签过到右下角文案「今日已领取同类型奖励」当日已在其他同类活动刮刮卡 / 卦象集录等签过到点击盲盒后弹出「今日已经完成过一次相同类型的奖励领取」。「确定 / 确认」卡片揭示依次尝试round_by_ocr_and_click匹配「确定」「确认」命中即点击并置self.claimed True返回round_wait。这是真正领到奖励的分支。「查看今天」盲盒已居中命中后盲盒已居中显示直接点击屏幕中心开盒Point(standard_width // 2, standard_height // 2)对应“点屏幕中心开盒”。「每日可领取一次」集卡机可领命中说明集卡机界面处于可领取态调用round_by_click_area(吼吼饼铺, 盲盒)点击盲盒格子点击失败则round_retry。其余黑屏过渡 / 加载round_retry(status未识别目标文本)等待下一轮截图。分支顺序为什么必须严格原文档用 ⚠️ 强调了一个关键的防误点设计「同类型奖励」分支必须置于「确定 / 确认」分支之前。原因在源码注释中写得很清楚当当日已在其他同类活动签到时点击盲盒会弹出“今日已经完成过一次相同类型的奖励领取”的提示弹窗而弹窗自带的「确认」按钮会被「确定/确认」分支误点——误点后弹窗关闭流程退回集卡机界面 → 再次点击盲盒 → 又弹出相同弹窗 → 再次误点……如此反复循环直至 20 次节点重试耗尽导致签到失败。因此先把「同类型奖励」作为终点判定命中即直接退出领取流程残留弹窗交由后续「返回大世界」节点统一处理。从实现层面看round_by_ocr/round_by_ocr_and_click/round_by_click_area这些辅助方法来自ZApplication基类zzz_application.py它们把「截屏 → OCR 识别 → 命中判定 / 坐标点击」封装为一次可复用的操作轮次使得collect能以极简代码表达完整的状态机。四、画面锚点screen_info 中的「盲盒」area吼吼饼铺的画面配置在 assets/game_data/screen_info/hou_hou_bakery.yml 中定义screen_id: hou_hou_bakeryapp_id: hou_hou_bakery。它仅注册了 1 个 area字段值area_name盲盒pc_rect[1100, 430, 1260, 570]lcs_percent0.5template_match_threshold0.7id_markfalsetext空该 area 描述的是集卡机界面中盲盒格子的固定坐标区域PC 标准分辨率下约位于屏幕中右部仅在「每日可领取一次」分支中被round_by_click_area使用。而弹窗确认、卡片揭示、今日已领取等其余状态刻意不配置 area全部交由 OCR 文字分发处理——这正是本模块“少坐标、多 OCR”的设计哲学与同类的卦象集录模块卦象集录.md形成对照后者同样以「区域-获取卦象」纯坐标 area OCR「确认」判定为主且二者共享「同类型奖励」判定文案。五、模块集成每日签到代理与调度吼吼饼铺并非独立被调度而是作为「每日签到」子应用之一运行。代理入口在 daily_signin_app.py 的DailySignInApp.run_sub_app节点根据配置读取selected_sign再通过ctx.run_context.get_application(app_idsub_app_id, ...)创建并执行对应的子应用。配置来源在 daily_signin_config.py 中property def selected_sign(self) - str: 选择签到的商店默认为 hou_hou_bakery return self.get(selected_sign, hou_hou_bakery)即daily_signin配置项的selected_sign默认值就是hou_hou_bakery用户可在界面见 daily_signin_setting_flyout.py切换为卦象集录或刮刮卡。模块自身通过 hou_hou_bakery_factory.py 的HouHouBakeryFactory完成「应用实例 运行记录」的创建遵循项目的ApplicationFactory工厂模式。六、已知限制与建档待补项原文档明确标注了该模块当前的两项待补信息均与游戏 3.0 新城区尚未探索直接相关⚠️ Transport布亚斯特城区吼吼饼铺失败3.0 新城区布亚斯特城区未探索时吼吼饼铺传送点未解锁Transport打开地图后 OCR 选不中目标传送点最终超时。这与项目 onboarding 文档中「Transport 失败 地图未探索」的判定一致需先手动跑图解锁传送点再建档截图。领奖界面各态截图缺失集卡机 / 盲盒开盒 / 卡片揭示 / 今日已领取等子态的截图像素素材source_image: 待补有待地图解锁后补齐。这一限制也解释了本 doc 的编写方式它基于“screen_info 代码”两层信息源完成而非基于完整截图实测——collect的 OCR 分发逻辑是从源码反推整理的领奖各子态的视觉快照则待探索解锁后回填。七、总结吼吼饼铺模块是 ZenlessZoneZero-OneDragon「每日签到」家族中一个极具代表性的实现样本其核心工程经验可归纳为三点纯签到应用无需战斗状态机四节点线性流转传送 → 移动交互 → 领取奖励 → 返回大世界即覆盖完整玩法固定锚点 OCR 分发的混合识别仅用 1 个「盲盒」坐标 area 处理可点击格子其余全部依赖 OCR 文字同类型奖励 / 确定 / 确认 / 查看今天 / 每日可领取一次做分支分发显著降低了对截图像素素材的依赖分支顺序即防错设计「同类型奖励」终点判定必须早于「确定/确认」否则弹窗自带的确认按钮会被误点造成“关弹窗 → 再点盲盒 → 又弹窗”的死循环直至重试耗尽。对于想要为该模块贡献截图素材或修复传送问题的开发者可参考 docs/develop/README.md 的开发文档与同目录下其他屏幕文档如 卦象集录.md、刮刮卡 相关配置的建档范式模块的完整实现入口则在 src/zzz_od/application/hou_hou_bakery/ 目录下。赞分享桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载相关推荐绝区零一条龙ZenlessZoneZero-OneDragon登录游戏流程自动化解析从打开游戏到进入大世界的完整状态机绝区零一条龙ZenlessZoneZero OneDragon登录游戏流程自动化解析从打开游戏到进入大世界的完整状态机 本篇技术指南聚焦 ZenlessZ桌面应用RPA计算机视觉AtlasOSWindows系统终极优化指南30%性能提升的免费开源方案AtlasOSWindows系统终极优化指南30%性能提升的免费开源方案 你是否曾经为Windows系统的卡顿、资源占用过高、隐私泄露风险而烦恼面对臃肿的操作系统隐私合规InternLM2.5-7B-Chat震撼发布三大核心突破重新定义开源大模型性能极限InternLM2.5 7B Chat震撼发布三大核心突破重新定义开源大模型性能极限 InternLM2.5 7B Chat作为书生·浦语大模型第2.5代开源创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ZenlessZoneZero-OneDragon 吼吼饼铺每日签到盲盒模块解析：从界面识别到 OCR 状态分发的完整实现
桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载导读吼吼饼铺是《绝区零》大世界中布亚斯特城区的一处纯签到型每日玩法玩家通过与「吼吼先生」交互领取每日「零食盲盒」奖励。在 ZenlessZoneZero-OneDragon绝区零一条龙项目中它被实现为hou_hou_bakery应用与刮刮卡scratch_card、卦象集录trigrams_collection共同构成「每日签到」应用家族共享每日领取次数。本文以 docs/game/screens/吼吼饼铺.md 为主线结合 hou_hou_bakery_app.py 等源码完整讲解该模块的界面状态流转、单节点自循环 OCR 分发策略、screen_info 画面锚点以及已知的建档限制帮助你理解该项目如何用「最小化的坐标锚点 最大化的 OCR 文字分发」实现一个无固定按钮布局的签到界面自动化。一、功能定位纯签到的「零食盲盒」吼吼饼铺在游戏中的表现是一台「集卡机」式的盲盒领取机器每日刷新后玩家最多可领取一次零食盲盒奖励。在 ZenlessZoneZero-OneDragon 中其应用标识定义在 hou_hou_bakery_const.py常量值含义APP_IDhou_hou_bakery应用唯一标识APP_NAME吼吼饼铺应用显示名DEFAULT_GROUPFalse默认不归入通用分组PRIORITY330调度优先级NEED_NOTIFYTrue运行完成需通知从模块性质看它是**纯签到无战斗**玩法流程中不包含任何战斗节点与刮刮卡、卦象集录同属「每日一次」的轻量日常。其运行记录 hou_hou_bakery_run_record.py 继承AppRunRecord以game_refresh_hour_offset游戏刷新时间偏移小时为基准按每日刷新管理签到状态保证同一天内不重复领取。二、入口与完整状态流转原文档给出的玩家侧入口为大世界 →Transport(布亚斯特城区, 吼吼饼铺)→interact(F)吼吼先生 → 领奖界面 → 领取盲盒 → 返回大世界。对应的应用侧节点链定义在HouHouBakeryApphou_hou_bakery_app.py中四个operation_node依次串联节点名起始标志职责关键实现传送is_start_nodeTrue传送到布亚斯特城区-吼吼饼铺调用Transport(self.ctx, 布亚斯特城区, 吼吼饼铺, wait_at_lastTrue)由 Transport 等待大世界加载完成移动交互—与吼吼先生交互打开领奖界面传送点已足够近无需移动time.sleep(1)后controller.interact(pressTrue, press_time0.2, releaseTrue)领取奖励—单节点自循环 OCR 分发node_max_retry_times20核心逻辑见下节返回大世界—领取完成后回城调用BackToNormalWorld(self.ctx)其中「移动交互」节点前的time.sleep(1)并非随意为之源码注释明确标注其为“防止交互无效”的补偿关联 issue #2405 / #2395 / #2328说明传送落点后立刻交互存在概率性失效需要短暂等待稳定后再按下 F 键交互。这属于自动化脚本处理游戏操作时序的典型经验。三、核心机制collect单节点自循环 OCR 分发吼吼饼铺领奖界面的难点在于除「盲盒」格子外其余领奖流程没有固定按钮布局各子态集卡机可领、盲盒居中开盒、卡片揭示确认、今日已领取均以动态文字呈现。因此collect节点采用单节点自循环 OCR 文字分发策略每个轮次对最新截图做 OCR按命中文字决定走哪个分支未命中任何目标文字则round_retry重试最多重试 20 次。源码中collect的分支顺序与判定条件如下「同类型奖励」领取终点调用round_by_ocr(last_screenshot, 同类型奖励)。一旦命中即视为流程终点返回round_success(status领取成功 if self.claimed else 今日已领取)。它兼容两种已签到场景今日已在吼吼饼铺签过到右下角文案「今日已领取同类型奖励」当日已在其他同类活动刮刮卡 / 卦象集录等签过到点击盲盒后弹出「今日已经完成过一次相同类型的奖励领取」。「确定 / 确认」卡片揭示依次尝试round_by_ocr_and_click匹配「确定」「确认」命中即点击并置self.claimed True返回round_wait。这是真正领到奖励的分支。「查看今天」盲盒已居中命中后盲盒已居中显示直接点击屏幕中心开盒Point(standard_width // 2, standard_height // 2)对应“点屏幕中心开盒”。「每日可领取一次」集卡机可领命中说明集卡机界面处于可领取态调用round_by_click_area(吼吼饼铺, 盲盒)点击盲盒格子点击失败则round_retry。其余黑屏过渡 / 加载round_retry(status未识别目标文本)等待下一轮截图。分支顺序为什么必须严格原文档用 ⚠️ 强调了一个关键的防误点设计「同类型奖励」分支必须置于「确定 / 确认」分支之前。原因在源码注释中写得很清楚当当日已在其他同类活动签到时点击盲盒会弹出“今日已经完成过一次相同类型的奖励领取”的提示弹窗而弹窗自带的「确认」按钮会被「确定/确认」分支误点——误点后弹窗关闭流程退回集卡机界面 → 再次点击盲盒 → 又弹出相同弹窗 → 再次误点……如此反复循环直至 20 次节点重试耗尽导致签到失败。因此先把「同类型奖励」作为终点判定命中即直接退出领取流程残留弹窗交由后续「返回大世界」节点统一处理。从实现层面看round_by_ocr/round_by_ocr_and_click/round_by_click_area这些辅助方法来自ZApplication基类zzz_application.py它们把「截屏 → OCR 识别 → 命中判定 / 坐标点击」封装为一次可复用的操作轮次使得collect能以极简代码表达完整的状态机。四、画面锚点screen_info 中的「盲盒」area吼吼饼铺的画面配置在 assets/game_data/screen_info/hou_hou_bakery.yml 中定义screen_id: hou_hou_bakeryapp_id: hou_hou_bakery。它仅注册了 1 个 area字段值area_name盲盒pc_rect[1100, 430, 1260, 570]lcs_percent0.5template_match_threshold0.7id_markfalsetext空该 area 描述的是集卡机界面中盲盒格子的固定坐标区域PC 标准分辨率下约位于屏幕中右部仅在「每日可领取一次」分支中被round_by_click_area使用。而弹窗确认、卡片揭示、今日已领取等其余状态刻意不配置 area全部交由 OCR 文字分发处理——这正是本模块“少坐标、多 OCR”的设计哲学与同类的卦象集录模块卦象集录.md形成对照后者同样以「区域-获取卦象」纯坐标 area OCR「确认」判定为主且二者共享「同类型奖励」判定文案。五、模块集成每日签到代理与调度吼吼饼铺并非独立被调度而是作为「每日签到」子应用之一运行。代理入口在 daily_signin_app.py 的DailySignInApp.run_sub_app节点根据配置读取selected_sign再通过ctx.run_context.get_application(app_idsub_app_id, ...)创建并执行对应的子应用。配置来源在 daily_signin_config.py 中property def selected_sign(self) - str: 选择签到的商店默认为 hou_hou_bakery return self.get(selected_sign, hou_hou_bakery)即daily_signin配置项的selected_sign默认值就是hou_hou_bakery用户可在界面见 daily_signin_setting_flyout.py切换为卦象集录或刮刮卡。模块自身通过 hou_hou_bakery_factory.py 的HouHouBakeryFactory完成「应用实例 运行记录」的创建遵循项目的ApplicationFactory工厂模式。六、已知限制与建档待补项原文档明确标注了该模块当前的两项待补信息均与游戏 3.0 新城区尚未探索直接相关⚠️ Transport布亚斯特城区吼吼饼铺失败3.0 新城区布亚斯特城区未探索时吼吼饼铺传送点未解锁Transport打开地图后 OCR 选不中目标传送点最终超时。这与项目 onboarding 文档中「Transport 失败 地图未探索」的判定一致需先手动跑图解锁传送点再建档截图。领奖界面各态截图缺失集卡机 / 盲盒开盒 / 卡片揭示 / 今日已领取等子态的截图像素素材source_image: 待补有待地图解锁后补齐。这一限制也解释了本 doc 的编写方式它基于“screen_info 代码”两层信息源完成而非基于完整截图实测——collect的 OCR 分发逻辑是从源码反推整理的领奖各子态的视觉快照则待探索解锁后回填。七、总结吼吼饼铺模块是 ZenlessZoneZero-OneDragon「每日签到」家族中一个极具代表性的实现样本其核心工程经验可归纳为三点纯签到应用无需战斗状态机四节点线性流转传送 → 移动交互 → 领取奖励 → 返回大世界即覆盖完整玩法固定锚点 OCR 分发的混合识别仅用 1 个「盲盒」坐标 area 处理可点击格子其余全部依赖 OCR 文字同类型奖励 / 确定 / 确认 / 查看今天 / 每日可领取一次做分支分发显著降低了对截图像素素材的依赖分支顺序即防错设计「同类型奖励」终点判定必须早于「确定/确认」否则弹窗自带的确认按钮会被误点造成“关弹窗 → 再点盲盒 → 又弹窗”的死循环直至重试耗尽。对于想要为该模块贡献截图素材或修复传送问题的开发者可参考 docs/develop/README.md 的开发文档与同目录下其他屏幕文档如 卦象集录.md、刮刮卡 相关配置的建档范式模块的完整实现入口则在 src/zzz_od/application/hou_hou_bakery/ 目录下。赞分享桌面应用RPA计算机视觉【免费下载链接】ZenlessZoneZero-OneDragon绝区零 一条龙 | 全自动 | 自动闪避 | 自动每日 | 自动空洞 | 支持手柄项目地址https://gitcode.com/gh_mirrors/ze/ZenlessZoneZero-OneDragon点击查看免费下载相关推荐绝区零一条龙ZenlessZoneZero-OneDragon登录游戏流程自动化解析从打开游戏到进入大世界的完整状态机绝区零一条龙ZenlessZoneZero OneDragon登录游戏流程自动化解析从打开游戏到进入大世界的完整状态机 本篇技术指南聚焦 ZenlessZ桌面应用RPA计算机视觉AtlasOSWindows系统终极优化指南30%性能提升的免费开源方案AtlasOSWindows系统终极优化指南30%性能提升的免费开源方案 你是否曾经为Windows系统的卡顿、资源占用过高、隐私泄露风险而烦恼面对臃肿的操作系统隐私合规InternLM2.5-7B-Chat震撼发布三大核心突破重新定义开源大模型性能极限InternLM2.5 7B Chat震撼发布三大核心突破重新定义开源大模型性能极限 InternLM2.5 7B Chat作为书生·浦语大模型第2.5代开源创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考