Once a new key is pressed, while the player was already holding another key, events will only fire for the latest key, as it uses normal OS behavior for holding down keys. When the player releases the latest key, events will NOT start firing for the previous one. This can cause a strange interaction:
Assuming a player is holding ctrl+shift to perform a certain mouse click action. They then want to perform a mouse action that requires only ctrl, so they let go of shift. After 0.8 seconds, OSKeys times out, because no events were being fired, and releases all keys; the game will no longer count ctrl as being held down, so the player will need to press it again.
A solution to this problem would be to only reset the keys if the latest key was NOT released. When alt-tabbing, wc3 does not register the latest key pressed, so this would work. Also, might as well implement use BlzIsLocalClientActive for multiplayer purposes.
Multiple Keys
Once a new key is pressed, while the player was already holding another key, events will only fire for the latest key, as it uses normal OS behavior for holding down keys. When the player releases the latest key, events will NOT start firing for the previous one. This can cause a strange interaction:
Assuming a player is holding ctrl+shift to perform a certain mouse click action. They then want to perform a mouse action that requires only ctrl, so they let go of shift. After 0.8 seconds, OSKeys times out, because no events were being fired, and releases all keys; the game will no longer count ctrl as being held down, so the player will need to press it again.
A solution to this problem would be to only reset the keys if the latest key was NOT released. When alt-tabbing, wc3 does not register the latest key pressed, so this would work. Also, might as well implement use BlzIsLocalClientActive for multiplayer purposes.
Windows settings