Fix gMarioState->lastSafePos not updating in some cases

[LucretiaArc]

Fixes #931. Also fixes the last safe position not being updated if the player performs a frame perfect jump.

In that issue, Arctic suggested updating the last safe position to the floor position of a destination warp after it is used. I haven't done that here, because the position under the warp might not be safe if Mario is meant to exit it with horizontal velocity.

[LucretiaArc]

Actually, this probably shouldn't live in object_list_processor.c

[gheskett]

I still think the warp thing is worth adding personally; if the above situation happens, you're kinda screwed no matter what (that's gonna be on the hacker to deal with appropriately I guess). Probably better to default assume a possibly bad warp than guarantee a wrong warp IMO.

[gheskett]

Or actually, maybe it could update only if level/area change, and otherwise not update? (Instant warps in particular make dealing with this whole thing kinda awkward.)

I think the only way to """really""" handle it in full would be to warp back to the old level/area, which I think is questionable scope for HackerSM64 to try and add a generic solution for.

[LucretiaArc]

It's not a consistent failsafe, but I suppose you're right that it's still better to have the safe position start near the warp in case it doesn't put Mario in a safe place.

[gheskett]

This still doesn't handle area swaps via instant warps, but once again that's kinda hopeless to fix completely anyway.

[gheskett]

Thinking about this more, should we be adding a slippery floor check and/or storing Mario angle? I can think of so many softlock situations with this implementation.

[LucretiaArc]

That's worthwhile, so I've added one, but it does preclude this system from being used for slides, and it can't completely solve the problem. If a level includes a platform that the player must jump to and then from in one motion, they could be left stranded on it if that were used as a checkpoint.

To be honest, I don't think any high-effort hack planning on offering the player a checkpoint/retry feature should use anything short of developer-placed checkpoints anyway. Even if you design around the potential pitfalls of checkpoints being absolutely anywhere in your level, putting the player right up against an edge that they jumped/fell off isn't a good experience.

[gheskett]

Yeah if I were using this in a hack myself, I would probably be buffering the safe positions, and clearing them out each time Mario goes from an unsaveable position to a saveable position (so frame-perfect triple jumps off a cliff don't send you a mile back or something). But that's a weird and specific enough implementation that I don't think we necessarily need it in here.