Accuracy about repair_speed and heal_speed

[nt1r]

repair_speed = 330 heal_speed = 300

Hello, there! I'm writing the same QTE script with kotlin(not python). I understand the speed 330 means the cursor spin 330 degree per second. But I have a question about the accuracy of these two speeds. I found that QTE would miss the perfect area in some cases.(mostly works well). Is it possible to be 331, 332 or another number?

How do you calculate these two speeds? I screenshot some QTE images and record the milliseconds(from Epoch 1970). I use my own method to calculate spin degree of cursor per second. There is the result of my calculation:

speed: 333.33334 speed: 350.0 speed: 300.0 speed: 219.51219 speed: 481.4815 speed: 230.76923 speed: 464.2857 speed: 236.84212 speed: 258.0645 speed: 541.6667 speed: 333.33334 speed: 230.76923 speed: 300.0 speed: 321.42856 speed: 320.0 speed: 346.15387 speed: 296.2963 speed: 346.15387 speed: 481.4815 speed: 230.76923 speed: 500.0 speed: 315.78946 speed: 195.12195 speed: 481.4815 speed: 256.41028 speed: 400.0 speed: 243.24324 Average: 333.8662081117983

I'm very confused with this result: Some up to 500 and some down to 195. So how do you calculate it?

[nt1r]

[MiracleShadow]

Are you trying to use screenshot to calculate? the timestamp of using screenshot may be inaccurate.

[nt1r]

Are you trying to use screenshot to calculate? the timestamp of using screenshot may be inaccurate.

@MiracleShadow Yes, I'm using screenshot to calculate cursor speed. I tried so many times and found that's inaccurate.

In Java and Kotlin, current time of system(JVM) supports nanosecond unit. I'm using nanosecond to calculate now, but it's still inaccurate.

I think the problem stems from matching the screenshot to the point of time screenshot start to render. It takes about 20-30 milliseconds to take a screenshot.

Do you have a better idea?

PS: 看你的repo应该是国人，那我就说中文了。

我用了OCR检测互动的文本，自动判断QTE是治疗还是修理。互动的文本位置和QTE的位置类似，在屏幕上都是固定的。

我还写了一个自动点血网的功能，思路是用OpenCV检测血网中所有的圆形，用圆形的边界颜色判断该圆形内的道具是否可以点击获取。转生图标的位置在血网中也是固定的，鲜艳的红色+较大的半径和道具的圆形区分。

我还给程序做了一个GUI。

[MiracleShadow]

QTE的速度应该是固定的，可以60帧录屏看一下，判定的效果应该还和延迟有关系。

可以，非常好的工作，支持来自国人。

可以再加上自动判断“挣脱”QTE吗？还有如果受到“无情风暴”、“压迫”、“电量超载”技能影响的QTE不太好做，你有没有什么思路。目前这个repo的工具遇到老杨就寄了。

自动点血网我现在用的是BloodwebAutoBuy，不过这个工具的算法比较呆，好像是用的贪心算法。比如”Cheap Mode“可能并不是最少花费；”Expensive Mode“没有优先考虑最末端的，容易黑掉。希望你可以有更好的规划算法。

加油！ 另外，”聚精会神“翻译成”完美检定“会不会容易准确易懂一些😆

[nt1r]

@MiracleShadow

"挣脱"QTE我有计划实现，目前已经实现了一部分，其实打QTE的本质基本是相同的：经过一些判断条件计算出指针还剩余多少时间到达白色格子，等待这段之间时间之后按下空格，逻辑就这样简单。难点就在于如何无状态地判断。

“无情风暴”、“压迫”、“电量超载”可以分为两类，"无情风暴"的QTE没有白格，“压迫”、“电量超载”的QTE和普通QTE一样有白格。理论上实现了普通QTE之后，“压迫”、“电量超载”只需要计算QTE指针的速度再加以修改就可以。

老杨的QTE和普通QTE相比，有两种特性：

• 可能出现逆时针
• 位置全屏随机（可能是几个固定位置，我没在意，但这些位置都不在屏幕中间）

解决上述两种特性的方法：

• 逆时针 首先你需要知道一点，所有存在白格的QTE，白格的位置都位于整个QTE区域的最前端（指针最优先经过）。如何判断QTE是否是逆时针就依靠这个特性：如果整个QTE区域中的白格位于顺时针方向的末尾，那这个QTE就是逆时针的；同理，如果整个QTE区域中的白格位于顺时针方向的前端，那这个QTE就是顺时针的。

• 位置随机 这个问题的难点在于截图的位置，我目前没有想到如何如何在整个屏幕上准确判断QTE的位置，但有几个特征可能有帮助：

1. 所有的QTE指针都围绕一个圆心旋转，通过多张截图判断红色指针旋转的圆心确定QTE中心位置，然后截图该区域。
2. QTE的白色弧线也有一个圆心，同上。

