- Run the attached scenario. Alternatively, create and run a scenario with an event with a "regular time" trigger that triggers every 5 seconds, and a Lua script action that calls the UI_CallAdvancedDialog function.
- When the first dialog appears, try waiting until approximately 3 seconds after the dialog appears, then close the dialog. Watch the simulated time clock toward the top of the simulation window upon closing it.
- When the next dialog appears, try waiting more than 5 seconds, then close the dialog.
When a Lua dialog is displayed, the simulation is paused. When the dialog is closed, the simulation should resume at the same simulated time, and continue advancing at the same simulation rate.
Actual behaviour
When the simulation resumes upon closing the Lua dialog, simulated time rapidly advances to "compensate for" the time spent with the dialog open. For example, if the dialog opens at simulated time 0 seconds and real-life time 0 seconds, and is then closed at real-life time 3 seconds, the simulation advances rapidly to simulated time 3 seconds upon closing the dialog. Upon arriving at simulated time 3 seconds, the simulation proceeds at normal speed. As far as I understand, the simulation advances quickly until the simulated time catches up with the actual time.
This causes a significant problem when the dialog is left open for a duration longer than the interval between runs of the event that produces the dialog. For example, let the interval between dialog-generating events be 5 seconds. If the dialog opens at simulated time 0 seconds and real-life time 0 seconds, and is then closed at real-life time 6 seconds, the simulation advances rapidly toward simulated time 6 seconds upon closing the dialog. Before the simulation can arrive at simulated time 6 seconds, it first arrives at simulated time 5 seconds, upon which the event generating the dialog is run again. This causes the user to be immediately presented with a second dialog. When the interval between dialog events is short, this can quickly create an inescapable loop of dialogs.
Commentary
I discovered this issue while using Lua dialogs to display some information once per second to debug Lua scripts in a scenario. In my case, this immediately trapped me in an inescapable loop of dialogs: the first few dialogs took more than 1 second to read and close, and when I no longer wanted to see more dialogs, actual time had advanced far beyond simulated time. While a Lua dialog is open, it appears to be impossible to interact with any other parts of the Command user interface, including the pause button or the file menu. I had to close Command using task manager, causing all unsaved work to be lost. I suspect that other users engaged in scenario editing and Lua development can find themselves in similar situations.
This behaviour can be a problem even in more ordinary applications of Lua dialogs: even in the absence of an inescapable loop of dialogs, rapidly advancing the simulation after a dialog, especially a dialog on which a player may spend a long time making an important decision, deprives the player of the ability to control units during the "skipped" time. Tactically important events may occur in that time with no opportunity for player intervention.
I can think of two possible solutions to all this.
- The most straightforward option is to stop simulated time from rapidly advancing to "catch up" upon closing a Lua dialog. I suspect that this happens because the game is, in some sense, not properly paused during a Lua dialog: for example, the pause button is shown instead of the play button. Perhaps the game may be made to properly pause upon opening a Lua dialog, and then resume upon closing it. To prevent the part of the Lua script after the dialog function call executing at a different simulated time from the part before the call, the user can be prevented from unpausing while the dialog is open.
- The second option is to not pause the game at all while a Lua dialog is open. This would require the output of a dialog to be handled separately from the function call that opens it, which may complicate the API.