1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-12-23 01:59:43 +01:00

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.
This commit is contained in:
Misa 2020-11-06 01:03:47 -08:00 committed by Ethan Lee
parent 5aa8b99113
commit 93775ecde2

View file

@ -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)