PRE_GAME_LOOP callback unreliable during OL game loop pauses

[Cosine256]

If OL pausing is set to "Freeze game loop", and OL pausing is active, then some scripts don't execute PRE_GAME_LOOP callbacks, but it seems like they will always execute POST_GAME_LOOP callbacks. I didn't test other callbacks and OL pause flags to see if they have a similar issue.

This is the example script I was testing with on OL fa6a025:

pre_game_loop_count = 0
set_callback(function()
    pre_game_loop_count = pre_game_loop_count + 1
    prinspect("pre_game_loop_count", pre_game_loop_count)
end, ON.PRE_GAME_LOOP)

post_game_loop_count = 0
set_callback(function()
    post_game_loop_count = post_game_loop_count + 1
    prinspect("post_game_loop_count", post_game_loop_count)
end, ON.POST_GAME_LOOP)

When I run this script via the OL console, both callbacks print messages while OL is paused. When I run it as part of a Mods/Packs script ("TAS Wizard", in case the name matters for the order of script execution), it only prints the POST_GAME_LOOP messages.

I'm not sure what would be the most sensible behavior for this. At the very least, if POST_GAME_LOOP executes, then there should always be a matching PRE_GAME_LOOP before it. In my case, I would prefer to always see a PRE_*/POST_* pair even if OL or some other script skipped the event. Perhaps the POST_* callback could include a way to check whether the event was skipped.

[Dregu]

I agree that the POST events should not run for any blocked PRE events. I don't know when we veered off from that design rule, but if thing never happens, there should not be an after-thing either. I should fix that, but maybe there are also cases where you would like to run a (different) callback when thing was blocked? So I should maybe block the POST-callbacks but also add POST_BLOCKED callbacks that run instead.

I think that blocking in these PRE-callbacks will also stop other scripts/callbacks from getting that PRE-event at all simply if the other script context was created later. That design choice wasn't really made with these pausable events in mind, in fact it was made years ago, but that's how all the blockable void functions work.

That running order, even if it might be somewhat predictable, probably shouldn't be used to design other scripts anyway. Maybe if I overhaul the OL pause system to always block before anything else, so no script gets a chance to run the callbacks, so at least that part would be predictable.

Running both tools with the API enabled makes it a bit more confusing, but basically the function that runs the hooks in Playlunky will be hooked as the vanilla game function in Overlunky, and blocking it in OL definitely blocks all of the hooks in PL.

[Dregu]

Made some PRE/POST callbacks more consistent and added BLOCKED variants for some POST callbacks that can get blocked in #366