huangrunheng
huangrunheng
提点自己的想法 + 希望有一种运行模式，是更加智能化的运行，既可以按照一定的图片流顺序进行点击（当然这个不一定是非得这次点击是这张图片，下次必须是另一张图片），希望有一定的优先级顺序 + 客户端的多样性，用户脚本用途的多样性，使得对“目标名称”的选择需求变多，而当下只有写死的六种模式显得太少，希望可以有可变的选择 + 有一个从我接触源码配置设置的不明所以，云里雾里的使用ini作为配置文件，由于其语法的简单使得后期更新的时候只能进行无脑堆叠，使得整个程序后期臃肿无章法，可以重写为json或者yaml toml + 当前界面对用户暴露过多设置，感受出随着软件的更新没有一定的组织结构，过于杂乱，可以选择在界面处写一个通用的可以随着配置文件选项增加而增加的 用户接口，一是可以优化界面，二是防呆处理，三是可以为了以后更新兼容 + 还是关于用户界面的，站在21世纪的重度互联网用户来说，这个上个世纪的风格属实接受不了，如果我来选我选qml， 还可以只留下右边的Log输出，设置以另一个dialog弹窗来设置  + 还有一个能当我没说的选用python实在是...太太太吃cpu了，运行时连桌面版这两个程序，我笔记本cpu直接飙升到百分之六七十，脚本吃掉了十多二十多，......有一说一如果技术选型我来选我还是会选python
干脆一步到位 每次截图都检测 不过还没有测试所用的时间 感觉1ms以内
突然想到使用像素级别进行检测，比模板匹配快多了
网友的要求总是千奇百怪，你先加点人，僵尸号那种也行，不要求多三个就可以了。有空在改改
👍很厉害
截图和点击都是阻塞的，不过截图里面会计算距离上一次的时间，如果小于0.3s就是会sleep一小会
修改底层并不是很好的设计，这些时间是由机器的配置决定的，你所优化的应该是推理的速度。 https://github.com/LmeSzinc/AzurLaneAutoScript/issues/988
看你这个速度在几十毫秒也是可以的呀，不过我有点疑问出模型的时候没有map这些数据的吗
为了照顾配置不高的机器，没有要求必须实时识别呀，式神的移动的位置是可以预测的嘛，尽管这并不是很好的思路
最后的部署方式上用pytorch并不是一个很好的选择，安装一个库就已经比本体大了， `torch.hub.load('ultralytics/yolov5', 'custom', path='./tasks/Hyakkiyakou/weights/best.onnx')` 会在本地上缓存一些模型结构，但是会调用这个 ``` os.system('pip install -U ultralytics') import ultralytics ``` 这个用的是操作系统的默认的python 解释器而不是我们oas自己的。 完全可以用onnxruntime 这个推理框架，本身同ocr就用着