Leaving the menu back to a dialog choice crashes

[Doktor_Q]

If you open a choice (specifically, the "show choice" event), then open the menu screen using a parallel process, RPGMaker crashes upon closing the menu.


Replicated in a clean project, minimalist example here, using only vanilla events. Talk to the NPC, and while the choice is showing press 'pageup' to trigger the parallel event in the corner and open the game menu over top of it. Try to close the menu and it immediately crashes.


Error report:

Spoiler

    Pixi.js 4.0.3 - ✰ WebGL ✰      http://www.pixijs.com/



rpg_managers.js:1756 TypeError: Cannot read property 'bitmap' of undefined
    at Window_ChoiceList.Object.defineProperty.get (rpg_core.js:5848)
    at Window_ChoiceList.textWidthEx (rpg_windows.js:3905)
    at Window_ChoiceList.maxChoiceWidth (rpg_windows.js:3896)
    at Window_ChoiceList.windowWidth (rpg_windows.js:3872)
    at Window_ChoiceList.Window_Command.initialize (rpg_windows.js:1296)
    at Window_ChoiceList.initialize (rpg_windows.js:3824)
    at new Window_ChoiceList (rpg_windows.js:3816)
    at Window_Message.createSubWindows (rpg_windows.js:4271)
    at Window_Message.initialize (rpg_windows.js:4249)
    at new Window_Message (rpg_windows.js:4236)rpg_managers.js:1756 SceneManager.catchException

Illustrative screenshots:

Spoiler

 

[Shaz]

My question would be why you have a parallel process event that opens a menu, while you have a choice box showing?  The code specifically limits (or attempts to limit) what you can do while message boxes are showing, and using a parallel process might cause problems with that.


I seem to recall this being mentioned once before, and I think it might have been Ace.

 

[Andar]

Can you show us the events and parallel processes that caused this?


I also think that error is caused by something you have done inthose events, not a bug in the engine - there are several ways a parallel process can create timing problems in the game loop, and some of them can cause crashes as well (for example when trying to access a picture that is already erased by another command.


There is a reason why we say that parallel processes should only be used where neccessary, and unfortunately too many users think that parallel processes can work miracles.


They don't, and a lot of problems are caused by them.

 

[Doktor_Q]

@Shaz For my project, I've been working on "visual novel style" towns. Instead of a full map, you use a menu to go between shops, pick people to talk to, etc. I'd like the player to still be able to get to their menu in town, but by the nature of the beast there's pretty much always a choice open (where to go next).


@Andar I made the events as bare-bones as possible for the conditions. Screenshots:

Spoiler

I can definitely make a workaround, and theoretically I could write a bandaid patch to stop this from crashing if I was determined, but I'm a bit worried that I could make it crash with just these two commands.

 

[Andar]

I think the only "workaround" you'll need is adding a wait(5) or so to that parallel process.


If you check the forum, you'll learn that the parallel processes should never run without a wait, because that simply causes too much lag and timing problems.


Because the wait command internally works by telling the game loop to stop processing that event for the number of frames given (unless you're not looping the parallel but switching it off after one run).


Without a wait, the engine runs each parallel process sixty times per second - no player can press the button that often, because that is physically impossible without destroying the keyboard.


So with a wait(5), the parallel process will only check ten times per second, and that should make your game stable again.


Sometimes you'll need to experiment with the exact number of waits - too few and the game will lag and get timing problems, too many and the engine might miss a key press (or whatever the parallel checks)

 

[Doktor_Q]

@Andar It still crashes. Tested various placements of the 'wait' and various timings, from 1 to 10 frames, start of the parallel event, end of the parallel event, even inside the conditional just in case, and various combinations thereof.


From a cursory look at the code pointed out by the error messages, it's trying to reinitialize the choice after the menu closes, but fails to find the Window._windowContentsSprite when determining the maximum width the text can use. It seems like it might be an issue with how it switches between scenes, but I haven't delved deeply into that bit.

 

[Shaz]

The wait in a parallel process is usually not done when you're checking for button presses.  I think that has to detect the very moment you press the button, rather than detecting that you're holding it down.  


If you have a wait, I'd make it just 1 frame.


However, I'd condition the menu opening to do it only if there's not a message open.  This mimics what the interpreter does - it waits for messages to close before allowing some things to continue.  Something like this might be worth trying:

If Button PageUp is pressed down
  If Script: !$gameMessage.isBusy();
    Open Menu Screen
  End
End

That should prevent you opening the menu when there is a message window or a choice window open.

 

[Doktor_Q]

The check is key down, not key pressed- that is, "is the input currently down". Holding it will trigger again as soon as it can. It seems to work fine if there's normal messages open, just not when there's a choice up.


That said, if I prevent the menu from opening when there's a choice up, it doesn't do what I wanted it to do, which is allow the player to open their menu over the top of another "menu" created with dialog choices, since they might want to say, check their status to see if they need to rest at the Inn before they leave town.