Open Asxcvbn opened 10 months ago
这三次是你自己打的还是src挂的,感觉只是没有更新仪表盘的问题
src挂的,确实只是没更新仪表盘(
2024-01-15_src.txt 似乎还是存在一点问题;
另外一个实例的仪表盘倒是正常的,符合预期的0/3, 但是这个就还是有点问题
一段时间后似乎正常了...? 此时还没跑到第二轮的周本调度任务 2024-01-16_src - 副本.txt
一段时间后似乎正常了...? 此时还没跑到第二轮的周本调度任务 2024-01-16_src - 副本.txt
不是挂着已修复待反馈的标吗
一段时间后似乎正常了...? 此时还没跑到第二轮的周本调度任务 2024-01-16_src - 副本.txt
不是挂着已修复待反馈的标吗
这不是反馈了嘛(),看上面的回复,有些上下文的。
主要是看起来这次的log,似乎是
周本次数 3/3 2024-01-15 23:19:43.842 | INFO | [OCR_WEEKLY_LIMIT] 3/3
->SRC刷完了周本 2024-01-15 23:31:33.956 | INFO | Done 1 waves at total
此时体力恰好刷完 [OCR_TRAILBLAZE_POWER] 10/240
有这么一句,周本时期: Combat wave limit: 3/3, can not run again
->周本次数0/3但是SRC以为3/3,预约了等够30体力的时间再次运行周本 2024-01-15 23:31:38.079 | INFO | Delay task Weekly
to 2024-01-16 01:31:38
->到预约的时候OCR发现已经到周限制了,才把仪表盘改回0/3。 2024-01-16 01:32:47.481 | INFO | [OCR_WEEKLY_LIMIT] 0/3
15日的log到第一次提交的时候并没有彻底结束, 没包括 2024-01-16 01:32:47.481的情况。当天完整log重新上传一下在这 2024-01-15_src.txt
考虑到这次情况比较特殊(周一晚上才启动了SRC),不排除这次仪表盘不正常是因为这个原因导致的。但是每天晚上启动一次SRC应该也算官方支持的用法吧,尽管推荐用法是一直开着。 另外,另一个实例虽然也是晚上启动,但是没遇到这个问题。
一段时间后似乎正常了...? 此时还没跑到第二轮的周本调度任务 2024-01-16_src - 副本.txt
不是挂着已修复待反馈的标吗
这不是反馈了嘛(),看上面的回复,有些上下文的。
主要是看起来这次的log,似乎是 周本次数 3/3 2024-01-15 23:19:43.842 | INFO | [OCR_WEEKLY_LIMIT] 3/3
->SRC刷完了周本 2024-01-15 23:31:33.956 | INFO | Done 1 waves at total
此时体力恰好刷完 [OCR_TRAILBLAZE_POWER] 10/240 有这么一句,周本时期: Combat wave limit: 3/3, can not run again ->周本次数0/3但是SRC以为3/3,预约了等够30体力的时间再次运行周本 2024-01-15 23:31:38.079 | INFO | Delay taskWeekly
to 2024-01-16 01:31:38
->到预约的时候OCR发现已经到周限制了,才把仪表盘改回0/3。 2024-01-16 01:32:47.481 | INFO | [OCR_WEEKLY_LIMIT] 0/315日的log到第一次提交的时候并没有彻底结束, 没包括 2024-01-16 01:32:47.481的情况。当天完整log重新上传一下在这 2024-01-15_src.txt
考虑到这次情况比较特殊(周一晚上才启动了SRC),不排除这次仪表盘不正常是因为这个原因导致的。但是每天晚上启动一次SRC应该也算官方支持的用法吧,尽管推荐用法是一直开着。 另外,另一个实例虽然也是晚上启动,但是没遇到这个问题。
一直开着不是占电脑性能吗,估计一般都是一天就开一次
一直开着不是费电吗
现在看起来好像一次打2,不一口气把3次周本打完,这个仪表盘就不准确? 2024-01-24_src2.txt
作为对比,另一边是一口气打完的,它的仪表盘还算正常。 2024-01-23_src.txt
大约02:37的时候SRC启动并跑了一次周本,但是显然结果依然不对: 2024-01-24_src2.txt
我的观察差不多是,似乎在运行历战余响这个任务之前?和部分情况下的任务之后,会进行检测更新当前状态,但是如果运行一半因为比如体力不够被打断,那么就不会更新剩余历战余响次数,需要等到比如也许下一次历战余响任务运行前才会更新。
我的观察差不多是,似乎在运行历战余响这个任务之前?和部分情况下的任务之后,会进行检测更新当前状态,但是如果运行一半因为比如体力不够被打断,那么就不会更新剩余历战余响次数,需要等到比如也许下一次历战余响任务运行前才会更新。
你这样一说我注意到一个情况,他的更新机制貌似是全部打完才会更新,因为我看他点击再次挑战不会更新仪表板,这有可能就是问题根源
而且如果这个任务被打断了,那么跑第三个的时候仪表盘也不会更新,于是当体力不足分开一个一个跑完,实际上是0/3的时候,仪表盘是1/3,还会预约3个小时之后的历战余响任务,虽然到那个时候可能才会发现这个破任务打完了= =
2024-02-19_src.txt 冒个泡证明问题还存在jpg
一个简单的复现手段是, 关闭历战余响,并等待体力回复至60~80附近(保证历战余响三连打不完)
然后打开历战余响,开始刷取:当刷完二连的时候会直接退出而不更新仪表盘,此时看起来历战余响还是3/3.
在提问之前...
描述你的问题
使用SRC完成周本任务后,会在日志页面的仪表盘更新各种状态,如历战余响次数,然而其更新并不准确,经常是每周一大早做完了3次,而历战余响显示2/3。
如何复现
预期行为
当然是能够正确反应剩余次数,而不是差1.
相关 Logs
截图
2024-01-08_src2.txt
还有别的吗?
mumu12@1280x720@30fps?
感觉就是没在打完周本之后再次更新当前的剩余次数