fix: 修复密集输入时，实际执行时间比期望值略长的问题

[zzyyyl]

引入一个理想当前时间 expectedNow, 表示执行 waitEvent(milis) 时应该等待至 expectedNow + milis 而不是 now + milis

[aa889788]

我没看具体错误，如果在commit wait的时候加上当前timestamp会怎么样？

[zzyyyl]

我把之前发给玛丽的一张图贴在这里：

[aa889788]

我把之前发给玛丽的一张图贴在这里：

我不清楚这样能不能解决问题？

[zzyyyl]

我觉得不行。主要是 maatouch 这边执行其它操作也是有时延的（例如 move、up、down等），但是 MAA 那边默认是理想状况无操作时延的

[aa889788]

我觉得不行。主要是 maatouch 这边执行其它操作也是有时延的（例如 move、up、down等），但是 MAA 那边默认是理想状况无操作时延的

parse本身的delay应该是可以忽略的吧，或者我把我这里编译的发给你看看还会不会有问题？
app-release-unsigned.zip

[aa889788]

我觉得不行。主要是 maatouch 这边执行其它操作也是有时延的（例如 move、up、down等），但是 MAA 那边默认是理想状况无操作时延的

想了想，你这样的实现还会有一个问题，比如：

down 0 x y
wait 50
move 0 x y
wait 50
move 0 x y
wait 50
up 0
commit

这样的指令理应是合法的，但是有了sync timestamp之后，就只有第一次wait能够生效，后续的wait都会不再起效

[zzyyyl]

parse的delay可能影响不大，但是controller那边的delay好像影响挺大的（

[zzyyyl]

我觉得不行。主要是 maatouch 这边执行其它操作也是有时延的（例如 move、up、down等），但是 MAA 那边默认是理想状况无操作时延的

想了想，你这样的实现还会有一个问题，比如：

down 0 x y
wait 50
move 0 x y
wait 50
move 0 x y
wait 50
up 0
commit

这样的指令理应是合法的，但是有了sync timestamp之后，就只有第一次wait能够生效，后续的wait都会不再起效

是的，所以我现在修了：fix: timestamp 在 ControlThread 处理信号的时候才同步
而且我还想出了第二种方案： fix: 除非 reset，期望当前时间不允许倒流

我自己觉得第二种更好一点，因为这么写不用改 MAA 那边的代码.jpg

[aa889788]

我觉得不行。主要是 maatouch 这边执行其它操作也是有时延的（例如 move、up、down等），但是 MAA 那边默认是理想状况无操作时延的

想了想，你这样的实现还会有一个问题，比如：

down 0 x y
wait 50
move 0 x y
wait 50
move 0 x y
wait 50
up 0
commit

这样的指令理应是合法的，但是有了sync timestamp之后，就只有第一次wait能够生效，后续的wait都会不再起效

是的，所以我现在修了：fix: timestamp 在 ControlThread 处理信号的时候才同步 而且我还想出了第二种方案： 31b5289

16bbbd3
我的这种方案没法解决问题吗？

[zzyyyl]

你这样应该相当于只解决了wait操作的延时，没解决up/down/move的延时吧

[zzyyyl]

主要是MAA的需求是：

