huangrunheng

从上游Alas同步设备相关

2

### 当前不足 同步新的截图方式 ### 解决方案 _No response_ ### 其他内容 _No response_

### 当前不足 ## 1、定位 早先使用绝对位置进行定位，但是不同的战斗场景下会导致不同的定位范围，极大增加工作量。 感谢群友的提示，将标记式神命名后可以在战斗中显示出来，ocr并点击很容易。 ## 2、标记反馈 一直摆烂的原因是 早先还不知道如何验证标记上了。突然记起来 图片匹配 又不是仅仅只有一个模板匹配。特征匹配可以解决大小方向等等这些不同 不过值得一提的是，绿标会极大概率引来鬼使黑 ### 解决方案 _No response_ ### 其他内容 _No response_

🐛协作检测时间

3

### 在提问之前... - [X] 我已经搜索了现有的 issues - [X] 我在提问题之前至少花费了 5 分钟来思考和准备 - [X] 我已经阅读了文档中的 常见问题(FAQ) - [ ] 这个问题出现了至少三次，不是偶发的 ### 描述你的问题 在开始设计时，对于突发事件选择主动检测。为了优化性能选择了默认10秒检测一次。 但是这有时候一方面响应不及时。而另一方面往往更严重，由于协作的新弹窗导致覆盖掉原有的游戏界面，会有某些元素不显示。导致流程错乱。提升到3秒或者5秒可能也并不是很优雅的做法 ### 如何复现 1. 前往 '...' 2. 点击...

### 当前不足 两个账号想要挂机太麻烦了，要是无脑执行就好了 ### 解决方案 _No response_ ### 其他内容 _No response_

🎈游戏装饰自定义

6

### 描述   作者不怎么氪金庭院皮肤不多，目前只实现了两个，得使用一段时间看看稳定与否。 那实现思路很简单，就是根据你的不同配置去替换掉原先的图片，具体的可以看[./tasks/Component/Costume/README.md](https://github.com/runhey/OnmyojiAutoScript/blob/dev/tasks/Component/Costume/README.md) 意思就是如果想支持自己所使用的庭院皮肤，就照着来很简单的。不过建议实现了来给我们一个PR，不然后面更新的话就会覆盖掉你的修改。如果觉得太麻烦就可以新开一个issue发张你庭院的图，有空我会加上去。 同理也可以支持其他的装饰，如主题、战斗主题、其他的。欢迎pr

🎈百鬼夜行

6

### 描述 这个模式下，目标检测无疑是最优解。我们需要一位大手来主导开发。

发展规划（挖坑~不是）

14

## 日常任务 1. [✔ runhey]琐事一遍：每日一抽、寮祈愿、好友友情点、商店签到 2. [✔ runhey]悬赏封印 3. [✔ runhey]宠物：其乐融融、饕餮大餐、放置食材 4. [✔ runhey]金币妖怪 5. [❓ runhey]经验妖怪 6. [✔ runhey]年兽 7. ❓ 师徒守护 8. [✔ runhey]花合战 9. [✔ runhey]式神委派 10....

召唤界面弹窗

6

### 在提问之前... - [X] 我已经搜索了现有的 issues - [X] 我在提问题之前至少花费了 5 分钟来思考和准备 - [X] 我已经阅读了文档中的 常见问题(FAQ) - [X] 这个问题出现了至少三次，不是偶发的 ### 描述你的问题 每次出现召唤活动时候，会有不同的弹窗类型，如何自适应？ ### 如何复现 1. 前往 '...' 2. 点击 '....' 3....

协作系统

1

考虑这样的场景，组队打完一段时间的御魂后突破卷满了，这需要停止御魂副本将突破卷清空然后继续刷御魂。一般的脚本无法自动处理这类多人协同副本（御魂、觉醒、日轮、永生之海、探索），OAS 希望可以通过设定将其自动化执行，这将详细描述协作系统的设计思路: 既然是针对多人副本而系统，那么第一点首先考虑人数的问题，在前面的记录中，考虑用户之间在系统内随机组队是被否决的，其中最重要的一个原因是这无法保证所组队的队员的阵容匹配和御魂水平，其他倒是小问题，第二个比较合理的是由多个人自发组成的小圈，这可以称为小组，小组的协作系统会自动的协调调度多人副本任务，这样规模的人员数量有这样的优势：1.执行稳定，小组内一致协商好 2. 不会被一锅端，每次执行副本只是两个人，如果都是长期固定的会被鬼使黑 3. 任务调度更加灵活。 第三个是点对点的，即两个人所组成，这本身就是第二个的子集。 另一个比较重要的是组网的问题，个体之间的通信才能保证即时响应副本任务，自然而然想到的是搭一个供所有人可以接入的服务器，讨论一番后发现最无法回避的是这会导致被抓去喝茶，其次是规模上去后服务器的费用问题。合理的方案是小组之间自行组网，这可能会有一些门槛但是不难，借助一些组网工具如zerotier、wireguard（傻瓜式）来搭建局域网。剩下的如在一台电脑上这些格局太小。 那么剩下是对这个系统的功能需要，准备的说是思考路径： 1. 自适应：对于每个个体都会自适应各种情况，当然这里太广泛了，具体来说小组成员一直离线、小组成员突然掉线、系统处于某些原因无法正确调度 等等。这应该单独讨论 2. 多角色：个体的角色不是固定的，在有的任务中可以是队员，也可以是队长。但是对于具体的某个任务这将是固定的，否则将会引入极大的复杂度。 3. 时差：这貌似并不难 4. 引入新的调度器(个体): 对于协作系统的设计直观的描述应当是：对于每个个体，在保证执行其他的任务的条件下，调度执行多人任务。如何量化？ ~~摊手~ 如何实现这一系统，是否需要建模，是否引入优化理论，基于主从的协同还是基于博弈的协同？ 我也迷乎

御魂优化

3

队员身份可以庭院原地等待， [通用队员] 接收邀请时检查所邀请的内容