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

Calling multiple scenes on the same frame has wrong behavior #1642

Open
fmatthew5876 opened this issue Feb 18, 2019 · 13 comments

Comments

@fmatthew5876
Copy link
Contributor

commented Feb 18, 2019

Create 2 parallel map events with this code:

OpenSaveMenu
EraseEvent

Start a new game on the map.

In RPG_RT, the save menu will be called only once ❗️ and then both events dissapear.
In Player, the save menu is called, then EV1 dissapears, save menu, EV2 dissapears.

This also happens if you teleport into the map.

@fmatthew5876

This comment has been minimized.

Copy link
Contributor Author

commented Feb 18, 2019

This is very much like #1624,

If you use different menus here, only the menu called by EV2 actually appears.

What must be happening is this:

  • Frame 1
    • EV1 runs, sets flag to call menu and then returns
    • EV2 runs, set flag to call different menu (overwriting the first), and then returns
    • The menu triggered by EV2 runs
  • Frame 2
    • EV1 runs, erases itself
    • EV2 runs, erases itself.

The only special case are battles.

If you setup the events as Battle, Menu, the screen does a battle transition (with sound effect) and then calls the menu. This is an RPG_RT bug ❗️

If you setup the events as Menu, Battle, a battle is started the menu never called.

From Cherry's comments in another issue, my suspicion is its actually using SaveSystem::scene and changing the scene. I can't verify that using my save game method however.

@Ghabry

This comment has been minimized.

Copy link
Member

commented Feb 19, 2019

Do you plan to emulate such bugs that depend on a race with the SaveSystem::scene variable? This is very ugly and completely incompatible with our scene-stack code imo.

@fmatthew5876

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2019

For accurate frame timing in the interpreter we must emulate this behavior. If we call the menu twice we start adding extra frames which can break other things.

So I will emulate the observed behavior of "call the last scene requested by all parallel events that ran in this frame."

This can be done with SaveSystem::scene or just use a single enum variable instead of the set of flags we have now.

I will of course not emulate the transition bug

@Ghabry

This comment has been minimized.

Copy link
Member

commented Feb 19, 2019

I read the issue again and now I understand it, this looks much more sane than #1457 , thought this is the same uglyness.

@fmatthew5876

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2019

We don't actually manipulate the scene stack until we're done running events for the current frame. So it's not that bad, just need to store and overwrite only one "call this scene" variable during interpreter run.

@fmatthew5876 fmatthew5876 changed the title Parallel events timing issue when start new game Calling multiple scenes on the same frame has wrong behavior Mar 2, 2019

@fmatthew5876

This comment has been minimized.

Copy link
Contributor Author

commented Mar 3, 2019

The gameover scene also exhibits this behavior!

  1. Create parallel event EV01 with
GameOver

Create parallel event EV02 with

CallMenu

Start a new game, the menu is called.

  1. This one is more fun

Change EV01 to

Change HP: Party -9999, allow death

The menu is called and game over is averted!

Return to title is not affected by this! A call to return to title seems to happen immediately.

@CherryDT

This comment has been minimized.

Copy link

commented Mar 4, 2019

The gameover scene also exhibits this behavior!

Yes, it should be the same for all scene changes, also "change hero name", "open shop", ...

Return to title is not affected by this! A call to return to title seems to happen immediately.

Yes because this throws an exception (in order to cancel out of whatever code is running) which then resets the whole game, same as F12 does.

Change HP: Party -9999, allow death

Basically it also just triggers a game over, so that's expected, but this way I found two interesting things, actually bugs.

  1. If you have parallel event 1 open the menu and then parallel event 2 deduct the HP (instead of doing it the other way round), there will still be no game over! Which is because the game over check is done at the end of the actor-modifying commands only if the current scene is "map", and in this case it's already "menu". (I believe the original idea here is that it should not trigger a game over during battle, because in that case, the battle screen's logic should handle it and make you lose the battle.)

  2. In general, you get very funny things when doing two scene changes in the same frame which come with more than just a change of the scene variable. Especially battle and game over are interesting, since they both change the music and have an additional effect (battle does the sound effect, flashing and transition; game over just does a fade-out). Try putting "Start Battle" in EV01 and "Call Menu" in EV02, both as parallel process, and then see what happens! Very funny. Even funnier when that's the first thing in a new game and it's executed before the map fades in. Oh, and then try exiting the menu. Also note that the fade-in of the menu is then missing. And of course it messes up the event that called the battle because you are now outside of the battle without either winning or losing it, and of course the music is still playing, etc. - Well.

(You can add more such parallel events... then you can get any number of battle start sounds, and if you sprinkle "game over"s between the battles, you also get the effect of the battle music restarting... isn't it fun playing with bugs...)

@carstene1ns carstene1ns added this to the 0.6.1 milestone Mar 5, 2019

@fmatthew5876

This comment has been minimized.

Copy link
Contributor Author

commented Mar 5, 2019

I haven't handled the game over edge case yet, so let's reopen this one.

@fmatthew5876

This comment has been minimized.

Copy link
Contributor Author

commented Mar 12, 2019

Here is another case for battles.

Setup EV01 parallel with:

Wait 0.0s
Battle Grassland1
If won: Var1 = 1
If esc: Var2 = 1
If lose: Var3 = 1
Var7=1
EraseEvent

Setup EV02 parallel with:

Wait 0.0s
Battle Grassland2
If won: Var4 = 1
If esc: Var5 = 1
If lose: Var6 = 1
Var8=1
EraseEvent

Start a new game

Result:

Grassland 2 battle runs. After the battle, the screen stays black until you enter and exit the menu.
If you won: Var4==1, Var7=1, Var8=1
If you esc: Var5==1, Var7=1, Var8=1
If you lost: Var6==1, Var7=1, Var8=1

Conclusion

There is this black screen issue when you abuse event battles that has already been reported elsewhere. We will fix this player.

More importantly, when you trigger multiple battles in the same frame, only the last battle is actually triggered. Futhermore, only the event that triggered that battle actually reacts to the battle results. The other event just skips ahead past the battle it called and continues on to the next command.

@fmatthew5876

This comment has been minimized.

Copy link
Contributor Author

commented Mar 16, 2019

How about messages an scene calls?
Setup 2 parallel events

EV01 EV02 show_message chunk Result
Message game over Message, and then game over
game over message message box appears briefly ❗️ , game over
open save menu message 1 message box appears briefly ❗️ , save menu called, message appears
Message open save menu 0 Message, and then save
@Ghabry

This comment has been minimized.

Copy link
Member

commented May 5, 2019

are there still open issues here?

@fmatthew5876

This comment has been minimized.

Copy link
Contributor Author

commented May 5, 2019

I'm not sure if go to title scene is implemented right. Need to check that one.

I also want to recheck all the things here in master once PR's are merged.

@Ghabry Ghabry removed the Needs feedback label May 5, 2019

@Ghabry Ghabry modified the milestones: 0.6.1, 0.6.2 May 5, 2019

@fmatthew5876

This comment has been minimized.

Copy link
Contributor Author

commented May 31, 2019

Title screen and exit game are handled by #1784

We still need to fix continuations so that only the event that triggered the scene that actually was called reacts to the scene results. Other events which called a scene and got overwritten skip over the conditions of the scene results.

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