Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Teleports using input key as Cancel open the menu staying blocked #1457

Closed
gadesx opened this issue Oct 18, 2018 · 6 comments

Comments

@gadesx
Copy link

commented Oct 18, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2018

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

This comment has been minimized.

Copy link

commented Oct 22, 2018

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

This comment has been minimized.

Copy link

commented Oct 22, 2018

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:
image
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 comment has been minimized.

Copy link
Contributor

commented Feb 17, 2019

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

@fmatthew5876

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2019

Fixed by #1714

@Ghabry Ghabry added this to the 0.6.1 milestone Apr 30, 2019

@Ghabry Ghabry closed this in #1714 Apr 30, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.