一旦需要搜索整个屏幕截图，计算的代价会非常大，QTE能否做到实时还需要测试才知道。

点血网Github上有个star数近100的，BloodEmporium，图标更新到了6.4.0，但我没用过，你可以试试看。

”聚精会神“是个技能，这个技能会影响QTE指针的速度。并不是你理解的”完美检定“。这游戏目前有个技能组合修机很夸张，”聚精会神“+"破案心切"，叠满buff之后每个QTE都是红齿轮的效果，和你一起修机的队友直呼外挂。你有兴趣可以试试这两个技能组合。

[MiracleShadow]

@nt1r

好的，骨灰级玩家！谢谢科普，我玩人类比较少，所以不知道这个技能。 你推荐的这个功能配置项更多，可以给每个物品配置优先级，你是要做成这种吗？

[nt1r]

@nt1r

好的，骨灰级玩家！谢谢科普，我玩人类比较少，所以不知道这个技能。 你推荐的这个功能配置项更多，可以给每个物品配置优先级，你是要做成这种吗？

@MiracleShadow

我暂时不打算重复造轮子，点血网的功能BloodEmporium已经比较完善。我目前已经实现的点血网的逻辑就是有啥道具能点就点啥，把血点消耗完就行。我是实在不想手动一个一个点才做的这个功能。

[MiracleShadow]

@nt1r

哈哈哈 好吧，BloodEmporium确实实现比较麻烦，但是性能很一般。 你会把你的handy tool 开源吗，或者在哪儿发布呢？

[nt1r]

@nt1r

哈哈哈 好吧，BloodEmporium确实实现比较麻烦，但是性能很一般。 你会把你的handy tool 开源吗，或者在哪儿发布呢？

@MiracleShadow

我有考虑过开源到Github，在我的理解中开源的目的是一种分享和交流。目前这个Handy Tool是我自己用的，我还挺满意。但如果要分享给其他人使用，还有一些问题需要解决：

• 适应各种类型的屏幕分辨率，甚至是多个显示器 比如目前我使用主显示器2K分辨率玩游戏，副显示器竖屏1080P。Java和Windows的截图工具两者都判定我的主显示器分辨率是2048×1152，而不是2560×1440。
• 可修改按键的绑定 例如目前我习惯的自动修机，清除数据绑定到鼠标侧键和鼠标中键，自动点血网绑定的是Alt+Shift+B，自动丢道具捡起来绑定的是Alt+Shift+K。这些只有我自己知道，如果需要让用户知道的话，还需要提供一个修改绑定按键的功能和对应的界面。
• 不同CPU的性能可能会导致截图速度有差异 计算时间的方式我使用的是取多张截图去头尾计算平均值，我不确定低性能的CPU有没有问题。
• 滤镜的颜色 英伟达滤镜的配置是会反应到截图中的，比如我取红色指针或者白色QTE区域的时候，不同的滤镜效果不一定会准确。

[En73r]

