starred/PlayCover

Fork 0

mirror of https://github.com/PlayCover/PlayCover.git synced 2026-04-26 00:05:52 +03:00

[GH-ISSUE #379] [Bug] Virtual Mouse freezes when changing map in Genshin Impact in Nightly Build 85 #167

New issue

Closed

opened 2026-03-03 18:55:25 +03:00 by kerem · 3 comments

kerem commented

2026-03-03 18:55:25 +03:00

Owner

Originally created by @lushuyu on GitHub (Sep 26, 2022).
Original GitHub issue: https://github.com/PlayCover/PlayCover/issues/379

Describe the bug

Press ⌥ and open map and tp anywhere in Genshin
When loading, press ⌥ to use Virtual Mouse
Virtual Mouse freezed.
Press ⌥ twice and problem solved.

Steps to reproduce

⬆️

Expected behaviour

This bug does not exist in older versions.

I think in the latest version there is a persistent virtual touch in the "Virtual Mouse Area" during loading after pressing ⌥, so after loading is complete, the virtual touch does not work. In fact when the player has no input, this virtual touch should cancel.

Crash log

No response

What version of PlayCover are you using?

Nightly/beta

What version of macOS are you using?

Ventura (macOS 13)

Issue Language

Yes my issue is written in English

Originally created by @lushuyu on GitHub (Sep 26, 2022). Original GitHub issue: https://github.com/PlayCover/PlayCover/issues/379 ### Describe the bug - Press ⌥ and open map and tp anywhere in Genshin - When loading, press ⌥ to use Virtual Mouse - Virtual Mouse freezed. - Press ⌥ twice and problem solved. ### Steps to reproduce ⬆️ ### Expected behaviour This bug does not exist in older versions. I think in the latest version there is a persistent virtual touch in the "Virtual Mouse Area" during loading after pressing ⌥, so after loading is complete, the virtual touch does not work. In fact when the player has no input, this virtual touch should cancel. ### Crash log _No response_ ### What version of PlayCover are you using? Nightly/beta ### What version of macOS are you using? Ventura (macOS 13) ### Issue Language - [X] Yes my issue is written in English

kerem

2026-03-03 18:55:25 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-03 18:55:26 +03:00

Author

Owner

@XuYicong commented on GitHub (Sep 26, 2022):

This bug does not exist in older versions.

Does this happen to you in nightly 65 or 66? I think camera control code had not changed since then.

@XuYicong commented on GitHub (Sep 26, 2022): > This bug does not exist in older versions. Does this happen to you in nightly 65 or 66? I think camera control code had not changed since then.

kerem commented

2026-03-03 18:55:26 +03:00

Author

Owner

@IsaacMarovitz commented on GitHub (Sep 26, 2022):

@XuYicong I have been experiencing this slightly. I think it is due to the touch end/begin timing change. It seems not to register the touch begin event, clicking with the mouse or just waiting for a few seconds gets it to work again.

@IsaacMarovitz commented on GitHub (Sep 26, 2022): @XuYicong I have been experiencing this slightly. I think it is due to the touch end/begin timing change. It seems not to register the touch begin event, clicking with the mouse or just waiting for a few seconds gets it to work again.

kerem commented

2026-03-03 18:55:26 +03:00

Author

Owner

@XuYicong commented on GitHub (Sep 27, 2022):

I see, it may be a side effect of the aimming precision optimisation, which keeps the touch point pressed for at most 4s if mouse moves slow. If this is the case, you can get it to work again by moving your mouse fast.

The touch end/begin timing change seems not a cause of this. Current touch end threshold is 0.25s±0.05s, which is significantly shorter than "a few seconds". It would be better if anyone know how to end touch based on not time but something like a mouse being stationary event, or how to dynamically obtain GC event delivery frequency.

I'll redo the optimisation so that it no longer rely on mouse moving speed. Instead, it would scale the first moving event so that it exactly skips the starting cold zone.

@XuYicong commented on GitHub (Sep 27, 2022): I see, it may be a side effect of the aimming precision optimisation, which keeps the touch point pressed for at most 4s if mouse moves slow. If this is the case, you can get it to work again by moving your mouse fast. The touch end/begin timing change seems not a cause of this. Current touch end threshold is 0.25s±0.05s, which is significantly shorter than "a few seconds". It would be better if anyone know how to end touch based on not time but something like a mouse being stationary event, or how to dynamically obtain GC event delivery frequency. I'll redo the optimisation so that it no longer rely on mouse moving speed. Instead, it would scale the first moving event so that it exactly skips the starting cold zone.

kerem referenced this issue

2026-03-03 19:07:22 +03:00

[PR #167] [MERGED] In-app Xcode CLI Tools Install #1497