Attempting to move during a loading screen makes the room never load
Closed this issue · 10 comments
Specifically, the room never fades in. I got as far as "changeRoomRemote keeps getting called" before giving up.
http://i.imgur.com/tHbKt.png is the process. The room fades out, hasControl() starts returning true, it loads the next room's file, starts fading in, and then immediately receives another changeRoomRemote action to start the whole process over. This infinite loops until the player stops trying to move.
I believe this to be a glitch in the command/action system somewhere and not key input, so I didn't want to just hack in "changing room purges pressed keys and reloads them after the room is loaded".
Good luck.
Should be fixable with the new noActions event. Whenever
changeRoom/teleportRoom/teleportRoomRemote/changeRoomRemote are called, it
can just start by calling commands.waitFor("noActions"), then queue up the
actual actions with noWait=true. Should block user input until the next
room is actually loaded.
Mostly fixed, but now it is possible to flash the old room before the new room :(
loadStateFile.noWait = true; is what both fixes the "it won't load when the player is moving" and causes the flashing old room :(
Did you actually test that or is that based on my guess?
I tested it. I'm going through the whole flow from trigger to getting in the next room right now trying to figure out why it matters that keys are pressed :( I'm guessing the use of hasControl() everywhere is part of the reason...
So it mattered if keys were pressed, I'm pretty sure, because you would
keep walking into the door, triggering the change room command again,
causing an effective:
while(keyPressed){
sleep(1000);
}
This is why I always move the character out of the doorway before I start
the changeRoom[Remote] command. Because it would just fade to black and sit
there if they were left in there. This is technically correct behaviour,
since the trigger should be called whenever it is satisfied. However it
seems wrong that the trigger is ever queried in the middle of a room
change.
Possible hotfix:
Wrap any trigger querying code in
if(!destRoom)
OK, weird idea. What is a character's default dx? hasControl() returns true right before destRoom is set, which COULD be what is calling the trigger again. a dirty DIRTY fix would be to just return a higher -x in the args of the trigger...
Setting the border between room 1 and 2 to shift the character -50 instead of -12 worked, so I think that hypothesis is right. Clearly it is a bad solution to rely on the game creators to fix engine deficiencies in the SburbML coughWouldNotHaveHadThisIssueIfYouBuiltItRightTheFirstTimecough
the reliance on hasControl() means we can't easily patch the room changing code or action changing code... Maybe have a global variable for "We're loading the room! Don't load another one!"?? Sburb.loading may be better used in this case, and we can shift the event listeners to only run while Sburb.updateLoop is set?
And now it seems to override the changeRoom action with another changeRoomRemote when loadStateFile finishes. Ugh.