-
Notifications
You must be signed in to change notification settings - Fork 78
[GEN][ZH] Unblock keyboard input on CRC mismatch #1209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
[GEN][ZH] Unblock keyboard input on CRC mismatch #1209
Conversation
The new change doesn't make the mouse visible, but I think that's ok. It does unblock keyboard input, so pressing ESC works again. Opening the options menu always makes the mouse visible. |
@@ -3779,6 +3779,9 @@ void GameLogic::pauseGameMusic(Bool paused) | |||
// ------------------------------------------------------------------------------------------------ | |||
void GameLogic::pauseGameInput(Bool paused) | |||
{ | |||
// unblock keyboard input if blocked by scripts | |||
TheWindowManager->winSetFocus(NULL); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this implementation correct? I think this means that when continuining the sequence, then input remains unblocked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this implementation correct? I think this means that when continuining the sequence, then input remains unblocked.
Is that an issue? I could make it for replays only, but I doubt it's needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be possible to detect current state, overwrite it, and then revert state when done. This way there will be no unexpected bugs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is unnecessary when playing replays. In fact, I'd rather have the keyboard never blocked for replays.
We could just check if we're in replay mode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok but that is a different area of concern right? Touching setGamePaused only concerns how the pausing handles the inputs, not if the inputs already changed before that.
The correct fix here is to make setGamePaused universially robust. It does not care about the context it is called from. It just applies its desired effect from whatever context - when possible.
I noticed this issue with a custom map that has a scripted intro readme that stays put for a couple of seconds. Keyboard input is ignored and the mouse cursor is hidden for the duration of the readme. If a replay CRC mismatch is detected during the showing of the readme file, the game is paused and it's annoying to get out of it because user input remains limited.
This PR checks the mouse visibility and if the mouse cursor is hidden on CRC mismatch, the options menu is toggled instead of pausing the game.