GUI not updated when popup is shown

[Karamel]

Progress in UI panel is not updated when a popup is shown on the screen.

For example (see picture), I ordered to train a female citizen in CC and clicked on delete building. While the confirmation popup is shown, the green progress bar is frozen. I waited until she appeared next to the CC, the production queue didn't update, it should be empty at that time (red circles on picture).

An other example while a building is being captured. Loyalty bar is not updated while the popup is shown.

Checked on r16555

[Karamel]

Progress bar is full while the unit is trained.

[elexis]

Maybe updating the panel onTick fixes the issue (didnt test though)

​http://trac.wildfiregames.com/attachment/ticket/3194/t3194_display_units_to_queue_on_same_turn.patch

[Karamel]

I tried the patch and can see the difference (no lag in display when pressing Shift briefly for batch) but it doesn't fix the popup issue.

updateSelectionDetails() doesn't seem to do the trick. I tried disabling "if(!g_SimState) return;" in onSimulationUpdate to run all the update* but it doesn't work either.

[elexis]

Calling onSimulationUpdate() onTick works, but I didn't check which part updates that progress bar.

[Karamel]

Game time is not updated as well. Doing onSimulationUpdate seems to correct everything but looks like an ugly hack and performance consuming (it is called when g_selection.dirty is true but time update is not related to selection) :)

session.xml indicates that onSessionUdate should be called on session update. I checked quickly sources/ps/Game.cpp and sources/network/NetTurnManager.cpp but haven't found an exception for when a popup is shown.

By the way the option screen shows the same black fader but also pauses the game (at least on local game). Could it be related?

[elexis]

By adding error("test"); to onSimulationUpdate(), it becomes obvious that this function not be called if you have opened the delete-unit popup or are in the settings. Consequently neither that progress bar nor the ingame time will be updated. Probably the updates won't reach session.xml if there is another window opened.

You can also ask questions on the developers chat: ​https://webchat.quakenet.org/?channels=0ad-dev

[sanderd17]

The options screen deliberately pauses the game, so you have time to modify your settings (for singleplayer at least, not for multiplayer).

Small popups should usually be quickly away again, so it's normal that the game isn't paused, and the GUI should indeed be updated.

I guess the simulation update arrives at the popup window, rather than the underlaying simulation. So perhaps the easiest way to update the gui is to forward the function when received?

[elexis]

I can see now why this issue is relevant.

When I played a svn game, the enemy was capturing my tower. I wanted to delete the building before it was captured. But since the capture progress bar is not updated while the delete popup box is displayed, you don't know when to delete the building and its probably captured before you can delete.

[elexis]

Sander's hypothesis is correct. The OnSimulationUpdate event arrives at the message window instead of session.xml. I dont know (yet) how to forward this to the correct window.

[Imarok]

Move tickets to In-game UI as UI & Simulation got some sub components.

[Freagarach]

Still present in A23b, but now fixed. (Possibly by r23076? @elexis, you might remember which commit it was. I've tried backtracing it but to no avail. (Spend way too much time on that already.))

[elexis]

Fixed by ​Phab:D1701 / r22200 (actually not sure, didn't test)

[elexis]

I know there was something else.

Actually fixed by r23138.

[Freagarach]

Thanks for bisecting the relevant commit @elexis!

[elexis]

(Didn't bisect, would take way too long, but svn-blamed the code for SimulationUpdate (Game.cpp) and then svn-blamed the SendEventToAll call. Bisect is only useful if one has no clue at all and really wants to find something and noone else with recollection of what might have introduced something is around. And sometimes bisecting can be faster than testing hypothesis of which code could have fixed it. Thanks for the work on the tickets!)