Player: Teleports using input key as Cancel open the menu staying blocked

[gadesx]

Name of the game: Test case

Player platform:

Windows 7 64bits

Attach files (as a .zip archive or link them)

Sample_problem_menuprohibition.zip

Describe the issue in detail and how to reproduce it:

Trying my old project I've seen that the Go to memorized map create a situation that open the menu first, staying as blocked. There's must be something that explain that different behavior that usually seems not happen with 2k3 and break custom menus.

Just open the menu with any key, referenced by 6 internally.

[fmatthew5876]

I did some testing of this in rm2k and this is a very subtle timing issue.

You can simplify the test case down to this code in a parallel event:

Key Input Processing [0001], Wait
Conditional Branch, Variable [0001] == 6
    Transfer Player Somewhere 
Branch End

In Player it will open the Menu first and then teleport you.

In rm2k3, it will teleport and never open the menu.
If you insert a Wait 0.0 before Transfer, rm2k3 will teleport and then open the menu immediately after.
If you insert a Wait 0.1 before Transfer, rm2k3 will open the menu and then teleport you.

[CherryDT]

If I remember correctly, it works along the lines of this:

each frame:
- event commands are executed until one requires waiting (such as the teleport)
- menu_calling is executed when it's set (but only if no blocking action is active)
- key trigger state is checked (setting menu_calling if necessary, but only if no blocking action is active)
- teleport is executed when it's pending

so, without wait, menu_calling is not set because the pending teleport is a blocking action (just like an open message box), then the teleport is executed
with wait 0.0, menu_calling is set, then next frame the teleport executes, and the following frame the menu is opened. (if there were an autostart event on the new map, the menu would not open.)
with wait 0.1 (or at least 2x wait 0.0), menu_calling is set, executes next frame, and only during one of the following frames [read: frames on the map] the teleport takes place.

Maybe I'm wrong though, that's just how I vaguely remember it. It is a bit convoluted unfortunately.

[CherryDT]

No, something was fishy here. menu_calling is cleared on teleport.

I see what it is now:

The game scene change is not instantaneous. During the main loop, the game decides which scene's code to execute. But a change of the scene of course takes place only next frame. Furthermore, the map scene automatically does a fade-out when it detects that the scene was changing during execution.

So what happens during the strange wait 0.0 case is that menu_calling is set, and in the next frame, menu_calling is executed, which changes the scene to menu. However, we are still in the map code - and it then executes the pending teleport and waits for it. Only afterwards, the frame is over and during the next frame, the menu pops up.

We can see that using one of my debug tools:

This is during the fade-out from the teleport. We can see that the teleport is in progress but the scene is already set to "menu".

[fmatthew5876]

This might be the same as or closely related to #1624

[fmatthew5876]

This must be due to #1691

In particular where cherry says

It is cleared when the player position changes by something other than movement (usually teleport)

So we need to handle menu_calling frame timing and clear it on teleport should fix this.

[fmatthew5876]

Fixed by #1714