move x y
wait 2
move x y
wait 2
...
move x y
wait 2
(以上 200 个move & wait）
commit

这样的操作期望延时应该是 400ms，而不是 400ms + move_system_delay * 200

[zzyyyl]

16bbbd3 我的这种方案没法解决问题吗？

要不把 ci 合进去（

[aa889788]

主要是MAA的需求是：

move x y
wait 2
move x y
wait 2
...
move x y
wait 2
(以上 200 个move & wait）
commit

这样的操作期望延时应该是 400ms，而不是 400ms + move_system_delay * 200

没有啊，因为input和controller是两个线程，wait这样改了之后可以保证wait完的时刻是相对输入时刻对齐的，也就是wait前指令的延迟都会被包含在内，最终多出来的就只会有最后一条指令的额外延时

[aa889788]

而且现在MaaCore也是每条指令后都会commit，也就是

move 0 x y
wait 2
commit
move 0 x y
wait 2
commit

这样的

[aa889788]

我才发现是不是有点不对？为啥是先commit再wait的！？

[zzyyyl]

我才发现是不是有点不对？为啥是先commit再wait的！？

@MistEO

[aa889788]

话说你改过的版本试过了么？现在Maa dev分支的我怎么彻底划不了屏了？

[zzyyyl]

话说你改过的版本试过了么？现在Maa dev分支的我怎么彻底划不了屏了？

• fix: 修复 maatouch 滑动 MaaAssistantArknights#6981
  你可以先试试 fix/maatouch 分支，dev 群里不是好多人说炸了（

• fix: 修复待选干员在列表末尾时点击错位的问题 MaaAssistantArknights#6960
  这个我自己当时是试过的，能用.jpg

[aa889788]

话说你改过的版本试过了么？现在Maa dev分支的我怎么彻底划不了屏了？

• fix: 修复 maatouch 滑动 MaaAssistantArknights#6981
  你可以先试试 fix/maatouch 分支，dev 群里不是好多人说炸了（
• fix: 修复待选干员在列表末尾时点击错位的问题 MaaAssistantArknights#6960
  这个我自己当时是试过的，能用.jpg

想了一下，其实最好的解决方案是用Maf那边的方法，每次move都commit，然后core这边用sleep做延时，这样延时就基本不会错特别多了

[zzyyyl]

想了一下，其实最好的解决方案是用Maf那边的方法，每次move都commit，然后core这边用sleep做延时，这样延时就基本不会错特别多了

MAA 现在就是这样的吧（？
主要是 core 的 sleep 是所有的 wait 时间之和，但是事实上操作延时很大

[aa889788]

想了一下，其实最好的解决方案是用Maf那边的方法，每次move都commit，然后core这边用sleep做延时，这样延时就基本不会错特别多了

MAA 现在就是这样的吧（？ 主要是 core 的 sleep 是所有的 wait 时间之和，但是事实上操作延时很大

不，我的意思是

move 0 x y
commit 
------------
std::this_thread::sleep(2)

这样基本可以保证延时差别不会太大

[zzyyyl]

不，我的意思是

move 0 x y
commit 
------------
std::this_thread::sleep(2)

这样基本可以保证延时差别不会太大

这样200次之后差距还是会叠加啊（

[aa889788]

不，我的意思是

move 0 x y
commit 
------------
std::this_thread::sleep(2)

这样基本可以保证延时差别不会太大

这样200次之后差距还是会叠加啊（

没有，move是maatouch处理的，sleep是core做的，move的时候只要不wait，那基本不可能长于2ms的，这样sleep时间基本就完全被core控制了

[aa889788]

不，我的意思是

move 0 x y
commit 
------------
std::this_thread::sleep(2)

这样基本可以保证延时差别不会太大

这样200次之后差距还是会叠加啊（

没有，move是maatouch处理的，sleep是core做的，move的时候只要不wait，那基本不可能长于2ms的，这样sleep时间基本就完全被core控制了

就是这样

[zzyyyl]

奥，你的意思是完全不调用 maatouch 的 wait

[aa889788]

奥，你的意思是完全不调用 maatouch 的 wait

对，主要maatouch和minitouch的wait实现是不一样的，maatouch是用队列交到controller来sleep，而minitouch是收到wait直接在主线程里sleep，我怀疑这就是minitouchcontroller里先commit再wait的原因

[aa889788]

奥，你的意思是完全不调用 maatouch 的 wait

对，主要maatouch和minitouch的wait实现是不一样的，maatouch是用队列交到controller来sleep，而minitouch是收到wait直接在主线程里sleep，我怀疑这就是minitouchcontroller里先commit再wait的原因

我新写的thriftcontroller和playtools都是这么实现的

[zzyyyl]

您要不先测测现在的（

[aa889788]

您要不先测测现在的（

我现在的测着没遇到啥问题

[aa889788]

主要我也没遇到过那个bug，也不知道怎么复现，现在在想三种解决方法哪个更好一点
感觉直接改core那边解决的应该是最彻底的，在maatouch这边改都有点治标不治本的感觉

[aa889788]

https://github.com/MaaAssistantArknights/MaaAssistantArknights/tree/fix/maatouch-delay
你如果能复现的话试一下这个能不能解决

[MistEO]

这个还合不合了（