我最近在忙学业，没时间更新。对于精准度的研究我已经花了很多时间，总结出了一些经验，如果你想完善程序希望能帮到你: 1.用windows自带的api 截屏和使用高精度的睡眠函数是减少程序运行时间造成误差的关键 2.由于观测的精度只有60fps，所以得到的速度精度有限，但是可以通过 较大距离/较大时间来减小误差，我通过录频中截取 270度的旋转，得到对应时间t，270/t 算出来比较精确的速度330，这个速度对于击中QTE来说精度应该是绰绰有余。3. 由于观测精度只有60fps，在检测红条位置时会有1/60/*330/2=2.75(度)的误差，并且在观测时产生的截图时间也不是一致的，会根据电脑cpu使用情况改变，主要是这两个因素造成了无法避免的误差，但是由于QTE的目标位置足够宽，由于误差导致QTE失败的概率可以忽略不计。4. 根据第3点中QTE的宽度足够的观点，我写出了当前版本的代码，主要思路是计算出当观测结束，实时的红条在目标白框时，观测到的红条应该处于的区间。同时循环扫描红条位置，当计算出红条在区间内时，表明实时的红条就在QTE区域，敲击空格。 但是由于不同玩家的滤镜不一样导致识别出红条的宽度不一，如果滤镜效果太严重，会导致程序无效。5. 可以根据第3点的全部优化方向来改写版本v0.10.9，该版本使用的是根据速度预测，与滤镜无关，但是编写时并没有使用高精度睡眠，以及一些其他的当前版本用于优化精度的代码，如果能优化完全，应该可以完成一个不同滤镜下都能使用的DBDEazyQTE。

如果该程序在你的电脑上无法使用，请 1）使用程序提供的色彩偏移选项。 2）开启HDR 3）调整滤镜

[En73r]

当前版本程序在滤镜相符的情况下，可以做到99.9%的成功率，在我自己的电脑上是屡试不爽的。

[nt1r]

我最近在忙学业，没时间更新。对于精准度的研究我已经花了很多时间，总结出了一些经验，如果你想完善程序希望能帮到你: 1.用windows自带的api 截屏是减少程序运行时间造成误差的关键 2.由于观测的精度只有60fps，所以得到的速度精度有限，但是可以通过 较大距离/较大时间来减小误差，我通过录频中截取 270度的旋转，得到对应时间t，270/t 算出来比较精确的速度330，这个速度对于击中QTE来说精度应该是绰绰有余。3. 由于观测精度只有60fps，在检测红条位置时会有1/60/*330/2=2.75(度)的误差，并且在观测时产生的截图时间也不是一致的，会根据电脑cpu使用情况改变，主要是这两个因素造成了无法避免的误差，但是由于QTE的目标位置足够宽，由于误差导致QTE失败的概率可以忽略不计。4. 根据第3点中QTE的宽度足够的观点，我写出了当前版本的代码，主要思路是计算出当观测结束，实时的红条在目标白框时，观测到的红条应该处于的区间。同时循环扫描红条位置，当计算出红条在区间内时，表明实时的红条就在QTE区域，敲击空格。 但是由于不同玩家的滤镜不一样导致识别出红条的宽度不一，如果滤镜效果太严重，会导致程序无效。5. 可以根据第3点的全部优化方向来改写版本v0.10.9，该版本使用的是根据速度预测，与滤镜无关，但是编写时并没有使用高精度睡眠，以及一些其他的当前版本用于优化精度的代码，如果能优化完全，应该可以完成一个不同滤镜下都能使用的DBDEazyQTE。

如果该程序在你的电脑上无法使用，请 1）使用程序提供的色彩偏移选项。 2）开启HDR 3）调整滤镜

@En73r 非常感谢提供帮助！

[MiracleShadow]

@nt1r @En73r 原来都是中国人，可以留个联系方式吗？

[MiracleShadow]

@nt1r @En73r 找到了官方的QTE数据Skill_Checks#Statistics，可以推算出速度，还有受技能影响的增减益情况。

[nt1r]

@nt1r @En73r 原来都是中国人，可以留个联系方式吗？

我们用漂流瓶联系，就不留联系方式了。

[nt1r]

@nt1r @En73r 找到了官方的QTE数据Skill_Checks#Statistics，可以推算出速度，还有受技能影响的增减益情况。

感谢，这个数据非常有用，治疗速度确实是 @En73r 计算出来的300°/s（360/1.2=300），修机速度应该是wiki上写的327.27（360/1.1≈327.27）

[MiracleShadow]

@nt1r @En73r 找到了官方的QTE数据Skill_Checks#Statistics，可以推算出速度，还有受技能影响的增减益情况。

感谢，这个数据非常有用，治疗速度确实是 @En73r 计算出来的300°/s（360/1.2=300），修机速度应该是wiki上写的327.27（360/1.1≈327.27）

大可能330速度是对的，1.09...简写成1.1了

[YunnrEX]

@nt1r 你好，我想请教一下您如何制作的自动点血点工具，以及自动qte工具，我是一个小白，刚刚开始接触代码，并不是非常了解，能否将源码发送给我借鉴一下，不胜感激！akirahehao34@gmail.com

[nt1r]

@YunnrEX

能否将源码发送给我借鉴一下

我使用的编程语言是kotlin，和这个项目的语言python不太一样，也许你更熟悉其他编程语言。基于这个考虑，我还是把实现的思路说一下吧，不同的编程语言有不同的实现。

我想请教一下您如何制作

我实现的自动点血点和自动QTE是基于计算机视觉（图像处理）的一种方案，模拟人眼看显示器屏幕做出抉择的思路类似。既然要获取显示器图像，截图功能是必须的。我使用的是Java awt包中的类Robot中的createScreenCapture方法获取显示器的图像，但速度只有40ms左右（25FPS）。如果想达到实时的截图效果，你可以试试调用Windows的API，python可以使用该项目中的win32gui库，java可以试试JNI/JNA中的API。

自动点血点工具

血网中所有的道具和附加品都包裹在圆形的图案内，如果能识别出血网中的圆形并点击圆心的位置就可以自动化。我使用的是OpenCV库中的medianBlur和HoughCircles方法，前者预处理模糊图像提高鲁棒性，后者检测圆形。效果图如下：

自动qte工具

前置工作：

• 检测截图中QTE的白格，计算角度
• 检测截图中红色指针，计算角度

这两者我用的都是简单的像素值检测，角度是目标像素与圆心的夹角，坐标系同图像坐标系。对角度的频率进行排序，取前几个值去头尾再取平均。

之后的实现思路有两种：

• 根据指针旋转的速度计算QTE指针还有多久会到达白格处，等待这段时间之后按下空格。
• 高帧率截图计算图像中QTE指针和白格的角度差是否在提前计算好的阈值之中。阈值的计算由截图帧率，指针速度以及程序中一些误差决定。