本项目在2022年1月6日达到了300star!超越fga指日可待!
本项目已经存在直接在运行fgo的手机上运行的解决方案,具体参见直接在手机上运行
人这东西还真是能力有限啊
我从短暂的人生当中学到的就是
人越是写代码,代码就越可能因意料之外的情况而出错
要成为超人的存在才行啊
所以啊,我不做人啦!JOJO!
Buy me a Saint Quartz
Scan this code to send Monero to 42CnrV9TuzE1jiS2ucGwtzN8gF6o4y9SkHsX1eZEvtiDf4QcL1NXvfZPhDu7LYStWrbsQM9UUGWnqXghManMBdqjEW5oaDY
觉得有帮助请为我star,谢谢
 |
 |
 |
 |
 |
 |
 |
 |
 |
版本记录
GitHub项目地址:https://github.com/hgjazhgj/FGO-py/
仅适用于命运-冠位指定安卓简体中文版本
<<哔哩哔哩游戏平台用户协议>>第11条第2款规定:
用户不得通过不正当的手段或其他不公平的手段使用本平台游戏、本平台服务或参与本平台活动。
用户不得干扰本平台正常地提供游戏和服务，包括但不限于：攻击、侵入本平台的网站服务器，或集中时间段内以超出正常用户登录需求的高频率登录或尝试登录服务器从而使网站服务器过载；破解、修改本平台提供的本平台游戏程序；攻击、侵入本平台游戏的服务器/游戏服务器端程序或使游戏服务器过载；制作、发布、传播、使用任何形式的妨碍游戏公平性的辅助工具或程序(包括但不限于“外挂”, “外挂”是指独立于游戏软件之外的，能够在游戏运行的同时影响游戏操作的所有程序，包括但不限于模拟用户操作、改变操作环境、修改数据等一切类型）。用户不得：利用程序的漏洞和错误(Bug)破坏游戏的正常进行或传播该漏洞或错误(Bug)；不合理地干扰或阻碍他人使用本平台所提供的游戏和服务；通过异常或者非法的方式使用本平台游戏(包括但不限于利用本平台游戏登录游戏私服)；使用异常的方法登录游戏（包括但不限于使用非本平台开发、授权或认可的第三方软件、系统登录游戏）、使用网络加速器等外挂软件或机器人程序等恶意破坏服务设施、扰乱正常服务秩序的行为；修改、翻译、注释、整理、汇编、演绎本平台游戏；利用本平台游戏或者线上游戏系统可能存在的技术缺陷或漏洞而以各种形式为自己及他人牟利（包括但不限于复制游戏虚拟物品等）或者从事其他不正当行为等。
Fgo-py不会对您的任何损失负责，包括但不限于奖励回收、账号异常、900石1宝、核弹爆炸、第三次世界大战等
由于使用本程序而导致的包括但不限于上述各项的损失本人概不负责,您下载并使用该程序即代表您已知晓使用程序可能带来的风险并愿意承担可能出现的后果
对于非16:9的屏幕,尝试使用ui中控制-全面屏适配菜单选项,详见非16:9屏幕
本项目已经存在直接在运行fgo的手机上运行的解决方案,具体参见直接在手机上运行
FGO-py一经立项,就把打破当前游戏版本下想尽办法3t速刷的固有思维,回归刚开服时克制队xjbd的环境作为自身的初心使命;从此羁绊点数和御主礼装经验不再被浪费,玩家抽卡不用考虑强度只用考虑xp;在大量90+阴间本的环境下,xjbd能带给玩家最阳间的体验;尽管本项目也可用于3t,但如果你是为了3t而来,就另请高明吧!比如FGA
速览程序功能,运行fgo.py,无需填写任何配置,去冬木大桥刷一根凶骨吧!
大部分功能说明也在ui里,只有未在ui中记载的部分被记录在本文档后续的说明内容中
(基于Qt6的)Gui大概长这样(设计模式仅供参考):
如果不便于使用图形界面,python fgo.py cli提供文本交互,这里同样拥有本项目完整的功能和说明
Cli大概长这样(在docker中运行时的截图):
这个程序能识别技能和宝具是否可以使用,指令卡颜色,克制关系,暴击率,无法行动及指令卡封印状态,敌我HP/NP等战斗中用得上或用不上的数据,可以半路接管战斗,会依据你的设置比较智能地帮你筛选助战,放技能,放宝具,吃苹果,依据特制的选卡算法选卡,一次合理设定后可以无脑通过绝大部分非高难关卡,包括主线关卡,实战7-12回合能够刷完无限池终本
除战斗功能外,还提供以下功能:抽友情池,抽无限池,领邮箱狗粮
照 着 做 应 该 不 难,尽管这看起来是一个1000行的小项目,但是你最好把它当成有10000行代码来看待
本项目的release均为智能构建,部分边缘功能不可用,仅作试用,无法保证获得技术支持
以下项目保存在fgoTeamup.ini内,只要填写就会应用于后续战斗,点击「应用更改」使之立即生效,保存需要点击按钮
- 各队伍编组的索引
- 各队伍编组的助战位置
- 各队伍编组的从者技能,包括最小使用面数/最小使用回合/目标/优先级
- 各队伍编组的从者宝具,包括最小使用面数/优先级
- 各队伍编组的御主礼装技能,包括使用面数/使用回合/目标/优先级
以下项目保存在fgoConfig.json内,更改立即生效,仅在进程退出前保存
- 是否在战败撤退时终止程序运行
- 是否在获得特殊掉落时终止程序运行
- 主窗口是否置顶
- 是否在点击关闭按钮时最小化到托盘
其他可配置项会在进程退出后丢失
我希望就算哪一天我弃坑了,本项目也要能够继续长久使用,无需定期维护,所以所有与游戏进度相关的内容都要允许用户自以非编程的方式自行制作/管理,我仅仅为此提供了一些示例和一小部分当前常用的情况
你需要事先将你期望的各种助战的样子截图为png放在fgoImage/friend下,参照fgoImage/friend/unused中的文件
被截图范围都应该可以点击来选中该好友
截图应对应1920*1080的游戏画面分辨率,建议使用gui中的检查截图按钮或cli的screenshot指令
如果fgoImage/friend目录下没有png文件,就选取好友列表中的第一个
助战截图的文件名若以包含技能和宝具信息的14个数字或占位符x结尾,则会将这些信息覆盖skillInfo中的设置
你在fgoImage/friend目录下的所有更改会在下一次选取助战时智能应用
如果你使用数据线将手机连接到电脑,那么你的手机自然会出现在设备列表中
如果没有,请参阅Google的adb文档和/或airtest文档的设备连接部分
但是很多情况下,设备不会智能出现在设备列表中,尽管程序会帮你运行connect命令,但是你还要手动输入设备序列号或ip,有些时候这些数据还不是固定的,比如模拟器启动时刷新,或是DHCP重新分配了你的ip,这就需要比较繁琐的步骤才能拿到
为此,我写了一个小魔法,在连接设备时以「/」开头的指令代替设备序列号,让你用短短几个字符便完成复杂的操作
这里需要用到的包未在requirements.txt中列出,此功能发生的问题无法获得技术支持
基于本人的实际使用场景,这里现在有以下命令
/gw手机开热点打fgo电脑连热点,获取网关ip/bs4兼容Hyper-V的BlueStacks 4国际版,从注册表读取adb端口/bs5兼容Hyper-V的BlueStacks 5国际版,从注册表读取配置文件路径,在配置文件中查找adb端口
你可以自己编写你需要的功能,如果你认为你的场景别人也会遇到,请发个issue或pr让我加进这个项目里
本项目在最初设计时就考虑到了在不同环境下运行的需求,完全前后端分离,后端一直也将继续可以在多系统下运行,基于Qt6的前端尚且存在一些局限性,在阅读本条目前,建议先验证你能在安装有Python3.9的Windows操作系统中运行本项目并用来操作运行于屏幕分辨率为1920x1080或其简单整数比缩放的安卓设备上的命运-冠位指定官方简体中文版本--这被视作使用FGO-py的门槛,我不会为此提供任何帮助--然后再根据后续内容向目标环境迁移
修改图片模板和fgoCheck.Check类
尝试使用ui中的「控制-全面屏适配-调整为16:9」功能
由于长宽比小于16:9的屏幕的游戏画面上下方仍为蓝边可以如同全面屏适配前一般使用,所以只有长宽比大于16:9的屏幕才需要此操作
在fgo中热更改分辨率会有奇怪的布局bug,所以你需要在fgo未处于运行状态时(或运行游戏后登录完成前)执行这些命令
在我的手机(OnePlus 8 Pro和RedMi 8A)上大概是这么个效果,其它手机具体表现如何我也不清楚:
这个功能就是执行了一条adb shell,单论这个shell的话是很快的,fgo的全面屏适配又跟屎一样不如没有,并且你完全可以在关闭fgo后立刻改回来不影响其他应用,你也可以在手机本地执行命令将其改回,所以我暂时不打算写全面屏适配
现已可直接使用,但是目录监控功能无效,如果你更改了助战模板等文件,需要重新运行程序
有一些软件能在安卓手机上提供Linux环境,比如AidLux(GitHub),类似于Android Subsystem for Linux(我愿称之为ASL)
官方已经提供了opencv等库,几乎避免了ARM处理器上的各种问题,故以此为基础搭建FGO-py环境,此方案已经被验证为完全可行,我现在用得很舒服
当然Qt的桌面UI多半是没有的,此时你只能使用文本交互方式运行本项目
| 按键 | 功能 |
|---|---|
| F1-F10 | 选取编队 |
| 12345 | 选卡,234指向技能的目标 |
| 678 | 宝具卡,选取剧情选项,8选取第一个关卡 |
| QWER | 御主技能列表展开/使用,WER选取剧情选项 |
| TYUIOP | 换人礼装 |
| <BackSpace> | 跳过/商店 |
| = | 无响应区域 |
| ASDFGHJKL | 从者技能,F取消,K确认 |
| ; | 刷新助战列表 |
| \ | 下一个无限池 |
| Z | 确认换人 |
| X | 对战结束时不发送好友申请 |
| B | 战败撤退 |
| N | 补充体力 |
| M | 再次进行十连召唤 |
| <Space> | 选卡/下一步/菜单 |
| NUM4-9 | 选取敌人,NUM7返回/关闭 |
关于如何提问题
在提问题之前至少花费 5 分钟来思考和准备, 才会有人花费他的 5 分钟来帮助你. "XX怎么运行不了", "XX卡住了" 这样的描述将不会得到回复. 一个有效的提问应大致包含一下信息:
- 经过什么操作后会产生这个问题
- 这个问题导致程序产生了什么现象
- 你希望正确的运行是怎么样的
- 提供 log (运行日志) 和一张截图.
- 如果程序报错, 找到 log 中提示的保存目录, 比如 Saving error: ./log/error/1595883037588, 打包为压缩包然后上传
- 使用可拼写的昵称以方便联系, 尽量不要使用空昵称或用特殊字符作为昵称
-- Alas-dev 群公告
在占用我的时间之前,先耗费自己的时间
Try to think at least 5 minutes before you want to make someone waste those 5 minutes to help you.
2021年9月24日,本人的原神智能钓鱼项目被GitHub删除了,我迫切地感到在GitHub上发布程序是不可靠的,为此,本人先建立了一个QQ群,群号932481680,作为一个FGO-py的备用发布手段,其他事项日后再议.
发现最新commit的bug请按bug_report模板建立issue,其他你想到的东西请发到discussion
qq 979449732(个人账号,加好友请注明是来问FGO-py的问题的.如果你有GitHub账户,请附上
email [email protected](相信您在小学就学过电子邮件怎么写了
现在这个项目居然已经可以从各大搜索引擎上找到,这就导致有很多halloworld都不会的小白来找我
我乐意回答一些本文档中没有提及的技术问题,但没有义务提供详细的教学.为使耳根清净的最好方法就是收费,故制定以下政策
没有标明免费的东西都不是免费的,凡是联系我的,先收10CNY我才会予以回复,算是付费咨询
这是无奈之举,卖的是本人的时间和精力,而用到知识和经验的解决具体问题另算,更详细的说明会在收费前给出,我发誓我一定会收费
什么?你想反馈项目本身的问题?那为什么不发issue?
建议您仔细阅读本readme以及ui中的说明,并尝试使用除百度以外的搜索引擎来解决您的问题,以免给您带来不必要的损失
如果你没能有提问的智慧 How To Ask Questions The Smart Way(zh_CN)而向我提问,那么你很可能被倒在垃圾场里
另外,如果您非得来骚扰我,请至少开一个小号,以保护您自己的隐私信息
- web UI
- docker
- getEnemyHPGauge
- getEnemyNP
- 新的选卡算法
- 新的技能模型
- 「确认」按键检测
- 新的用户脚本调用
- 搓丸子
- 素材掉落计数
- 配置文件/助战模板云端同步
- 聚合消息推送
- ...
更新:控制台交互式前端
启动时带上cli参数来进入文本交互,此处已提供本项目面向游戏的完整功能
在手机上运行本项目时,这可能是最优雅的方式了
优化:pr #41
我希望能用一个美观且通用的字体,可惜找不到
优化:助战选择及邮箱筛选的图像识别优化
谁能想到迦勒底午餐时光和助战选择界面顶部空白的TM_SQDIFF_NORMED只有0.4呢
v8.x标志着本项目正式拥有多前端
「拥有」不代表能用,能用不代表好用,从零现学web前端,什么时候真正写出来得看我有多么勤奋地学了
更新:命令行参数
主要是为了选择程序入口点,其他的自己去help
更新:控制台交互式前端
相比开个浏览器,可能在手机本地还是文本交互更方便,尤其是在更改队伍编制的时候
当前只是一个简单的Demo,提供了一些最最基础的功能,这个入口之后也会完善,也是要真正能用的
倒不如说文本交互式的ui早就该有了
更新:Dockerfile
我不会为配环境提供帮助,但是我觉得既然你都有docker了,那配个环境应该不是什么大事,我也乐意减轻一些程序员朋友们的负担,毕竟要是一个写了十年java从来没碰过python的同志想要跑起这个项目,恐怕还是要花上一些功夫的,所以我写了个dockerfile作为参考
但是写完我就不想发了,因为20行dockerfile有19行在搭环境,剩下的1行在启动FGO-py...也就是说这个dockerfile其实跟本项目一点关系都没有
加上不同地区适用的下载镜像还都不一样,所以你多半还得根据自己的情况修改,那么请问你如何知道怎么改呢?最终还是得学python
优化:调整了部分点按位置
v7.9.0的按键映射调整使在有大量任务奖励弹窗时点在了任务奖励弹窗上而无效,亦使v7.6.5的彩箱子检测丧失了优势,故在战斗阶段仍采用右上角点击跳过
更新:技能后点击屏幕
这个功能国服还没有上线,但是本次游戏更新确实有一些未在公告中展示的新增内容(也可能是我搞错了),所以这样前向兼容的小功能就先写了
更改:调整了三色指令卡的模板以应对新版游戏ui更改
阿b你屁事没有为啥要改这个?改后变好看了吗?咋不敢改回英文?ん?
更新:技能优先级相关调整
先前考虑到技能总数,优先级在ui中的表示范围设定为0-255的十六进制值,但是在助战模板文件名中的正则只匹配了字符0-9
现在对ui和助战模板文件名做出调整,使之只能是十六进制表示的0-15
更新:特殊掉落细分为彩箱子和羁绊礼装
羁绊礼装就会显示羁绊礼装,不会看见是特殊掉落以为是掉活动礼装了兴冲冲看一眼发现是羁绊礼装
新礼装通常是羁绊礼装和活动礼装,羁绊礼装在战利品结算前弹出展示界面,活动礼装在战利品结算后弹出展示界面并且肯定对应了彩箱子,当两者同时出现时,彩箱子会先在战斗中被识别到,但是羁绊礼装会抢先判定
这是为了彩箱子计数准备的,「彩箱子」术语仅在文档和代码中使用,ui中的「特殊掉落」现在特指彩箱子
更新:彩箱子计数
先前是掉了一张礼装就停,现在可以掉了若干张再停
该数据不会写入配置文件,会在进程退出时丢失,也就是说,你需要每次启动都设置一次这个计数
「预约终止」的战斗计数停止对应于单次战斗类调用,而这个「彩箱子计数」是贯穿整个进程的
bugfix:消息推送可变参数少打了一个星号
bugfix:优先级越小越优先
明天今天无限池,在全面测试本项目动能时居然发现了这么个惊天大bug
在v7.6.0之前的版本仅有宝具有优先级,是越大越优先的,v7.6.0版本加入了技能的优先级,彼时代码和本文档中写的是越大越优先,ui中写的却是越小越优先,现统一为越小越优先
越小越优先,使得在优先级是自然数列的情况下可以代表「这是第一个放的技能,那是第二个放的技能」
更新:BlueStacks 5 with hyper-V的快速连接支持
更新:ServerChann推送
填写fgoConfig.json中的notify相关项
早上醒来不下床就能知道脚本有没有报错,没报错就继续睡
这个功能还非常简陋,就几行代码,之后的webUI中此功能会取代当前的windows系统消息,届时可能会加入其他渠道(问就是从GenshinHelper里抄)
这新功能不比死抠战斗算法有用多了
更新:调整了按键映射
大版本7.x.x也要接近尾声了...
更新:兼容非windows电脑
你不再需要手动替换一些代码
更新:战败撤退
灵脉石使得战败界面布局改变了
另:docker上的方案已经确认,待webUI完成后一并放出
更新:断线重连
如果要我详细地对代码进行说明就会像本次更新日志一样2行代码10行文档,本项目的诸多环节都是经过细致考虑和反复调整的,所以别再说我代码没注释了
bugfix:调整特殊掉落彩箱子的判定
先前在检测到「>>获得的战利品」判定战斗结束后在战利品展示页面检测特殊掉落的彩箱子,但是任务奖励的弹窗可能将其遮挡,可能导致漏判特殊掉落
我真傻,真的,我光考虑到奖励弹框可能遮挡「>>获得的战利品」所以只匹配了「>>获得的占」(v7.3.1),却不知道奖励弹框也会遮挡彩箱子
为完成此更改扩大此识别范围等待弹窗消失是得不偿失的,毕竟奖励弹框可能多到下一局开始后retry getStage(v4.9.10),现在会在自动机主循环中检测彩箱子,检测到就set flag,由于从敌人死亡掉落彩箱子到网络连接完成弹出任务进度框应该有足够的时间,而且会掉礼装的关底boss通常血量最高会被优先攻击选取(v6.4.0)而最先死亡,不会造成漏判,但是对代码造成了侵入性修改
更改:调整了「无法行动」的模板
这个模板很久很久以前(v2.10.2)就有了,当时研究发现「眩晕/魅惑/石化」在指令卡上反馈的图标和文字是一样的,就把图标也截进去了
但是现在发现「睡眠」状态有自己的图标,文字还是「无法行动」
「猪化」还没遇到过,不过如果遇到了然后发现文字也不一样的话,估计也不会为了这么一个东西加判定,除非在free中出现
更新:添加了各职阶金卡的助战模板
应对加成按职阶区分的活动,比如我打掉「炫彩锐齿」(三角形的那个)的free就可以启用枪/术/月/降的助战模板来贪到最高加成
更新:不使用「援护请求」
今年情人节v4.9.9版本更新对「进入战斗前选择使用道具」的场景进行了适配,友情巧克力自然是能用就用,但是这个活动里打free的时候(也是需要脚本选择使用道具的主要场景)是应该不使用用这个东西的
然后,连续出击的地方也加了个「使用援护请求并连续出击」的选项,原先的「不使用援护请求并连续出击」右移了,现使用「是否连续进行同一关卡?」进行识别,同时也改变了点按的位置
bugfix:issue #37
rnm我群里有内鬼...
换了个入群问题
另外,qq通过扫描二维码加群时可能会出现不用回答入群问题就能加入的bug,故移除了了群二维码图片
注意:本版本进行了较大幅度的更新,源码有大量更改,尽管已经经过测试,但仍不能保证相对较少的bug
注意:本次更新后fgoTeamup.ini配置文件与先前的不兼容
如果你想保留先前的配置文件,可自行按正则\[\[(\d,\d,\d)\],\[(\d,\d,\d)\],\[((\d,){2,3}\d)\]\]匹配替换为[[$1,7],[$2,7],[$3,7]]
优化:Check截图的文件名改为截图的时间而非保存的时间
更新:为所有技能添加了优先级,优先级数值越大,对应技能越先被施放
这个优先级是打通了从者技能和御主技能的
在优先级相同时,在ui中写在前面的先放
更改:每放一个技能就会刷新所有技能的冷却状态
以上改动可以解决包括但不限于以下问题:1.拉二可以先加强化成功率再放皇权;2.Kingprotea可以先解除增殖并减少一技能cd然后再附加新的增殖;3.先用阿特拉斯院制服将技能CD减完再使用那些技能;4.精确指定涉及换人操作时的技能顺序;5.先给雪山樱充能再开三技能
更新:将所有的数字输入小框改为了SpinBox
这使得你可以完全使用鼠标移动和滚轮滚动来改变数值
也就是说,本项目的ui现在既可以仅用键盘操控,又可以仅用鼠标操控,并且两者都非常方便,同时布局也为触摸进行过优化,搭配屏幕键盘亦可顺利使用
更改:调整选卡算法
减少了首红加成,减少了克制和被克制的倍率,减少了brave chain的权重,增加了color chain的权重
更新:在战斗中识别助战位置
解决了数据不同步问题,同时避免原先应用助战信息对配置的破坏
结合近期版本的更改,现在「完成战斗」按钮可以完全被「肝」和「预约终止」组合替代
bugfix:正确检测羁绊礼装的特殊掉落
v7.3.0中将获得战利品界面作为战斗结束标志,这导致羁绊礼装会在战斗结束前弹框
更新:根据带彩虹的箱子判断特殊掉落
移除了掉落截图的模板和相关代码
本功能使用的图片模板来源于网络
其实原来的功能是有做「刷到若干个某素材后停止脚本」的想法的
更改:预约终止计数由「战斗开始计数」改为「战斗结束计数」
需要被设置的值通常比原来增大了1,也就是说,要是你希望这场战斗打完就停,就在对话框中输入1(原先是0)
为此,默认值和最小值也被改成1,所以在这种情况下,实际上还是只需要点确定就行
更新:Main可以在战斗中途调用了
这是为短线/闪退等异常原因导致脚本中断后的补救,使之能够从中断处继续运行而不至于先调用Battle等待战斗完成后再调用Main
你不应该在((没有从主界面进入战斗过||在上次战斗后切换了关卡)&&会继续战斗&&助战模板有技能信息)的情况下在战斗中途调用Main,不然由于没有获取过助战位置,会导致助战信息被放到错误的地方
这个地方得想个办法解决一下,我不想粗暴地加个校验禁止这样的情况发生,因为我的多数场景下助战模板时没有技能信息的
现在的想法是在Battle中增加额外的friendInfo,并识别当前从者是否为助战
bugfix:修复了7.4.0误删的主窗口焦点策略导致的按键映射失效
注意:此版本未经全面测试并且可能包含严重bug!
几个小时后原神新版本新地图,要是现在不commit就得拖好几天到时候活动都关了,所以直接进行一个测试的跳过
新增:修改了基础的图像识别算法,模板同时被用作蒙版,如果一个像素三通道都不大于1就会被忽略
这个更改可能导致目前已经存在的识别参数需要些许调整
这个更改允许你制作非矩形/非连通的助战模板,参考fgoImage/friend下新增的图片
新增:选卡时考虑暴击
新活动的逆克制加成有点顶,所以又优化了一波战斗算法
这里其实拿边缘去匹配效果会好得多,但是懒
优化:缩小了一些图片模板,大幅节约你的硬盘
优化(?):调整了指令卡分组的阈值,具体情况有待进一步观察
优化:降低了红卡/color chain/extra attack的权重
先前color 指令卡完全按照伤害赋权为1.5/1.0/0.8,忽略了np以及暴击性能,而将这些附加价值完全安排在了color chain中
同时,extra attack难以得到A类buff,相较其他位置并没有那么高的价值,而且会花费大量动画时间
现在这样的改动,在暴击的影响下,使二三位更容易出现蓝绿卡,使color chain更有可能优于brave chain
新增了邪马台国活动礼装的掉落模板
bugfix:修复了由短路运算导致的在选择了与编队中成员不同的助战上场后的下一回合仍被判定死亡的问题
优化:略微下移了\键的映射位置,尽可能避免其呼出状态栏
bug修复:在选取了与编队中成员完全相同的助战时正确判定死亡
助战的头上会带一个「+助战」的标签,由此判定.这个标签也可能写的是「+临时加入」,但是临时加入的从者不会是助战,助战的头上一定写着助战,一个队伍中不会出现同一个正式加入和临时加入的队员,故无需判定
更新:自动识别助战位置
移除了助战位置的配置信息,这导致在通过继续战斗进入战斗时会使用本次程序运行以来上一次从关卡列表进入战斗时获取的助战位置,可能会有数据一致性问题
新增了卑弥呼的助战模板
恢复了自动打包
新增:刷新编队信息
更改编队文件后可以直接刷新不用重启脚本
同时扩大了编队下拉列表最大大小
我8月24日给airtest提的issue终于在9月30日给出了一个修复,一看release,好家伙,这一个版本就为修我这一个issue,然后仔细看对应的commit吧,还真就用我说的wm size来获取分辨率了!请大家把排面打在discussion里!
其实吧,这样的改动并说不上完全正确,比如本项目的16:9适配会强行更改手机分辨率,此时wm size第一行为原始分辨率,第二行为调整过后的分辨率,此时getPhysicalInfo只拿了第一行,到此为止都是正确的,这些数据也能使功能正确运转,但是get_current_resolution就是调用的getPhysicalInfo,也就是说这个接口返回的数据或许可以说是「名不副实」的,当然我现在使用的get_render_resolution是没问题的,希望airtest别哪天脑抽了把这些东西给破坏了
其实这些接口一开始就摆在那里,期望实现的功能都没变过,只不过有那么一点「小小的」bug
我觉得让用户通过版本限制来规避bug是不合适的,所以移除了requirements中的版本限制
此外,我移回了自动打包的yml,具体是否启用还在思考,反正摆一个在那里呢就谁都能看着来打包了
优化:按键映射随设备切换关闭
避免打开按键映射后切换设备而触摸方法未初始化导致无效输入
其实还是应该放弃这个懒加载,毕竟触摸初始化强行点击一个(0,0)不是什么好事
经过一晚上的复盘,我认为原神钓鱼项目被删除的原因是我写了英文的readme而被分析了,据此,本人对本readme中的一些词语进行了替换
更新:战斗逻辑部分不出现具体坐标,完全解耦
目前仅剩下swipe仍需具体坐标,但是这个只要滑动一下就行了,具体点哪里无关紧要
这是为之后全面屏适配做的准备,这样只要更改按键映射的坐标和Check的公有方法参数就行了
真正的全面屏适配相关的东西被放在fgo169.py中,我正在研读FGA的源码,自愧不如,一点一点看着写吧
优化:领狗粮能够领完最后一个页面
奇人共赏更新了
优化:避免任务奖励弹窗影响回合结束判断
优化:筛选邮箱时,等领取完毕后再进行下一次领取,避免网络卡顿造成的误领
优化:调整了检测列表滚动到底的判断方式
优化:缩小了检测没有好友的模板
更新:判断战斗结束
由于7.2.0中会在回合间点按屏幕,所以现在检测战斗胜利只需要看战利品框
更新:specialDrop除了新物品以外还可以是fgoImage/dropFilter下的png
会对战利品框进行识别,图片制造方式参考助战模板
要说掉活动礼装就短信通知什么的我觉得不至于
更新:日志保存到文件
优化:日志显示算法
另:16:9调整的功能有诸多限制,请自行摸索
更新:全面屏适配时代的邮箱筛选
重新截取了模板图片,算法未变
奇人共赏更新了
90+混合本客观地具有更高的难度,请合理安排队伍成员,仔细配置技能参数
更新:调整了抽奖池相关的识别图像和点按位置
原先是「重置比赛奖品」,现在是「重置战士的报酬」,形状也不一样,于是直接匹配「0/300」中的「0/」
更新:在每回合开始前点击屏幕,以跳过三面特写镜头
另:筛选狗粮的功能好像也有一点小问题,但是当前游戏内可以对邮箱内物品的种类和稀有度进行筛选,所以还能凑合着用,暂时未做更改
游戏副本难度的增大给了我些许压力,现在除了已在计划中的getEnemyNp,还想做一个getCriticalRate识别暴击星数量
getEnemyNp需要新的图像识别方法,getCriticalRate需要新的ocr模型和参数,都不见得是一行代码能搞定的
妹的,airtst那个bug半天不修,8月24号提的issue到现在连个回复都没有,连个屁都不会放
爷直接回滚到1.2.0重新打包,等爷考完研tmd一定要砍了这该死的airtest
随便去alas上抄个aScreencap或uiautomator2,再不济直接adb都行
好家伙要是真的用回adb了拿怕不是回到v2.7.0时代...
更新:全面屏适配
问:什么是「全面屏适配」?
答:让游戏画面适应程序,而不是让程序迁就游戏画面
全面屏适配:调整先前遗漏的isListEnd
受影响的行为是选择助战和清理邮箱
全面屏适配,但又没有适配
更新:在16:9分辨率的屏幕下调整了新ui的一些识别位置
我曾经说v5.x是全面屏适配的版本,但是破坏数学上的偏序关系总会带来一些困扰,所以直接启用版本号5,直接编号为7,这样也能显得这个项目经历了更多更新
拆分,解耦,桥接,单例
起先这个项目的源码是朝着「紧凑轻量」的目标走的,核心代码就一个ui一个算法,但是随着功能增加,代码即使极限minimize也有个几百行了,所以还是拆分到数个文件里
最近我突然兴起想做个东西,本来调个库就完事的,结果发现相关领域开源的还是空白!根本没库可用!
从零翻msdn估计得几个月才写得出来,等那个东西写完估计就得对本程序的结构做一些变更,因此先重构代码方便后续更改
还是先想想全面屏适配怎么写吧
最近fgo国服五周年过后,fgo的智能化案例越来越多,门槛也越来越低,相关的创作一夜之间井喷
这究竟是好时代的来临,还是坏时代的前兆?
无论如何,本项目还是保持低调,闷声发大财,小心驶得万年船
我也在考虑删除所有的release
9月1日原神开2.1版本,所以要是我现在不发这个版本就又得咕好久
更新:添加托盘图标的「退出」和「强制退出」菜单,移除主窗口的「退出」菜单选项,以及其他一些ui上的小优化
关闭窗口,然后QApplication发现lastWindowClosed而退出,而不是退出QApplication时关闭所有窗口,避免窗口关闭迟滞
更新:配置同步管理器
随着和未来可能的可配置项增加,写了一个配置同步管理器,用以使config文件/ui部件/<可选的>回调函数保持一致
该配置管理器是线程不安全的,仅在程序启动和退出时会读写文件
bug修复:兜住设备连接错误
先前的版本又tm手抖了
优化:isHouguReady花费的时间更少了(-70%)
这是v4.8.0的编码水平不到位
优化:调整了logger的风格
另:上个版本的更新可能在一些设备上是反向更新,建议使用airtest<=1.2.0
我又来给airtest擦屁股了...参见AirtestProject/Airtest#960
这个airtest 1.2.2是5天前发布的,此间的所有release都含有该问题,已被移除
同样是getPhysicalDisplayInfo的问题,采取了与v4.4.0中相同的修复手段,同样的效果,现在仅需一行代码!
更新:智能选择每面血量最高的敌人,弃用「优先攻击」设定
更新:增加了一些可保存的配置项,置于fgoConfig.json内
更新:添加托盘图标,可设置关闭到托盘
在启用「关闭到托盘」时,通过「文件」菜单中的「退出」来关闭进程
更新:战斗完成时通知,取代原先的beep
系统通知受勿扰与专注等系统设置控制
做这个托盘图标是考虑到有「老板键」的需求,但是就算程序已经最小化到托盘战斗也不会暂停,甚至会在完成时弹出系统通知
什么tmd叫惊喜?这tmd就叫惊喜!
优化:各对话框风格统一,并且使ui文件体积更小了
我挺想搞一个深色风格的,就想着是和Windows深色主题一样,可惜Qt里没有现成的能用,自己写调色板样式表也太顶了...
叔叔我啊,最讨厌做前端了
bugfix:issue #24
我就说好像有些时候加载了明明没有写过的配置,现在总算是去检查了一下
优化:调整了选卡算法,使得color chain--尤其是Quick Chain--不那么容易出现了,应该
更新:手写了一个轻量级的ocr,以识别我方的HP/NP和敌方的HP
这个功能已经写好有差不多半个月了,期间一直在各种关卡中测试准确度并优化算法,现在差不多能堪一用了,准确率应该不低于98%,如果你发现某个识别出了偏差,请立刻保存截图并提交issue(复制fgoCore.fuse.save()然后选择控制-Execute菜单选项能够保存最近的若干张截图),我会依此调整算法
该功能还需进一步测试,保证鲁棒性后才能真正用于战斗策略,比如智能选取优先攻击对象
fgo的这些数字显示啊,理论上来说应该是白色字体黑色描边,但是实际上就是会带一些很恶心的彩色--去除彩色无效,解析度也很低--腐蚀滤波一下字没了,边缘也是模糊的--二值化阈值不定轮廓毛刺也很多,再加上杂乱无章的背景--找不到完全有效的去背景算法,实在是条件极其恶劣,以至于就算我做好字形提取后再送入当前比较nb的几个ocr库里面正确率还是惨不忍睹...所以我只能自己写
此外,敌方的数字要比我方的大1-2px,如果不是DW的程序员太垃圾的话,就只剩下「暖色背景腐蚀内容」这种设计方面的解释了,但是:
bugfix:getCardColor/getCardResist/getCardGroup的指令卡裁剪范围调整
我曾经天真的认为五张指令卡是等间距排列的,在之前的版本中就算裁切出了偏差也毕竟是红色匹配红色,总比红色匹配绿色差异小,但是之前添加的getCardGroup里我把阈值卡得很死,所以发现了这个问题,五张指令卡的坐标是[76,460,842,1230,1620],差分为[384,382,388,390]
所以,真的是DW程序员太垃圾...
优化:硬改了一波ui文件,优化了一些显示效果
另:先前提到的那个在B站发布网盘更新的3t程序增加了一个根据编队界面进行从者识别的功能用于智能加载技能图标的特性,我在想要不要抄一个过来,这样的话或许真就不需要任何配置只要点开始按钮就行了...但是这会增加很多数据,并且需要跟着游戏进度更新,同时重写UI以及配置管理
但是如果真的做了这个功能那么我是不是要向Fgo Teamup一样再对每个活动图都建立配置呢?这样的话感觉就有点悖离项目的设计初衷了...要做估计得另外开个FGO-teamSolve来求解编队
不说了直接import tensorflow as tf开启二刺螈人脸识别快乐炼丹
更新:刚出了c呆羁绊暂时还没满,就把换人UI加回来了,并添加了相关代码
由于每个御主技能每场战斗仅会使用一次,所以默认换上来从者的技能都是可用的,不会再次截图识别
技能的第3个参数必须是当前在场的成员,第4个参数必须是后备队员,如果不可交换就会关闭交换对话框
注意v4.0.0版本中的换人是以换人发动时现存的从者进行编号,而现在是以进入战斗时的编队进行编号
打个比方,「陈宫|caber|cba|孔明|司马懿|梅林」的队伍第一面第一回合陈宫发射caber后孔明上场,第二面第一回合交换孔明和司马懿,在先前的版本中技能参数可以是(2,1,2,4)或(2,1,4,2),而现在必须为(2,1,4,5)
上回说到,八月份以来本项目star突然多了一些,我算是搞明白怎么回事了
8月3日B站上有个人写了个程序发了个视频大约3.5w播放,但是他不会用git,所以仅仅以网盘的方式分发了源码和可执行文件,因而如果其视频的观众试图搜索FGO程序,尤其是在GitHub上搜索,就有相当高的可能性看到本项目
尽管这样能够获得很多播放/三连/关注与些许充电,但我不得不说这个老哥胆子是真的大,轻易就做到了我不敢做的事,敢在叔叔的地盘上这么搞,希望他别被查水表
以此为鉴,在LICENSE中加入了不允许将本项目相关内容发送到bilibili的条款
添加workflow来在release时智能打包
每当我添加了一个以v开头的tag就会构建项目一次并release
打包方式跟自己电脑上打包是一样的,但我也不知道这样打包出来的东西能不能在全新的环境中使用,如果使用遇到问题,请提交issue,但是以本人的水平多半解决不了
bugfix:避免无法行动三连
如果首红无法行动,后续指令卡仍可以得到首红加成,故将判断无法行动从判断颜色接口分离
如果有无法行动便置Color Chain和Brave Chain评分分量为0
这破游戏也五周年了...
bugfix:issue #21
更新:指令卡分组,可以打出Brave Chain
同时更新了选卡函数,基本根据相对伤害排序,因此不能合理评判Arts Chain的价值,并且会较为频繁地打出Brave Chain,造成伤害溢出
所以在伤害排序的基础上对Color chain的权重做了增加,之后还要考虑是否需要放弃Brave Chain特意调换指令卡顺序尽量避免鞭尸
至此,选卡又成了本项目中最长的一行
最近几天这个项目忽然多了好多star,谁能告诉我发生了什么事
6.3.x版本计划实现那些@returnOnError修饰的方法
更新:选卡考虑克制关系,以应对多职阶混合本,或是提高速刷后补刀效率
但是当前的选卡仍然不是最优,具体的优化要在getCardGroup实现Brave Chain识别之后再做
另外,我觉得本项目中的一些英文有点问题,有些从翻译软件得来的要改,日服写英文的要用日服的,fate专有的要用日文,其他的要去美服找
打个比方,克制/被克制在日服和国服强制汉化前是weak/resist,但是在美服变成了effective/resist
更新:重构部分代码,使之具有能在错误发生时不丢失当前战斗状态的特性
随着90+本逐渐出现,战斗算法需要进一步提升,首先要实现的是更多战斗参数的获取
我本人的精力显然不够,既没有办法更新各个从者的技能信息,更没有精力每出一个活动就对90+本写一个关卡配置,所以只能实时获取当前场景的信息经验主义贪心一下,仍然没法知道技能的实际效果,或是下一面会有什么敌人
另外,尽管airtest修复了内存泄漏的问题,但是僵尸线程好像仍然存在,当连接对象被GC后,相关的各个线程均未kill
对于一些模拟器,airtest加载截图方式时会导致模拟器黑屏,截图不会报错但就是黑色,这就很tm操蛋,所以还是指定了截图方法
注意:本更新的兼容性未经充分验证
更新:试图获取当前连接是否仍然可用,以替代先前的是否曾经建立过连接,并在从暂停中恢复程序执行时添加判断
以避免出去接个电话回来继续执行时战斗状态丢失
很遗憾airtest并没有现成可用的接口,最靠谱的方法是像初始化时那样看看触摸截图是否报错,但是这样开销太大
现在是判断某个线程is_alive或者shell进程poll来获取,但是在无线连接时有大约或至少10s的滞后
总之这里说有效不一定真有效,但是这里说无效必定无效,在主线程上的调用还是得包一层try
反正比什么都没有要好,之后会看看有没有更好的方法,比如直接通过tcp forward去ping手机上的server,同时重构本程序的异常处理逻辑
说实话,反正出现这种连接断开的异常肯定是要人工处理的,谁知道具体出错时是wifi断开/线没插紧/模拟器闪退还是什么别的情况呢,总不能无限尝试重连吧...所以花太多精力在异常处理上就有点本末倒置,相关特性也很有可能在未来直接全部砍掉
更新:适配airtest 1.2.0
上回说到,初始化时touch_proxy会点击(0,0)作为初始化的最后一步,随后就是用户点击操作,这导致几乎同时点击了屏幕的两个地方,在fgo中,后一个点击很可能就不被响应了...
为此,还是跟原来一样,在建立连接时完成触摸的初始化
更新:既然又要动到具体实现了,我就把我自己的swipe改了改加回去了
更新:在屏幕方向发生改变时智能更新,移除了手动更新选项
更新:适配airtest 1.2.0,具体参见https://github.com/AirtestProject/Airtest/releases/tag/v1.2.0
连接手机时无需设置参数的更新让人迷惑,方便使用的初衷挺好,也切实加强了本程序的兼容性,但实际上就是把之前的屎山包了一层漂亮的外壳,并且留下了一个巨大的隐患:touch_proxy会试图在(0,0)处点击一次看有没有exception来判断当前touch_method是否可用.不过还好点不到fgo左上角的返回按钮,应该不会影响全面屏适配后的表现,如果之后发现这个点击产生了影响就还是得换回先前手动指定的样子
v6.1.0版本发现的「严重的内存泄漏与僵尸线程问题」被修复了
更新:移除了我自己编写的swipe
更新:对于游戏画面不在屏幕中央的设备,在屏幕旋转后可以在「控制」菜单中刷新方向而无需重新建立连接
更新:<无>
由于本人经常处于手机开热点打fgo笔记本连热点挂程序的情况,故在选取设备时输入某四个特殊字母能够获取并快速连接到网关ip,免得手动开终端ipconfig复制黏贴
最近才想起来要加这么一个功能省下每次开机后的十秒时间,这个功能说实话打算藏在我自己的分支里不发布的,毕竟并不是所有人都在这个场景下使用,更不可能所有人的无线网络适配器都叫一个名字,所以这并不作为一个正式的特性存在,仅仅作为一个类似彩蛋的东西,在代码里动了一点小手脚,如果恰好你也能用上那就凑合着用吧.这个功能与fgo没有关系,不会正儿八经的照着软件开发的样子做
注意:调整了一些按键并未经充分测试
高考第一个出考场记得让mhy策划加强刻晴
更改:适配Qt更新,在requirements.txt中限制了版本号
Qt6还处于快速迭代阶段,总是会有杂七杂八的更改
但是这种WindowFlags->WindowType,StandardButtons->StandardButton,Alignment->AlignmentFlag这种就有点搞人心态了...
更新:「指令卡封印」导致的行动不能
F/R联动的最后一个奖励关卡新增的东西
更改:移除了「重新建立连接」选项
现在直接更改到当前设备就会重新建立连接
这「移动至后台」的仙鹤小姐真是拉满了yls的恶意...本项目不打算为其机制提供额外支持
还有一些细节优化
更新:更改了连接设备的UI,现在你可以直接连接到远程设备,只需要在原先的选择设备对话框里输入对应地址
同时,现在连接上的设备会显示出来
更改:不WrapLongRows
你uic有bug我就不用咯
另:我发现airtest有严重的内存泄漏与僵尸线程问题,请尽量不要异常断开连接或是切换设备,如果你发现本项目异常占用系统资源,目前只能关闭整个进程重开
我近期都会很忙,还入了Chia的坑,没时间给网易擦屁股
优化:调整了检测卡色的算法
之前为了方便就求个平均看看RGB哪个大,并取得了不错的效果
但是有些从者指令卡--比如Kingprotea第二再临--是整块的绿色,在指令卡上下运动至接近最低点时就会显著影响分类结果
尽管就算分类错误也不会导致程序运行中断,我还是换用了靠谱的方法,毕竟这个程序本体已经基本完善了
更新:为日志输出上色
你得在支持颜色转义的终端里(比如VisualStudioCode终端和WindowsTerminal)运行才能看见色彩,否则是原始转义序列
我在考虑是否换用Loguru
bug修复:在无法使用三划令咒复活时正确检测战斗撤退
印象中当你没有圣晶石时点击使用圣晶石复活按钮会跳至购买页面,所以不用考虑
bug修复:窗口置顶现在能够正确动作
又是这该死的enum,windowFlags()现在运行就报错,相关标志在python里甚至不能转成int,估计是int32放不下38个flag溢出了...
反观只有8个成员的Qt.KeyboardModifiers.KeypadModifier是能够正确参与各种运算的
更改:移除了PowershellHere
bug修复:将上次遗漏的各Flag由enum改为enum class
问:为什么没有v5.x版本?
答:那是留给全面屏适配用的版本号
问:为什么要这样安排
答:因为6代表Qt6
没错,这个项目的UI现在基于Qt6
在使用pyuic6编译ui文件之后,还需要将
self.LAYOUT_INFO.setRowWrapPolicy(QtWidgets.QFormLayout.WrapLongRows)
改为
self.LAYOUT_INFO.setRowWrapPolicy(QtWidgets.QFormLayout.RowWrapPolicy.WrapLongRows)
在Qt6中,各Flag由enum变为了enum class,但是部分选项uic里没改过来,例如xml中Qt::AlignRight会被正确编译为QtCore.Qt.Alignment.AlignRight而QFormLayout::WrapLongRows被遗漏了
由于缩放策略的改变,Qt5时缩放不正确的bug被修复了,现在在不同缩放分辨率的屏幕之间拖动窗口不会导致布局改变,因此先前的UI设计现在会看起来有点不舒服,这会在之后的更新中逐步调整
优化:战斗结束后将苹果输入清零等小细节优化
更新license
bug修复:检查截图不会因已熔断的熔断器和其他错误导致进程退出
正在研究即将到来的fgo全面屏适配,被yls这狗屁不通的界面整糊涂了
我有三条路可以走:1.限定16:9使用;2.舍弃当前的按键映射适配全面屏;3.在每个设备初次连接时启动按键定位引导
如果选择第二条道路,应该怎样重新设计本项目的结构?
重构,好起来了
更新:可设置战斗失败或特殊掉落时中断
更改:fgoConfig.ini更名为fgoTeamup.ini
原文件名日后可能用来存放其他配置
更新:针对游戏活动更新进行适配
在没有友情巧克力时正常进入战斗
优化:避免特殊掉落导致卡顿,包括活动礼装/点数奖励/羁绊礼装等
bug修复:等待任务奖励弹窗消失后再进行回合数识别 issue #18
我设计Check类的时候想的是一个Check对应一张截图,其中的各方法取得图片中的一些信息
isHouguReady是个例外,由于np条忽明忽暗,可能需要两张截图,但是最多也就两张
但是这次出现了「反复截图直到有结果」的方法,那么之后是不是除了isBegin之外还得来一个waitForBegin方法呢?
很烦,晚上又喝多了,打原神连个闪避都按不利索,等以后再慢慢想,现在能跑就行,也没多测试
bug修复:熔断器保存截图时的访问错误
更新:针对游戏活动更新进行适配
情人节活动新增向好友赠送友情巧克力的剩余次数提示导致选取助战界面判定位置下移20px
适配向好友赠送巧克力特性(虽然我既不缺友情点,也不缺绿方块),需要关闭使用巧克力的确认提示
更新:熔断器熔断时保存最近的几次截图
更新:增加requirements.txt,修订readme
(更新||bug修复)&&优化:延时调整
自v4.9.2游戏版本更新后出现了数次战斗卡顿的现象,检查发现从判定回合开始到技能按钮有响应需要的时间好像比原来长了,从者头像完全显示需要更长时间,对着几个录屏数帧数半天发现16/60s就已经达到正常运行标准了,很奇怪
如果你想完全避免这一问题,使用不带指向的技能
在某技能释放后实际判定回合开始前包括御主技能在内的其他技能按钮就有响应,调整了相关代码使得放技能更快了
更改:删除对airtest.core.android.adb.ADB.getPhysicalDisplayInfo相关的bugfix
参见v4.4.0日志
airtest没有作出任何更改,但是我的手机系统更新为adb shell dumpsys display中没有mPhysicalDisplayInfo字段,使得getPhysicalDisplayInfo换用其他方法获取
新增:在ui中执行python代码
仅用于发现了一个罕见的难以复现的问题而没开调试没有控制台时的最后补救措施,你得先完全理解这个程序的工作细节才能使用这个功能
bug修复:修改了键盘映射与主窗口的焦点策略,使相关交互符合逻辑
bug修复:在羁绊等级上升时正确判定战斗结束
在v4.8.1中曾对此问题进行过修复,现发现存在(幕间物语开放)(从者资料更新)(追加语音)三种提示同时出现的情形,判定位置进一步升高
bug修复:键盘映射可用小键盘
更新:截图不加锁
airtest 1.1.7新增了一个threadsafe_generator专门用来搞多线程截图
底层实现原理跟我自己写的是一毛一样的,多了几层调用效率或许变低了??
但是,touch/swipe等输入操作,尤其是本人优化过的swipe,仍然是线程不安全的,这不是什么线程安全问题(这里所有数据传输都是线程安全的),而是因为那些touchmethod根本就没记录手指数量和序号,所有操作都是硬编码在0号手指上完成的(pinch当然是在0号和1号手指上完成的),所有暴露出来的接口无法同时按在两个地方
另外,很久以前我就把获取锁和检测flag解耦了,因此现在并不需要自己实现锁
更新:预约终止可以选定后续战斗数量
更改:由「最后登录」识别好友界面,以应对印象中之前从未出现过的free系统助战
你游又整新活了,正经人谁刷free用NPC助战啊
更新:针对游戏版本更新进行适配
游戏底部菜单增加了「终端」按钮,导致其他图标整体右移,更改了空格映射座标使其功能正常
更改:选择设备后立刻应用连接,不再缓存
这样做避免了很多问题,但是导致选择设备后卡顿
优化:加载按键映射时检测设备连接
bug修复:带有技能宝具配置的助战选取错误
这个bug是v3.4.6将好友技能配置由简单的下划线分隔改为正则匹配时编码错误,直到现在这个功能真正被使用了才发现
更新:针对游戏版本更新进行适配
判定技能冷却完毕的字样由「还剩」变为了「剩余」,剩字还是那个剩字,但是位置改变了
判定宝具充能的充能条位置下移了
优化:并非每次检查截图都要保存,现在弹出截图后按s键保存
优化:ui文本更改
readme小幅修订
bug修复:在羁绊等级上升时正确判定战斗结束
问题不在判定的阈值,而在于被识别的>>与从者的羁绊加深了文字的位置是会发生变化的
其下方可能有一行(追加可在个人空间中播放的语音)(获得圣晶石或苹果)或两行(从者的资料已更新\n追加可在个人空间中播放的语音)文字
而该提示框是相对某座标居中的,因而引发了位置变动
羁绊5以及之后的显示形式未经完全验证,如果后续仍然出现此问题再改
另:奇人共赏时隔数月终于更新了!
这么大的更新间隔确实证明了前述的收费政策具有十足的威慑力
同时这次的事件更警醒本人一定要将之严格贯彻落实
优化:调整了判定宝具充能的方法,现在正确率更高而且更快了
我终于对这一过程做了详细分析,数据表明,宝具充能满之后亮暗变化的周期为正好1.6s
被判定区域个像素各通道的平均值在46-155之间线性变化
另外,我发现了一件奇怪的事情:在4.6.3版本中我说过调整了战斗结束羁绊等级提升的判定阈值,但是代码居然没有修改??git log中查到改行的上一次修改居然是在3.9.9!
版本日志中4.6.3记录的日期是2020/10/11,也就是我在issue中收到对应反馈的那天,但是实际commit是在2020/11/1,可能这之间发生了一些不为人知的变故
本人在v3.5.0加入了御主礼装的相关功能,然后在v4.0.0加入了换人礼装的特殊功能,现在所在的v4.7.x对其中的bug进行了一些修复
很遗憾,本人的换人礼装早就满级了,所以相关功能一次都没有实际使用过...
当然其他的御主礼装的技能也几乎没用过
这个项目终归逃不了二八定律的窠臼,还真就只有20%的功能是关键的,像这些御主礼装,还有包含了一坨代码的智能刷新模板图片,都是可有可无的
正如v3.5.0日志中所述,这个程序不是来给你三回合速刷的,而非速刷为目的的换人需要相当精确的考量
至此为止,本程序对战斗的操控都是相当抽象的,不会去关注某一个特定从者的特殊机制,这样的代码已经能够完全胜任当下的所有free本,但是换人礼装从御主礼装这一抽象中实现出来,打破了这一现状,而且还附加了大量的代码,我觉得这是不好的
因此我在ui中禁用了换人礼装的输入,删除了相关代码,相关功能就留作备用,以防哪一天yls出了个什么奇怪的副本
后续应该会继续精简代码,或者全部重构
bug修复:在有助战模板时正确选取助战
调整了新增功能的部分延时,避免了一些你可能永远也不会遇到的问题
本次更新内容可靠性未经充分验证,请谨慎下载使用
新增:非速刷的换人礼装支持,你仍然可以在战斗中随时更新技能等各项配置
bug修复:调整延时以正确识别无法使用的宝具
bug修复:正确获取stage,使得优先攻击能正确生效
bug修复:
-调整判定战斗结束的阈值,试图增强羁绊等级提升时的稳定性
-在助战未满一屏导致无滚动条且程序试图筛选助战时能够正确选取助战而非认为没有助战
新增了一张呆毛王的助战模板
每次无限池一开这个项目的star数就蹭蹭蹭往上涨,可是这不能当饭吃啊...
这个学期课程突然变得超难,顶不住了,更新放缓
另:我打算在之后的版本中应用一些python的新特性(尤其是象牙运算符),届时python3.7及以下将无法使用
ui优化
每次功能更新后都会有这样一个版本来调整ui上的细节,这也标示着相关功能已经基本稳定
将ui里的打开命令提示符换成了PowerShell
修订readme
近期收到了多起不同设备上的兼容性问题反馈且暂未发现问题,需要更多样本
新增:狗粮筛选器
在image/mailfilter目录下有要被筛选的图片模板,领取银狗粮和不多于2个的金狗粮
基于归一化模板匹配的特性,这些模板最好拥有接近的大小,并且特征所在的部位要有一定的比例
如果你大幅更改了这些模板,很可能需要重新调教参数
新增:抽无限池
本程序的刷本效率相较去年同期已经有了大幅提升,因此获得的奖券变得太多了
所以加了这么一个小功能,同时修改了ui
之后会上线邮箱筛选功能
修订readme
我计划对本项目的代码风格进行一系列微调,现在是第一步
另有微调,谁tm想得到我写个程序都得玄学调参
修订readme
bug修复:延时调整,在未首通时能够正确进本
之前动画还没放完就截图识别导致错误,虽然连续战斗能用了但是不连续的不能用了
本次沿用了连续战斗上线之前的延时设置,可能有些许优化空间
ui修正,延时调整
bug修复:手抖了,环刷本时预约本场战斗结束后中止功能对应标志位初始化打错了
新增:你可以在循环刷本时预约本场战斗结束后中止
bug修复:战斗暂停/停止不应该影响DirListener
之前在战斗线程通过点击停止按钮而停止时会使得dirListener在下一次阻塞返回时停止
另有小优化
优化:并非所有人都把adb加入了环境变量,所以用了airtest的adb库,同时精简了一波代码
bug修复:临时补丁中获取到分辨率后不排序直接写入成员中
平板/模拟器之类默认横屏的设备就应该width>height
嘛,毕竟没有那么仔细地看airtest的源码
之前不是手机摔了吗,就发现了minitouch的一个问题
现在我买了个新手机,OnePlus 8 Pro
这手机怎么样就不多说了,总之暂时不建议购买
同时我又发现了airtest库的一个问题,见这个issue
简单说来,就是我随便从一堆苹果里拿一个,而airtest傻乎乎的认为我拿的一定是第一个
为暂时修复这一问题,我进行了一些魔改,暂不清楚是否在各种设备上有效,更不知道这会不会带来什么其他问题
见fgoCore.py第185行附近
优化:重新设计选卡代码
4.3.0的优化并不能在所有情形下都起作用,如三红时红卡会在chain选择和伤害排序中各选一遍,仍无法解决卡顿问题
更新后的代码使得选卡序列至少有5张卡,且无重复,比如1红3蓝1绿会排序为蓝蓝蓝红绿而非之前的蓝蓝蓝红蓝蓝蓝绿
小优化
吃了个晚饭,更新迟了
更新:fgo四周年了,连续战斗功能适配
游戏内指引的存在部分关卡无法进行连续出击的情况让我看得很慌,所以无论如何都要保留原来的代码
当未拿到首通奖励时,无法连续出击
好像智能机出现了另一个状态分支,这就体现出没有goto的问题了,本来直接一个标签飞过去完事
注意现在选了助战就没法反悔了,请确保在性能较好的机器上使用带特制swipe的助战选取功能
优化:多选几张卡防止漏按
之前总有设备卡顿导致的选卡时只选了了两张卡的情况发生,设备与设备间是不同的,现在我在极度愤怒的情况下直接以更快的频率一口气选五张卡,要是没有卡顿那很好选的就是我要的卡,万一卡掉了几张也能让战斗继续只不过当前回合亏一点点伤害
另:mumu模拟器不支持maxtouch,只能用minitouch
如果你非得用mumu模拟器,自己翻v4.0.2及以前的commit把Base类给改回来吧...
网易wrng,这airtest用着已经够烦心了,自家的模拟器还跟他不兼容
ui优化:退出前确认
优化:监控好友模板的线程应该随着主线程的关闭而关闭
确保程序正常退出
现在呢这个功能已经基本写完了,我的天哪,直接给爷空手撸了个DirListener出来,也不知道写得对不对,早知道这样就随便去哪个同步软件里抄一段过来了
优化:部分延时调整
另:现在userScript是3美少女队的配置,便于速刷Sacrilege Tetrahedron
之前是些没删干净的测试代码
优化,精简代码,统一格式,并增加了一些优化可能性
bug修复:果然上一个版本我手抖了...当然现在很可能也在抖...
虽然我已经尝试了多种情形,但仍不能完全保证该功能动作正确
bug修复:实时化简文件改动列表
该功能未经充分试验,并且有极高的可能性含有bug
在提高效率的同时避免了先前提到的错误
打个比方,先更改一个文件再把它删掉,那就只会留下删除的记录
化简原则:尽可能减少需要重新读文件的操作(create和update).因此最终记录数并不一定是最少的
至此,这个不起眼的功能已经占用了超过80行代码,接近fgoCore的1/4了
这是必要的牺牲
嘛,终于写了点跟算法搭边的东西了
ui修正
曾经好不容易降到200行的代码随着功能增加又快到300行了...
大优化:你现在不需要手动刷新助战了
该功能未经充分试验
此处使用了该死的win32api
助战列表会在选取助战时智能增量更新
当初就是为了减少硬盘IO才限定手动刷新,现在已经实现了智能化,并且现在的增量更新方式可能比你手动刷新更省硬盘性能
如果文件没有改变或仅仅是重命名就不会重新读取,仅当文件更改/新增/删除时才会读硬盘
这个智能刷新助战的功能已经占用太多代码了,并且有一些已知的bug,比如先新建文件再删掉就会在选取助战时读取那个已经被删掉的文件导致错误,这也是为什么那个「选取助战」的按钮仍然保留了下来
之后很有可能直接回滚把这个功能整个砍掉,操作稍微麻烦点就麻烦点,刷本效率和稳定性提升才是要不惜一切代价达成的目标
总结起来就是方向错了,感知不强,徒增功耗
当你更改编队信息,你很可能是希望在下一次操作中再使用它,而如果你更改了助战,那多半是马上要用的,毕竟你不可能在战斗中截到助战的图,如果你需要频繁地修改助战图片,请在程序运行前改好
特别地,如果你喜欢一次性向助战目录中加入数百张图片,请手动调大ReadDirectoryChangesW的第二个参数的大小
小优化:部分数据输入校验
另:adb又更新了,请顺手把airtest里面的那个换了
小优化
修订readme
文本/显示优化
泳装三期复刻活动由于会在刷本之间强制插入剧情而不便使用循环刷本功能,再说三种点数也该均衡发展
更新:点按方式改为maxtouch,重写swipe
上个版本更新时注意到没有屏幕的手机不能用minitouch,而adb实在效率低下
随后我就发现剩下的那个maxtouch好像在各种环境下都能正确动作,于是就拿来用了
并且在当前环境下性能似乎不亚于minitouch,这真是太好了
但这也就代表着我得重写swipe,这便是本次更新的重点内容
哦我的上帝呀,我又对着airtest的源码翻了半天
之前minitouch是有样例数据包格式的而maxtouch没有,我得凭着我的聪明才智把它猜出来
其他还有一些零零碎碎的小更改,更新频率低了每次更新内容就有点杂乱
另:我发现了一个能用于各个语言版本的项目,直接搞成了apk
这种直接装在手机上的程序真的不会被检测封号吗??本人深表怀疑,并且不敢做测试
那个解说视频做得跟屎一样,再加上my English is so poor,根本看不下去,只能自己研究
搞了半天半天界面很nb,功能其实一般般,并且配置有点麻烦
其设计初衷是3t+补刀速刷,好像只能实现相当有限的智能战斗吗,我差点以为本项目「github最强」的地位不保了
它号称能在蓝叠模拟器上用结果我搞了半天还是直接模拟器卡死,这就是国际版和国内版的区别吗...
有一说一,人家外国的编程社区环境真的相当和谐,跟我这种面向国内的项目真是天差地别
bug修复:选卡逻辑
在没有宝具和/或color chain时,不会优先选取无法行动的指令卡
我tm刷岐阜城时看见选了无法行动三连直接裂开
此外,魅惑等导致不能行动的debuff在选卡时的表现是一样的,都是眩晕的图标加上「行动不能」的文字,这也就意味着我不需要新增模板图片或更改好几个月以前写的代码
另:我发现了一个大问题
我把我手机屏幕摔了,于是在淘宝上买了屏幕打算自己换,因此先拆了屏幕简单拼装一下用scrcpy投屏肝
但minitouch是假装自己是触摸屏向手机发送触摸信号的,但是现在手机上根本没有屏幕,于是加载失败......
这或许也是在更换过与原装屏幕分辨率不同的屏幕的手机上滑动不正确的原因
对于这种情况,只能使用adb触摸输入(touch_method=TOUCH_METHOD.ADBTOUCH),并禁用本人为minitouch特别编写的siwpe函数
一夜回到解放前...(所以为什么不用模拟器呢
我想要研究一下scrcpy等投屏软件具体是如何实现触摸输入的,然而c语言真的让人头皮发麻
bug修复:选取编队功能并非在所有机型上都能正确动作
我以为版本更新后修复了这一问题,结果不能用的还是不能用
但是这个功能真的能省心很多,所以要实现而不能一直处于废弃状态
此版本加了一些特判,如果当前编队已经是目标编队,就不会试图切换编队
文本优化
更新:魔王信长活动军备生产确认按钮点击
代码写一半才发现根本不用管这个界面只要按空格就行了...
另:上个版本更新的「帮你选取编队」功能由于由于客户端更新现在好像可以正常动作了
如果你那里不能就改回原来的注释状态吧
另:Qt不能跨线程修改ui,但是读取经过测试好像是安全的
重要:7月7日airtest终于更新了1.1.4,修复了部分机型截图不正确的bug,见这个issue和这篇日志,因此截图代码的相关适配有简化更改
注意更新后再次检查adb版本是否有冲突,airtest自带的adb版本较旧
重构/优化代码
更新:重新编写了按键映射表
按照键盘排布编写,去除了一些我已经忘记了干什么用的键,将ctrl/shift/alt键换成了其他键(modifier需要特判),新增了一堆键
更新:提供了一些用于调试的功能
我经常在手机投屏时感到鼠标操纵不便,所以编写了按键映射功能,在菜单栏里提供,程序窗口必须获得焦点
由于我的按键映射表是按照虚拟键码来编写的而qt有他自己的一套编码,所以需要转换,并且仍然并非完全有效
在操纵git时需要手动cd让我烦躁,现在可以一键在程序位置打开cmd
更新:帮你选取编队
在进入战斗前去编队界面选取编队保存是一件非常麻烦的事,所以我在配置文件中增加了编队位置项,可以帮你选取编队
但是你游在点击当前编队所对应的按钮后进入战斗按钮就没有响应了,必须在当前编队改变后才会恢复响应
我当然可以切另一个编队再切回来,但是这样故障风险太高了,所以此功能暂时被注释掉了
更新:提供换人礼装的相关功能
这功能最终还是加上了,无非是多一个输入框,加几个键值,然后写一堆特判,之前不做这个功能仅仅是因为我不高兴
更新:优先攻击相关定义更改
现在从1开始编号,0设定为无效,这可以帮你节省下大约800ms的时间
这一更改使得现在界面里的东西统一为从1开始编号,并且0表示无效
此更新与之前版本不兼容,你需要更改之前编写的配置文件
更新:去除了结束战斗时播放音频的功能
保持本项目的简洁,在代码里一省再省而资源文件随便乱加就本末倒置了
优化:加快启动速度
在应用启动时不再智能加载默认设备,让用户自己选设备
优化:大量文本描述/显示效果优化
感知不强,方向错了,功耗不变
另:我看到了这个项目(GitHub,NGA)提供了模拟战斗的功能(只能放宝具不能平a,用于测试能否速刷)
东西很不错,但是代码相当臃肿,无论如何,该项目作者至少把Mooncell上那些从者/礼装的信息爬下来了
这或许可以被本项目用于真正的智能战斗这也是为什么此次更新新开了一个大版本号
尽管相应的功能可能还要很久才能上线,又或者新开一个项目单独提供,毕竟这工程量不是一般大
本版本没有实质性更新
我看到了一个公主连结的项目,里面用了uiautomator2,稍作了解后感觉挺不错的
本来想着终于能拜托这烦人的airtest了,结果发现这个东西仅提供了相当有限的功能,毕竟是封装后的接口,完全无法满足本项目的需求,遂未使用
写了一半的代码被注释掉了,现在仍然可以查看
bug修复:当完成一场战斗且达成了任务条件时,任务进度提示框会把当前检测是否要吃苹果的判定区域遮挡住导致要吃苹果但实际没吃而卡死
现在换成了检测回复体力界面的关闭按钮
每次更新都东修西补的,导致现在代码不统一,命名也很混乱,等暑假有空了要重构
巴巴托斯我来了
跟上个版本一样的原因,在两场战斗交接时增加了延时
最近各种问题有点多,好烦
优化:暂停和结束程序运行的相关功能只应在程序运行时被初始化而不应在其他不相关功能内被修改
其他还有很多细节更改,最近功能更新的太多了很多细节就不是很舒服
bug修复:与进入战斗时相同,使用技能后技能按键要略晚于攻击按钮加载(30fps下5帧)
尽管看起来是同时加载完成的,但是实际上还需要一点时间才能被点击
这一问题在本项目开源前(2019/10/25)曾经困扰了我很久才被发现所以并没有记录在日志里,现在又碰到就能秒解了
同样,这个程序很多地方看似无意的操作说不定都大有来头.我的源码现在将近300行了,并且抵得上别人的1000行,然而对于代码的说明,可能需要3000行才能彻底讲明白
所以别再抱怨为什么代码里没注释了,要是写上注释,代码就没法看了
令人遗憾的是,增加的这足足0.16秒延时仅仅让bug出现率从0.5%变到了0%,一旦延时不够就会有极低概率卡住,这代价未免太大了
我觉得现在光光一个熔断器可能不是很够用,可能需要一个更加智能的特殊情况处理器
又跳过了几层包装调用
如果把整个airtest比作一个人,我不是雇佣这个人来给我干活,而是把他的几个脏器挖出来给我用,这就不可避免地有排异反应
bug修复:修复了对异型屏的尺寸有可能不能正确缩放的问题
这波到此为止,设备io相关方面应该没有问题了,要是您那里不能用,那多半是您的设备不兼容
bug修复:修复了新版swipe可能存在的滑动位置不正确的问题
部分设备,尤其是模拟器,触摸屏的尺寸和显示的尺寸是不一样的,比如显示器1920*1080,但是触摸输入设备实际上是32768*32768
bug修复:自v3.8.0以来异型屏黑边的问题看似解决了,实际只解决了一半,在一个方向上能正确获取到截图,在另一方向上则会裁剪错误
因为我基本不开刘海所以直到上一个版本改代码时才注意到这个问题,现在将其修复
这一问题是airtest对部分设备兼容不佳导致我要手动适配才一不小心发生的,请参考v3.6.0的日志,整整两个月过去了airtest项目组还是没有修复我反馈的bug
格式字符串有一点不好,当你重命名某一变量,你得手动更改字符串值
添加了qp加成礼装的好友模板供孔明活动使用
实践证明,v3.8.8更新的快速滚屏并不靠谱,那个取消后摇用的水平滚动在低配机型上很容易被卡成点击
也就是说,现在最好的滚动方式还是v3.3.0的底层设备读写
于是我又去翻了airtest的相关源码,但是发现了一个大问题:
他也怕点得太快被设备略过,就在每两次I/O之间加了足够的sleep
不得不说airtest真是究极套娃,每个类都实现一点功能,然后疯狂继承或不继承
反正先照着他的这套写写看,有问题了再改
后续内容皆为经验总结,如果你知道实际的工作原理,请告诉我
在起始位置按下->瞬移到结束位置->延时->(重复一次结束位置->)抬起
fgo在识别用户滚动时好像会浪费一些坐标输入用于确认用户确实是在滚动而非点击或长按,此时的坐标跨度要很小但是不能太小,而滚动途中如果两步间跨度太大也会被判定无效
例如从800滚动到100,你很可能需要800-795-790-600-400-200-100-延时-弹起的过程
实际上我在各种设备上用手指或鼠标实际滑动了几次然后将设备采样数据dump了下来,发现我完全可以用很密集的频率发送一大串坐标
经过更多的试验,我发现滚动速度越快或者滚动步长越长,移动距离误差越大,这很有可能是因为fgo没能及时加载出相应内容导致丢帧
fgo中的滚动惯性完全由滚动的最后一小段时间所经过的距离决定,与实际设备采样无关
延时0.3秒可将惯性后摇控制在通常图片模板的可接受范围内,延时0.5秒就几乎没有后摇了,但是可能被认为是长按
经过至少6个小时的爆肝,现在的代码已经可以比较稳定稳定工作了,但是应该还可以挤出水来
这波就体现出v3.9.0的锁的用处了,你绝不能在滑动到一半时向队列中写入新值
另外,当前swipe使用时要先手动初始化内部对象,比如在之前调用一次touch
很多步长之类的参数写死在代码里了,这个siwpe也不能用于小于48px的滑动
你也不应该无间断调用新swipe,以免上一个滑动事件还没响应完
bug修复:更改了判定宝具封印的阈值,现在能正确地识别出被封印或眩晕的指令卡
被封印时约0.06-0.12,未封印时约0.6-0.8,当前阈值0.3
我仍然没打过有可能被魅惑的关卡,所以相关功能还没写
更新:更改了检测滚动条的函数
增加一个参数传入滚动条底所在位置,以用于将来的无限池邮箱筛选等功能
bug修复:正确读取后排的技能数据,v3.8.6的遗留错误
之前检测技能是否设置允许使用时访问了错误的地址,在有人阵亡时依然读取先前的数据,导致了错误的技能使用
调整了部分延时
包装了几个tapOnCmp,这其实很滑稽,在我的程序里,点击可能存在的位置固定的图片应该将识别与点击分开
最近沉迷母猪连结,工会战群机器人写得我焦头烂额,fgo程序都没怎么更新了.
母猪连结本质音游,音游开挂实属孤儿
说到底这个程序的大厦已经建成,今后只要做一些修修补补的工作就行了,我也没瞧见远处的天空有什么乌云
bug修复:在程序执行时获取截图有可能冲突挺烦人的,就手动写了个锁,反正单例模式没必要调库,到底没几行代码,方便简单透明高效
仅仅是因为这一情况相对经常出现才想办法解决,其他小概率要求的很可能将来也不会修复
要怪就怪airtest没写操作队列
优化:战斗的暂停和终止能得到更及时的反馈了
把一个大sleep改为一堆小sleep加判定,延时仍然是精确的,在大段延时时应优先考虑使用新方法以便操作尽快生效
优化:在选完助战确认编队时可能会卡加载,加了一个判断
这样整下去我非得把游戏资源一帧一帧全部存下来,当初觉得不错的IMG-Check调用也越来越臃肿了
优化:给Check搞了个缓存,方便代码编写
虽然搞了个缓存但是之前没有缓存而要用同一次Check的时候挤在一坨lambda里的代码还是没改
今后优化选卡逻辑的时候可用
另:重构了部分代码,更改了ui内的说明
憨憨家族又添一丁
优化:ui安全性更改,战斗与抽友情互斥
同时简化了资源存储目录
程序开发有两个底线:一不破坏游戏公平,二不损失游戏乐趣
程序只做人能做到的事情,并且不能把人能做到的全做了
街头霸王n3结束了,我终于有空回来写程序了...
bug修复:增加了一些延时
在返回主界面后,可能多点了一下打开菜单,这没有关系,反正再点一下就关闭了,但是当前点得太快了,有极低概率动画还没放完就点击了关卡导致没有进入关卡
其他地方类似
同时调整代码顺序,使你可以在返回主界面的途中运行main
更新:更加合理高效地选取助战
之前是固定滚动16个页面,现在会在滚动至少10秒钟确保可以刷新之后将剩下的列表项识别完
如果没有好友,也会等待10秒然后再找,而不是刷新一次发现没有就报错
并且现在滚动得更快了,而且没有惯性后摇
如果在您的设备上并没有发生滚动,请增大swipe的duration值,要怪就怪fgo的垃圾优化
更新:前几日的fgo更改了抽卡的机制,现在程序与之适配
警告:现在不会区分友情池和氪金池!!!
注意:出于账户资产安全考虑,你需要先抽一次十连,待进入转圈界面时再启动程序
bug修复:swipe对坐标的映射错误
这一错误与3.8.4中的错误是成对出现的,并且就是上下两行...
更新:最近长草,有一些幕间本/强话本少于3面,增加了一些代码让技能和宝具能够提前使用,让你不必频繁更改队伍配置
这些最大面数的截图显然是取自不同关卡的,我对其做了一些处理使得他们的背景看起来是相同的,但是不能保证不出问题
注意:由于这些更改会使得战斗行为不完全依照您的设置,所以现在skillInfo[i][j][0]和houguInfo[i][0]==0时代表不使用技能/宝具
8说了,我去冬木大桥刷凶骨了
bug修复:旋转屏幕后点击位置还在旋转前的坐标
这是airtest.minitouch的问题,用adb就没有关系,但是效率低
也就是说,v3.8.0的更改并没有实际解决问题
现在强行创建了一个新设备,之后会想办法作更好的处理
更新:抽友情的功能现在增加到了菜单中
我本想着抽友情这种简单独立的工作直接airtestIDE里面随便搞搞就好了,结果效率低得令人难以忍受
而且airtest的模板默认是在灰度下匹配并且相当不精确(70%,我的是95%),也就是说,若非仔细设置就无法区分友情池和氪金池
所以有了这个功能,加起来就6行代码(ui里的不算)跟一张图片
出于账号资产安全考虑,我不会开发任何贩卖/喂狗粮/搓丸子的功能
更改:调整了fuse.__max
以前600,现在200,其实100就差不多够了,除非我方敌方各开三个宝具
bug修复:以前的base.touch打错了一个符号,现已纠正
没人教过我数学,我对数学不感兴趣
更新:针对白色情人节的更新
白色情人节这诚意满满的副本配置要是再用程序打个十几二十几回合就太浪费了
所以我试图测试了一波用此程序进行3T速刷的可能性
并在用户程序区域内写好了一个典型的3T程序
看好了,3T程序是这么写的,别tm再在oneBattle里面xjb乱改了!!
然后我希望main函数使用userScript,就加了一个对话框
这里的界面设计有待调整,反正对话框很蠢,但至少功能实现了
说不定先选择一个函数然后决定只跑一次还是传进main里循环要更好
另:突然想起来我有去除airtest的计划,那就不能企图从airtest的logger上接头了...
于是自己写了个一样的
优化:重构代码,使用了logging,现在命令行上的各种输出看起来格式相当统一街头霸王
新增:fgoData,日后有用
bug修复:运行程序结束闪退
这个bug出现率相对较低,是由于跨线程修改ui导致的
v3.4.7的更新表明创建一个线程然后立刻在这个线程里修改ui几乎肯定会报错,但是如果这个线程运行了很久才修改ui就几乎不会报错
真奇怪,要是能改就能改,不能改就不能改,大概率成功小概率失败就很迷
难道是相应用于安全性检查的资源被智能回收了吗??
反正现在不会出现这一问题了,写成一堆信号就感觉很臃肿
我本来不想修这个bug的,直到有几次改了配置没保存...
上一个版本的奇怪问题解决了,我忘了写self参数
......淦
为什么直接IDE报错弹框里写「3221226505无法转换为int32」呢
照着这个0xC0000409去查,百度根本查不到,然后谷歌了半天,在stackoverflow里看到了这么一段:
(NB: if you're using any kind of IDE or debugger, and you are getting unexpected errors or crashes, your first step in diagnosing the problem should always be to test the code in a standard console.
Quite often, the IDE or debugger itself can be the cause of the problem, or may mask error messages comming either from Python or from underlying libraries, such as Qt).
然后进cmd运行,总算看到了TypeError: refreshDevice() takes 0 positional arguments but 2 were given
wrng
更新:异形屏黑边兼容啦
调整了一些参数
我又发现了一个大问题:
当更改过屏幕分辨率后,airtest的get_current_resolution仍然返回物理尺寸
所以不得不用get_render_resolution
那不如顺手就把刘海屏黑边问题也给解决了,方案如下:
如果程序打开时手机为竖屏/程序空闲时旋转了屏幕但并保持/程序运行时旋转了屏幕,就应该重新读取设备显示信息
这一功能在菜单中有提供
出于不明原因此菜单栏点击就报错,这可能是Qt本身的问题,如果在您的电脑上可以正常运行,请跟我说一声
由于跨线程强行修改了可能正在使用的变量,若程序正在运行,我建议您先将其终止
我特意把代码设计成这样,作为对异形屏用户的惩罚,哈~哈~哈~
另:垃圾小米毁我青春,千万不要在小米机器上adb shell wm size进行更改,这会在横屏时产生点按位置偏移(redmi8a/MIUI 11.0.7)
另:airtest自带的adb版本=1.0.40,并非最新版本,请注意版本冲突问题,您可以用新版adb覆盖airtest里的adb,反正是向下兼容的
另:总有一天我得用其他手段来截图,airtest用着太不爽了,隔壁scrcpy才没有这么多问题,只不过它是java写的...
果然猪厂跟Genymobile这种大公司还是有相当的实力差距啊(骗氪的实力倒是一流
不过scrcpy好像是作为视频编码的,一帧一帧地读取不一定好搞
另:我不该进行3.7.0的更新的,每当调试出错就听到一堆歪比巴卜心态都崩了
bug修复:一堆bug,改吐了
今日运势:诸事不宜
忌:重构代码
往readme里加了一点东西
更新:播放声音的功能回来了
由于先前的版本砍掉了win32api,所以没法放声音了
于是用回了playsound
QSound?不存在的,请牢记这是一个python项目,怎么简单怎么来
基于UI的特性,不宜播放过长的音乐
于是重点来了,我给大家整个活
我翻出了植物大战僵尸的资源文件,想办法把里边的音频文件搞了出来,最后挑了几个处理后听起来还不错的放在了sound文件夹里
为了避免连续地听到同一段音频,我还专门写了个生成器
祝好
兼容补丁:airtest.javacap部分机型兼容优化
并非所有用户都需要这个版本的更改
有用户反映了异形屏的问题,我就买了一个异形屏设备
airtest官方也对异形屏的黑边没有很好的办法,因此维持v3.4.5的更改
但是我发现了一个非常严重的问题,见我提交的这个issue
为了在官方补丁发布前能够正常使用,我进行了部分相关算法的暴力重写,当然,画质不可避免地差,有可能漏判
漏判的相应判定参数要是airtest没修这个bug就会在之后的版本进行修正
另,偏移量和缩放的意义略有更改
bug修复:统一了配置保存的格式
优化:压缩代码体积(-30%)
PyQt5(5.13.0)库跟C++的Qt库相比在父子控件的属性继承上好像有点不人性化的地方,所以没精简掉的代码就应该是不得不保留的
优化:进一步加大ui,并且看起来更和谐了,并去除了根本没用的右键菜单及相关翻译
多就是美,大就是好;代码要短,界面要大
初步的计划是文本框得有fgo里面技能按钮差不多大,最好取得焦点后能全选
如何取得焦点后能全选?1设置输入掩码2设置右对齐让用户点不到文本外面
重写控件?事件监听?不存在的
最近的更新使得UI文件体积+100%这也无可奈何啊
bug修复:现在可以使用带指向的御主技能
我真傻,真的,我单知道从者的技能会有指向目标,却不知道御主也有
更新:增加御主技能
代码内部一直都有御主技能的相关按键配置,但是在此前的绝大多数情况下,你完全不需要使用御主技能也能通关
但是看起来CCC活动的副本难度有点高,贪加成的话得全队他人格Alterego而不能上对应克制
我开发这个程序就是为了贪加成,这时再说退而求其次放弃加成未免太不识趣了
不忘初心才能得其始终,要想贪加成且不翻车无非就两条路,1优化现有功能2使用未使用的功能
那显然2要容易得多,于是你现在可以使用御主技能了
当然换人还是没法内置在大的算法框架里,重复一次,这个程序不是来给你三回合速刷的
而非速刷为目的的换人需要相当精确的考量,因此暂不考虑
我要保证在阵容[Lilith/BBssr/BBsr/Lip/JK/SSY/好友]下能够稳定刷本
现阶段值得考虑的是先用御主技能还是先用从者技能,当前是先从者技能以便莉莉丝二技能接防御弱化解除
另外,由于御主技能CD很长,并且检测是否冷却完毕要加操作加代码,所以御主技能一场战斗只会施放一次
请注意半路接管战斗时可能企图使用未冷却完毕的御主技能
优化:增大了所有元素,方便触摸屏点击
就算增大了一些,你还是要比较小心地定位手指,然而再大就破坏屏幕整体和谐了
bug修复:上一个版本提出的问题好像是由于对ui的跨线程修改
但是很奇怪,只有runOneBattle才会有一定概率报错
薛定谔的python吃掉了他的bilibili.狗.徳川家康.保留
而且现在的更改好像只是降低了这一概率
就很抽象
归根结底还是偷懒不肯用QThread
另:正在寻找更好的beep方法
优化:助战技能宝具设定更改,看起来更人性化了,并且代码更短了
未解之谜:见fgoGui.py第84行的注释
有知道为什么的master麻烦联系我一下,非常感谢
优化:细节更改
优化:助战技能宝具设定更改,现在会从助战截图文件名中读取助战信息
有用户反映了异形屏黑边的问题,请见issue
我没有异形屏设备,因此无法调试代码,所以相关补丁可能永远不会上线
在手机上,fgo总是在用户区内居中显示
而用户区在异形屏上通常不是整个屏幕
用户通常不会fgo玩到一半来一个adb shell wm size {} {}
但是很有可能手一抖屏幕旋转了
就算之前裁剪正确了,屏幕一转黑边就到另一边去了,裁剪的偏移量加倍
本来点击的位置偏移一点该放技能还是放技能,现在偏移量加倍说不定全线崩盘
所以代码改不改55开
那就不改
如果黑边不能关闭,请换手机
Google当初就不该解除屏幕必须16:9的限制
bug修复:之前手抖打错了两个字符导致对于非1080p屏幕不能正确裁剪和点击
优化:解决各种各样的小问题
当你电脑上连了手机又开了模拟器时,位于列表中的第一个设备将会是手机,请注意手动切换
经过近期测试,当前版本完全达成设计目标(可以开新坑了
在全部adb命令行更新为airtest接口的同时,实现了完全去除显式win32调用的目标,顺便还精简了代码
珍爱生命,远离win32api
一个月前这个项目还是命令行窗口,无法交互只能直接改代码,我还对qt一无所知,也没听说过airtest
果然懒惰是人类进步的阶梯,游戏是第一生产力
更新:所有3.3.0版本的功能全部恢复
优化:设备连接懒加载,先记录序列号,要用时再更新对象
你甚至可以先手动输入一个并不存在于设备列表中的序列号,然后再连接设备
重构部分代码,看着舒服,用着也舒服
更新:基本功能基本稳定,多设备兼容性也没有问题,但仍有待优化
airtest偶尔会莫名其妙出错,并且是那种进程直接崩掉一点信息不给的
迟早有一天我得把airtest库给阉了重构,源代码越看越气
完全移除了win32引用
增加了窗口置顶的功能
更新:延时调整
当前的目标是先让代码跑起来,原有的功能之后再补
关于airtest首次安装/重新启动带来的本程序中没有考虑到的问题请提交issue
有些地方延时是数帧数卡得正好的,可能你的电脑一卡就出问题了
更新:我已经基本搞明白了airtest安卓部分的工作原理,现在已经用上了airtest库进行截图与触摸,效率奇高
但是现在点得太快了,又得手动延迟
airtest最大的问题就是基于模板识别的点击效率太低,并且难以修改参数,这应该是处于通用性作出的牺牲
airtest最大的优点就是把所有高效的底层交互整合到了一起,一步就能到位
因此无论是谁移植到谁那里都应该是用我的识别和airtest的IO
我看airtest的源码写得有点臃肿,有空把它精简一下
另外,我用的是airtest的底层接口,这些接口好像并没有出现在官方文档里,因此可能出现错误
由于不同版本的adb间会有冲突,所以现在统一使用airtest自带的adb
这样就可以去除win32库和大量命令行调用
由于截图不用win32了,所以也去除了其他附属品,易用性略有下降,但是稳定性提升
现在设备序列号是写在代码里的,你得手动更改
ui里面那些过时的代码已经被注释掉了,会在之后的更新中慢慢补齐
使用了基于底层设备的swipe,消除swipe的后摇.所以当前版本只能用于Bluestack模拟器
由于进程间通讯的关系比原有的慢
更改了助战截图,先前版本的截图选取的范围过大以至于包含了威力加成图标而导致匹配失败
补充了状态栏信息
现在几乎所有的说明都可以直接在ui里看到,所以大幅精简了readme
我希望readme变成广告,展现我的程序的特点而非具体实现
bug修复:
swipe在上个版本误删了一些字符
新增:
添加了菜单栏和状态栏及相关信息
ui改版,稳定性优化,添加了一些功能
在绝大多数情况下,安卓的信息并不需要每次都检查改变,就像各窗口句柄一样.因此更改了ui
有时你需要更改助战模板,添加了一个按钮使得现在你不需要重新启动应用就能完成更改
注意:当前的一些功能可能对于错误的输入产生难以预料的反应
优化:情人节活动不能在游戏内筛选掉巧克力礼装.现在到了chooseFriend函数重见天日的时候了
添加了相应活动礼装的截图,增大了每次刷新助阵页面前识别的页面数量以应对mix职阶.
如果你确定你只需要在特定职阶中筛选,请自行调整代码,但是请注意两次刷新之间需要时间间隔
微乎其微聊胜于无的小改动
修订readme
我仔细地研究了airtest的工作原理
minicap采集屏幕的原理很简单:通过ndk的截屏接口不停的截屏并通过socket接口实时发送,这样客户端便可以得到一序列的图片流,图片流合成后就成为视频
我不需要实时显示,因此minicap就截一张图时应该和win32的截图差不多
STF框架对于点击,拖拽等操作比adb快得多
细节部分有待进一步学习.等我什么时候研究透了,就可以更快乐地跑程序了
bug修复:开始创建线程前将熔断器复原,否则熔断后无法继续操作
bug修复:选卡报错
先前的版本会在场上队员不满三名时ListIndexOutOfRange
此bug可能是v2.10重构时留下的
优化:将一些列表改为了生成器,应用了(可能)更高效的选卡算法
本以为sorted是快速排序,相同颜色的指令卡有多张时不会枯燥地选排在前面的了,结果发现用的是稳定的归并
更改:现在宝具优先级越大越先用
优化:从者头像识别阈值修改
说明:通过今日对数百场战斗的分析,当从者未变时,匹配结果约为1e-9,不超过2e-3.当从者改变时,匹配结果约为0.25,不低于0.08
因此看起来取几何平均值是比较合适的
但是有些从者长得比较歪,实际框选的区域包含了大量背景;又有些从者长的比较像(比如黑骑呆和伊莉雅).因此实际取值仍有待进一步优化
二次元人脸识别?要是有现成库的话可以考虑一下,不过我觉得现有功能够用了
bug修复:现在当hFgoWnd最小化时启动程序不会把程序窗口移到屏幕外面去
对于最小化的窗口,GetWindowRect返回[i-32000for i in rcNormalPosition]也就是说,如果你不幸拥有一个分辨率高于32000*32000的显示屏,就可能在相关win32的判断上出问题
ロン！国士無双！-32000
bug修复:有些应用,尤其是游戏,不允许消息队列操作,此时不应让窗口弹出打扰用户,所以在setForeground里加了一个try
优化:调整了tab顺序
杂七杂八的修改:
处理了工作路径的问题,不依赖调试器设置工作路径(我才发现双击运行会报错)
现有的7个队伍设置差不多够了,新建/重命名/删除等功能也不见得常用,如果要修改的话就手动改config文件吧,不想写代码了,删库跑路
确认了Tab顺序
试图减少了各ui文件的体积(-40%)
bug修复:有关类,列表生成式,eval之间命名空间继承所带来的bug修复
bug修复:修复了宝具设置不生效的问题,这一bug可能是v2.10.3重构时留下的
即将更新:编队设置的新建/重命名/删除等功能.代码已经写好了,但是效果有点不友好,所以相关控件被改为了不可编辑不可点击
bug修复:保证setForeground能正常执行
优化:修改了Key映射,以应对boss血条与小兵血条不在一行里的情况,从上到下从右到左依次为dangerPos0-5,按键为小键盘9-4
优化:你可以看见你点过哪个编队按钮
「一个控制台窗口+一个ui」的布局基本确定,我希望移动动其中一个窗口时另一个跟着动
功能移植
在以前版本中,我可以一边挂程序一边修改代码,因为代码会在执行开始时全部载入内存
但是现在由于线程之间共享内存,你可以战斗途中变更各项配置,如果你在两个设备上用相同的队伍打同一个图,你甚至可以在这两个设备间切换
这究竟是好是坏有待实践证明,目前我认为应该删除这一特性
但是,想要删除这一特性比较困难.首先我想到的是改为多进程,但是我希望进程退出时对ui进行变动,而Qt的一堆控件都是不可序列化的...
所以多进程是不可能的,也无法利用多进程进行挂起或中断
再者就是将各项配置都作为参数传入战斗函数,这将大幅重构代码
还有就是强行禁止一些更改,这样就使用体验极差
当然究极的解决方案是存在的,那就是搞一个服务端和客户端然后进程间交互,但是这对于一个小项目而言负担过重
Qt好像有他自己的线程库Qthread,看看能不能解决这个问题----不能
脑阔疼
最后还是从进程与线程的区别入手,创建线程前拷贝一份变量,这样,我的线程有了属于他自己的内存.蠢,但是有效
挂起/中断的功能也用了很原始的实现,但是绝对不会出问题
ui基本定型,基本功能基本生效.
之后还会移植一些功能
修订readme
在开发中遇到了以下问题:
- 当
app=QApplication(sys.argv)执行完毕后,Qt将系统缩放倍率强行调整为1. - QtDesigner里面应用layout的显示效果和预期相去甚远.
- python的线程无法挂起或中断,目前要取消程序运行必须关了整个应用重开
我打算开始写ui了
代码结构更改,无实质性变化
我才发现函数定义本身就是可以挤在一行里面的
加入英文readme
xjb乱写了一个ui之后说不定用得上本来想搞个ui的但是测试到一半发现比直接改代码麻烦得多,就不搞了...但是今后可能会向代码中添加一些接口以便ui访问
bug修复:修改了一些写代码时手抖留下的错误
优化:又把所有代码塞进一个文件里了,方便交互
负优化:在hWnd初始化的下方加了一行被注释掉的代码,方便那些经常换设备/模拟器的用户
现在所有启用中的代码少于200行
bug修复:彻底修复了先前版本存在的宝具充能检测方式存在的不稳定不兼容因素
说明:录屏数了一波帧数,从按下选卡按钮到普通指令卡加载完毕需要正好0.5秒,然而按下选课按钮到宝具卡加载完毕需要2.17秒,宝具充能条闪烁周期为1.62秒.因此,每隔0.81秒检测一次就可以保证任意连续两次检测中有一次检测中宝具条的亮度大于从最暗变到最亮区间时间中点的亮度.实际使用时考虑一波误差和截图运算所需时间,取40%亮度值.
另:isHouguReady现在应该在选卡之后运行,整合了之前的isHouguSealed函数,又压缩掉了一堆代码,并且由于短路运算符的关系效率应该比之前高一些
另:严格来讲,亮度指的是0.3*R+0.6*G+0.1*B,但我的代码中就暴力地(R+G+B)/3,反正也是严格递增的,效果相同
另:上一个版本的更改是完全错误的,只是碰巧圣诞节的几个本背景偏白才有效
优化:多设备兼容性优化,也可能没有优化,也可能负优化,更改了isHouguReady函数
说明:随便网上找了个安卓投屏软件在我自己的手机上测试了一波.全屏显示要会员?C语言写了个程序强行全屏显示.勤劳与智慧的天朝人民是绝对不会给你一分钱的!转念一想我的程序现在已经不用全屏了啊...然后这个投屏软件有四个标题类名都一样的子窗口,所以我还得在每次投屏后手动填写句柄值...垃圾软件毁我青春!
另:isHouguReady函数是当前唯一一个像素识别而非模板匹配的函数,之后可能还得改
bug修复:现在fgo_shell内的初始化部分能正确地获取尺寸及缩放信息
说明:adb shell wm size会返回通常使用方向的尺寸,比如手机就是1080*1920之类,而平板就可能是1920*1080,而fgo始终是横屏(landscape)方式显示,这导致了之前版本的初始化有可能将长宽颠倒
优化:setSkillInfo更名为setInfo,以便添加更多快速换装信息
优化:重写一些代码,现在能够适应任意(非16:9)分辨率及显示画面
另:重构了一堆代码,极大地并且过分地压缩了代码的纵向长度,将已经基本定型的代码挤到了一行里,可读性大幅下降.用更精简的代码实现更强大的功能
lambda函数是好文明!
修改了一些写代码时的失误,简化了一些代码,删去了一些很久都没有再次用上的代码段
说明:能写在一行里的绝不写两行
更改了代码开头的字符画
bug修复&优化:考虑了从者行动不能的情况,不会试图使用行动不能的从者的宝具,并更合理地选择指令卡
说明:魅惑导致的行动不能的图标好像是不一样的,等实战遇到了再处理
bug修复:增加了部分延时
另:把所有模板的位深度都改为了24,删除了以后不会再用的图片
另:明确了战斗函数的管辖范围
新:向代码中增加播放声音的功能,现在一旦程序停止运行就会播放战歌
说明:为什么不用pygame或者playsound呢?pygame音质奇差,playsound已经不更新了
无限池最高效率本开启前几个小时发布此更新,就是为了牺牲睡眠质量保证24小时不断肝
bug修复:代码重构带来了一些后续的麻烦...但降低一点内聚性总是好的
优化:现在这个程序可以用于任意分辨率的16:9的模拟器显示画面了
代码重构,无实质性变化
把所有(依赖于adb的)底层交互接口放到了一个新文件里,如果要换平台应用程序,只要更改新文件里面的内容就行了
看了一波下来突然发现我的程序封装的是真滴好,只有三个函数和少数变量是跟fgo运行所在平台相关的,他们是:
tap,swipe,screenShot(已弃用)
并且对于当前版本的程序,你几乎用不到chooseFrined函数,截图识别也跟adb无关,也就是说,你甚至可以不写swipe和screenShot函数,因为在所有其他地方都没有使用这两个函数,就是不停地点点点
我要不要再把所有依赖Windows的函数也搞个文件放着呢?应该没有人吃了空用Linux打fgo吧...mac?那是什么我不知道
bug修复:现在在战斗结束时如果提示加好友会更稳定地拒绝
说明:此前版本中由于点击时机不精确有可能导致卡在加好友界面
重大bug修复:现在每截一次图就会释放在调用win32api时分配的内存
说明:在此前的版本中进行大约9场battle就会占用大约8G内存进而导致截图中的某一步分配内存失败, 因此所有使用v2.8.x版本的用户都应该立刻安装此更新
果然,珍爱生命,远离win32api
优化:现在在好友选择界面发现没有好友时(多半是由于使用了过于严苛的筛选条件导致的),会刷新一次好友列表,再发现列表为空才会GG
优化:chooseFriend函数现在不会无止境地找好友,最多识别Fuse.__max(默认300)个页面
延时调整
bug修复:现在不会试图使用被封印的宝具
对于这个bug的修复可能有bug
期末考结束了...
稳定性大优化
全面修订readme
截图从<某个已经消失的版本>的qt改回win32api了...
修改了一些判定的模板图片
由于截图效率的提高,正在尝试用多帧来进行一次判定来提高可靠性,比如houguinfo
稳定性优化
肝!
紧急更新
本次更新内容可靠性未经充分验证,请谨慎下载使用
使用了win32api代替之前的adb进行截图,单次截图时间从1s级别减低到了10ms级别
这段代码是不带裁剪和缩放的,所以需要模拟器在正好1920*1080的显示器上全屏显示,真机的话要用投屏软件
由于之前的代码有一些地方是依赖截图的耗时来进行延迟的,这一延迟消失后可能引发各种各样的问题,所以我正在一点一点地在必要的地方加上显式延迟,但是仍然会有疏漏,之后发现一个解决一个,慢慢改
打版本日志的时候突然发现已经2020年了...期末考好累...
圣诞活动7号晚上开始,但是期末考9号才结束...
所以复习放一边去,先把程序给写了
重大bug修复,带指向的技能现在会正确地施放了(尽管识别错误的问题仍然存在)
微调了部分按键坐标,现在你可以吃银苹果和铜苹果了
小优化,切换目标后加了冗余点击以关闭在点击已选中目标时产生的敌人详情对话框
增加了所谓「快速换装(setSkillInfo)」函数,先把配置写好,然后活动一开就上号挂机岂不美哉!
flag:我圣诞要吃光苹果,当前金苹果当量287
蓝叠模拟器更到最新版就不会闪退了
chooseFriend函数还是挺重要的,要用来选取特定从者
明天(2019年11月27日星期三)上午8:30通关主线第8话(前篇)后开启炎舞击退战,
增加了一小段代码用于otk,现在直接运行程序就是单次执行该程序
这段代码专用于「三美少女队」,如果你没有bba/cba中的任何一个,或嫖不到cba,告辞.
需要极地迦勒底制服
本次活动特攻是「特殊的魔放」,会稀释其他的倍率,可恶!
版本更新后蓝叠模拟器闪退,在物理机上的兼容性未发现显著问题.
版本更新后可以对助战礼装进行筛选,chooseFriend函数变得不再重要,已在主程序中禁用.
你已经到达了世界的尽头