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:
parent
5aa8b99113
commit
93775ecde2
1 changed files with 1 additions and 1 deletions
|
@ -2157,7 +2157,7 @@ void mapinput()
|
||||||
}
|
}
|
||||||
|
|
||||||
if(graphics.menuoffset==0
|
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))
|
|| graphics.fademode == 0))
|
||||||
{
|
{
|
||||||
if (graphics.flipmode)
|
if (graphics.flipmode)
|
||||||
|
|
Loading…
Reference in a new issue