一、阿比特的计时方法的疑点
单独看阿比特的鼠标事件和结果,是可以对应起来的,没有疑点。然而,在avf录像中额外存储了两个时间戳,格式如下:
开始时间戳:"dd.MM.yy.hh:mm:ss:????"
结束时间戳:"dd.hh:mm:ss:????"
以鞠帝的记录局,25.10为例,这是同时记录在avf文件中,以及鼠标事件中的,所以表面上avf是精确到厘秒。但是同时,上述时间戳的内容分别为:"3.8.2023.15:56:38:2276"、"3.15:57:03:3378",可以发现,最后四位实际上精确到了万分之一秒,即丝秒。
问题在于,avf文件中的精确到厘秒和丝秒的数值经常对应不上。鞠帝的记录局中,精确到厘秒为25.10,但精确到丝秒为25.1102。再以18201的记录局为例,分别为"18.10.2022.20:15:35:6606"、"18.20:16:24:8868",精确到厘秒为49.25,但精确到丝秒为49.2262,这就存在疑点,到底哪个更加精确?
此外,avf中的开始和结束的时间戳也没有时区信息,因此,这两个时间戳的误差可能达到12小时。
二、Clone 0.97的计时方法的疑点
Clone 0.97中,虽然根本没有存储时间戳,避免了出现两中原理计时结果不一致的疑点,但是其疑点直接体现在鼠标事件中。
以校长的记录局的rtime为例,雷网数据为37.82。但是当我们查看鼠标事件,开头为(删去第一个lr以后的鼠标移动事件): time = 0.0, mouse = "lc", x = 213, y = 164 time = 0.01, mouse = "mv", x = 116, y = 140 time = 0.01, mouse = "lr", x = 116, y = 140 time = 0.09, mouse = "lc", x = 177, y = 96 time = 0.18, mouse = "lr", x = 283, y = 91 …… ……
结尾为:
…… time = 37.68, mouse = "rr", x = 156, y = 224 time = 37.75, mouse = "lc", x = 144, y = 232 time = 37.82, mouse = "lr", x = 142, y = 232
发现没有,Clone 0.97中的rtime居然是从第一次lc(左键按下)开始的,而阿比特是从第一次lr(左键抬起)开始的。经过实验发现,Clone 0.97中,左键按下后,无论停顿多少秒,移动多少距离,文件中都固定记录成上述格式,即左键按下,0.01秒后瞬间移动到下一个位置,同时抬起。
可见,作者其实心里知道,正确的做法是,从第一次lr开始计时。
假如站在作者立场上,可能辩解称,mvf录像中,第一个lc其实是lr,你们所有人都解析错了(解析器和软件不是同一个作者)。
那么问题又来了,假如第一个lc是lr,那么第一个lr是什么?如果不考虑完整的一组按下、抬起,就没有必要加上嘛,假如这个时刻什么也没有发生,那岂不是凭空创造的事件?
所以无论这么说都对应不起来,解释不通,疑点重重。
而站在笔者这样的解析器+软件作者的立场上,基于实际经验倾向于认为,第一个lr是真实的,而第一个lc是为了形成完整的一组按下、抬起,为了编程方便凭空添加的。所以,所有录像的真实rtime应该比录像中记录的少0.01秒,即校长的记录局用时应该为37.81,其他mvf录像的rtime也都应该减去0.01秒。
这个问题不是笔者第一次发现,此处早有提到。认为是偶然出现的bug。
此外目前,解析录像文件的工具有3个实现,分别是: (1)作者国际网站长的minesweeper-rawvf (2)14512的flop播放器 (3)18201的工具箱
其中minesweeper-rawvf可以快速验证mvf录像中的时间问题。而工具箱可以在Rust、Python(Windows、Linux)、Javascript(bundler、nodejs)、Typescript(bundler、nodejs)、julia等语言/平台中,使用官方包管理器方便地安装和使用。
|
|