[PATCH] Display units to queue without waiting for another turn

[elexis]

Sometimes when the game is laggy, it becomes apparent that you need to wait one turn in order to produce a batch of 5 units.

Reproduce in a multiplayer session where one player has paused. The other player won't be able to queue 5, despite pressing the shift-key.

(Or host a multiplayergame and type Engine.SetTurnLength(10000); to the JS console (F9) to produce 10 second long turns.)

[elexis]

Correction: 5 are queued, but its not displayed before the next turn!

[sanderd17]

This is part of the network model to guarantee deterministic execution. The commands are collected, and only executed on the next turn, which has a known time. There's no way you can know which command was first, when two players have a command at about the same time, but it took a while to reach the other players.

Only indirect solutions for this problem are possible, like blocking the gui when someone paused or reducing the lag.

So unless you prove me wrong with a deterministic patch, I'll close this as wontfix

[elexis]

The problem is if you pause the game with one client and then hold the shift key in the other client, it would schedule to queue 5 units on the same turn if you clicked the button, but not display that on that turn. However if you select the CC again while holding the shift key, it updates the GUI on the same turn and displays the correct number of units (five) that would be scheduled to be queued if you clicked the button.

Calling onSimulationUpdate() once in javascript is sufficient to update the GUI and fix the problem. onSimulationUpdate() is not only called when another turn is processed, but also OnTick. For example if one clicks somewhere, OnTick() will call onSimulationUpdate() and thus update the GUI.

The patch would technically fix the issue, but it is not optimized for performance (too many onSimulationUpdate() calls when not necessary). The solution with low performance impact would be to call onSimulationUpdate() once if a building that can produce units is selected and the shift-key state changes.

[elexis]

Same goes for bartering at the market.

[elexis]

This fixes the issue described above with less performance impact. It makes training units generally more responsive. Try pressing shift key many times, you will see that its only updated once per turn without the patch. One more patch to go before the ticket can be closed... (Display the units that will be queued on the next turn if the user started the production).

[elexis]

In 18416:

Improve bartering GUI responsiveness and immediately switch to the selected resource instead of waiting one turn. Refs #3194.

[elexis]

Should have mentioned that it was meant to be about showing the units to be trained, not the ones actually queued (The icon shows the number 5 if shift is pressed, otherwise no number).

The patch above just updates the GUI onTick instead of onSimulationUpdate, thus takes hotkey changes into account immediately.

The patch below updates the GUI only if one of the affected hotkeys is pressed or released, thus saves a relatively significant performance part.

[elexis]

With all debug warnings to investigate the bug when not calling HotkeyInputHandler.

[elexis]

release candidate