Opened 9 years ago
Last modified 5 years ago
#3194 closed enhancement
[PATCH] Display units to queue without waiting for another turn — at Version 9
Reported by: | elexis | Owned by: | |
---|---|---|---|
Priority: | Should Have | Milestone: | Alpha 22 |
Component: | Core engine | Keywords: | patch |
Cc: | Patch: |
Description (last modified by )
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.)
Change History (13)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Milestone: | Backlog |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
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
comment:3 by , 9 years ago
Milestone: | → Backlog |
---|---|
Resolution: | wontfix |
Status: | closed → reopened |
by , 9 years ago
Attachment: | t3194_proof_of_concept.patch added |
---|
comment:4 by , 9 years ago
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.
comment:5 by , 9 years ago
Summary: | Allow queuing units with shift-click without waiting for another turn → Display queued units without waiting for another turn |
---|
by , 9 years ago
Attachment: | t3194_display_units_to_queue_on_same_turn.patch added |
---|
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).
comment:8 by , 8 years ago
Keywords: | patch review added |
---|---|
Milestone: | Backlog → Alpha 21 |
Summary: | Display queued units without waiting for another turn → [PATCH] Display units to queue without waiting for another turn |
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.
by , 8 years ago
Attachment: | gui_hotkey_release_event_v1_debug.patch added |
---|
With all debug warnings to investigate the bug when not calling HotkeyInputHandler
.
comment:9 by , 8 years ago
Description: | modified (diff) |
---|
Correction: 5 are queued, but its not displayed before the next turn!