From 93775ecde2812ceff1e2634a0a1a831c64e783be Mon Sep 17 00:00:00 2001 From: Misa Date: Fri, 6 Nov 2020 01:03:47 -0800 Subject: [PATCH] Fix ACTION press processing on same frame as fade ticks to 0 Here's what causes #401: After the fade to menu delay ticks down to 0, the game calls game.quittomenu(), but the rest of mapinput() still executes. This means that the block that detects your ACTION press gets executed, because there's a check that fadetomenudelay is less than or equal to 0, and, well, it is. So if you've pressed ACTION on the exact frame that it counts down to 0, then the game detects your ACTION press, then processes it accordingly, and then sets the fadetomenudelay, which means it'll get reactivated the next time you open the map screen. But at this point, you get sent to TITLEMODE, because game.quittomenu() set game.gamestate accordingly. (This is why resetting game.fadetomenu or game.fadetomenudelay in game.quittomenu() or script.hardreset() won't fix this bug.) The solution here is to add a game.fadetomenu check to the ACTION press processing. Same-frame state transition logic is hard... actually, any sort of thing where two things happen on the same frame is really annoying. This also applies to fadetolab and fadetolabdelay, too. Fixes #401. --- desktop_version/src/Input.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/desktop_version/src/Input.cpp b/desktop_version/src/Input.cpp index 8e54ef4e..1c7b3b3f 100644 --- a/desktop_version/src/Input.cpp +++ b/desktop_version/src/Input.cpp @@ -2157,7 +2157,7 @@ void mapinput() } if(graphics.menuoffset==0 - && ((!game.glitchrunnermode && game.fadetomenudelay <= 0 && game.fadetolabdelay <= 0) + && ((!game.glitchrunnermode && !game.fadetomenu && game.fadetomenudelay <= 0 && !game.fadetolab && game.fadetolabdelay <= 0) || graphics.fademode == 0)) { if (graphics.flipmode)