Freeze pause doesn't stop on last fade-in frame of screens with short fade-ins

[Cosine256]

When using OL "Freeze updates" or "Freeze game loop" pauses with "Freeze during loading screens" disabled, OL won't pause on the last fade-in frame of screens with short fade-ins. Instead, it misses this frame, allowing one entity update to occur before the pause stops the game engine.

I believe the issue is the second state.fadevalue check here:

overlunky/src/injected/ui.cpp

Lines 9339 to 9348 in fa6a025

	function not_loading()
	local ret = state.loading > 0
	or state.fadevalue > 0
	or (state.screen == SCREEN.MENU and game_manager.screen_menu.menu_text_opacity < 1)
	or (state.screen == SCREEN.CHARACTER_SELECT and (state.screen_character_select.topleft_woodpanel_esc_slidein_timer == 0 or state.screen_character_select.start_pressed))
	if state.loading == 3 and state.fadevalue < 0.03 then
	ret = false
	end
	return not ret
	end

It works for screens with 40 frame fade-ins like levels (last state.fadevalue is 0.0250), but not 18 frame fade-ins like transitions (last state.fadevalue is 0.0556). Perhaps it would be better to check whether state.fadeout is 1?

Also, a related feature request: It would be nice if there was a similar special case for the first fade-out frame of the screen. I know that "Freeze during loading screens" works for all fade frames, but I'm often just interested in being able to see what happened on the frame where the player finished the door exit animation and triggered the fade-out, and then I want OL to not pause for any of the remaining fade-out frames.

[Dregu]

That does sound like a better check for variable fade lengths, I don't know what I was thinking. Also sounds more and more like you should just make this stuff exactly like you want in your script and maybe I'll port it back to OL, or you could just make a PR to fix OL along with making your script... I still find myself not interested to open vscode this whole week anyway.

[Cosine256]

If you're taking a break from working on this stuff, then that's fine. I'm pretty sure I can fix this particular issue myself in OL.

Regarding implementing my own pause system in TASW, that was what I originally wanted to do, but I ran into some gross issues with the hotkey system. It's possible that I'm not using the hotkey system correctly, so I haven't reported anything for those issues. In the meantime, I thought it might be easier if I keep using OL for now and migrate users from fade pauses to game loop freeze pauses. I'm willing to release a TASW version where the pauses are a little hacky since this is still way better than the fade pause limitations that exist in the live version.

Independent TASW pausing is still on my backlog, and I'll give some thought to how I could port my own pause system back into OL.

[Cosine256]

I'm working on a PR to fix this issue, as well as rename the fade variables. What cases was this particular check meant to catch?

overlunky/src/injected/ui.cpp

Line 9341 in fa6a025

or state.fadevalue > 0

You can set state.fadevalue to anything you want while state.loading is 0 and it doesn't seem to do anything except dim the screen, so I don't think it really counts as "loading". Was there a screen where this check mattered?

[Dregu]

I think there was a screen that fades without setting loading. Maybe out of character selection?

[Cosine256]

I see it flicker a fade_value of 1 for a couple frames when it loads the character selection. I didn't check every single screen and I'm not really confident about whether that check is unimportant, so I'm just going to revert that particular change in my PR.