[LUA] rttr:MissionStatement can continue game

[Spikeone]

Although the game pauses when you set the pause parameter to true, you can just continue by pressing P. This was possible in the original as well but it feels like a bug as you can not force reading the window before opening an other window.

[Flamefire]

You never can force anyone to read that window. If they choose to continue via P then why not? I don't think it is worth the effort to implement an extra "forced pause"

[Spikeone]

Well, in my use case:

I want to tell the user, that this is the tutorial etc. and everything will be explained and so on. Sadly the next message is also triggered by GF - so user keeps reading or just doesnt close the window and an other window is shown over it.

My other use case is: I use the MessageBoxEx to display images, sadly the mission statement wont block stuff so the next messageboxex is just shown as everything is triggered on gameframes. I do not really mean to force somebody to read stuff, but to actively click "continue".

If it's really that hard to implement, well bad luck, everybody gets the same maximum amount for reading then ;)

[Flamefire]

I don't understand: The game pauses when that message is shown. The user has to actively press the button or P to continue. So where exactly is the problem? That there is another way to continue besides pressing that button?

MessageBoxEx is another thing and you already opened #943 to pause the game for them too. But the same applies: A user action is required to continue.

[Spikeone]

Thats correct - but if the user presses P to continue, I can not ensure that an other window is overlaying the current text, thus I can not make sure the user reads (if he does) everything in order. While pausing makes sure of that, pressing P does not. Wont happen often, not saying that, but it's possible.

I also agree, that when message boxes can pause the game, it is very unlikely that it will happen, that a user presses P while reading, thats why it's just an enhancement. Still would ensure more reliable mission statements as mission statement a) needs to be closed before mission statement b) could be shown - so everything is in order for sure. Hopefully I could describe my problem better this time :)

[baka0815]

I can not ensure that an other window is overlaying the current text

Can you ensure this if the user opened another window previously or could that also be overlaying your window?

[Spikeone]

As the latest opened window overlays any other window - yes. Problem for me is the following:

Show missionstatement/msgbox a) after has been closed (either user read the text or hit ok) I do not want to immediatly show the next window (e.g. I told the user how to open the map and stated he should play around with the feature). The next window then explains how to use the build aid mode.

The user now hits P after the first statement / msgbox has been shown - thus my "play around" delay will just pass and then my 2nd statement is shown. As those are not the same size (or position) it looks quite weird. In most cases statements are event driven, which means they can nearly always avoid the problem. But for statements that are not driven by events but by time, it'd be quite nice to know if a statement is still shown or not.

Thats actually another way to work around that problem: If could ask if there are still open msgBox or missionstatement I could just delay my next window further.

Overall everything will work without that change and if @Flamefire actually adds a pause parameter for the messagebox only players who press P can "mess up" messages. One could argue their bad, not our problem and thats the exact reason why I only think this would be an enhancement and not a bug or something else.

[Flamefire]

Other solution:

• Add a pause/unpause option to lua
• Add a "windowClosed" callback for lua opened windows
• Remove pause param from windows

Then you can do what you want. I'd go as far as opening a window gives you a ID which is valid till the window is closed. So you can see which window was closed.

Note: Pause in multiplayer can prove problematic, but that is valid already.

[Spikeone]

Well that'd be great as well and would solve the problem as well :)

When you are talking about window IDs - wouldn't it be possible to also create a "onWindowShown" event or something similar so one could actually check if the player made a certain action. That'd be helpfull for better tutorials but isn't needed as there is only one use case.

[Flamefire]

IDs in that case would be e.g. memory adresses of the window instance. Nothing meaningful just unique for the lifetime of the window.

For your 2nd suggestion we would need unique IDs for each window type (which we partially have, but I feel that exposing them to lua would be to much and error prone...)

[Spikeone]

One also needs what type those windows are off - an unique ID does not help much, at least even I can't think of any use case. But thats something else. The solution you mentioned above should solve any problems I can think off.

[Flamefire]

It does: You open a window from lua and get an ID. Then you can check for that ID when it is closed

For your onWindowShown this is what I meant: We need meaning for those IDs so each type of window gets its on type ID. This is much more work, although I think we already have something like this...