[PATCH] Hotkey detection fails under heavy load

[zoot]

Steps to reproduce (YMMV):

1. Start a match against 7 Aegis bots and set the sim rate to 10x or higher to cause heavy load. The game should be stuttering.
2. Use cheats to stock up on resources and population capacity.
3. Select the civic center, hold the batch train hotkey (Shift), press Z twice and immediately release the batch train hotkey.

What happens: Training of two female citizens is queued.

What should happen: Since the batch train hotkey was held down, training of two batches of female citizens should have been queued.

[zoot]

I imagine some kludgy use of Engine.HotkeyIsPressed() is at fault here. You press Z, but due to the stuttering, by the time the game gets around to processing the key press, you have already released the batch train hotkey and so Engine.HotkeyIsPressed() returns false.

It would probably be better to detect "Shift+Z" as one event than just detecting "Z", then waiting, and then checking whether "Shift" is pressed.

On a more general note, it should be considered whether other situations where Engine.HotkeyIsPressed() is used are also affected.

[Josh]

RedFox redid the hotkey system to use a more efficient memory profile and apparently fixed this issue in his memory patch. I have separated out the relevant changes and attached them.

[Josh]

Patch by RedFox

[Jorma Rebane]

I think it's safe to close this ticket, since the code will be committed to A15 anyways. Thanks for opening a ticket for it though.

[Philip Taylor]

Not fixed - I can reproduce this even with the megapatch applied.

The problem is that the hotkey system receives key up/down events from the SDL event queue, updates its g_HotkeyStatus immediately, and pushes the hotkey up/down onto the back of the event queue. If the queue starts as [shift-down, z-press, shift-up], the hotkey triggered by z-press will go onto the end of the queue, and be processed after g_HotkeyStatus has been updated by the shift-up.

A similar problem occurs when hotkeys are interleaved with mouse events - if the key event is before the mouse event but in the same frame, the key's hotkey event will be pushed after the mouse event.

Hotkey events ought to be processed immediately, not pushed to the end of the queue.

[philip]

In 14057:

Improve correctness of hotkeys at low framerates.

SDL queues up all the input events received in a frame. When the hotkey system saw a key up/down event, it immediately updated its HotkeyIsPressed state and then pushed a hotkey event onto the end of the queue.

If the initial queue was e.g. [key-down shift, key-press Z, key-up shift], the hotkey event triggered by Z would be processed after the key-up shift had updated the HotkeyIsPressed state, so the handler of the Z hotkey would not think the shift hotkey was pressed.

If the initial queue was e.g. [key-press Z, mouse-click], the hotkey triggered by Z would be processed after the mouse-click event, so it could apply to the wrong building selection.

Fix by pushing the hotkey events onto a special queue that gets processed before any subsequent SDL input events.

Also update the HotkeyIsPressed status when the HOTKEYDOWN/HOTKEYUP events are processed, not when they are generated, to guarantee they are consistent with the DOWN/UP events.

Fixes #1869.