Improve LimbPath.cpp - rewrite ReportProgress, etc

[Architector4]

The rewrite checks all path segments from the current one to the last and finds the best one to continue from, instead of fixating on just the one. This helps in cases where feet might be yanked along the path by excessive horizontal acceleration, or when the player switches look direction while moving. Removes random stumbling too, mostly.

This doesn't perfectly fix everything ever, but it definitely makes it better I think. It's now more feasible to spam the jetpack and literally drag feet on the ground when the character's baggage is too heavy lol

Also fix Vector/Matrix division, making it the proper inverse of multiplication and applicable to a const Matrix. Figuring out why the math did not math definitely made me pull a hair or two lmao

Played a round of Bunker Breach with this patch and everything appears fine. Going over the scene wrap border break anything either.

---

Old behavior:

tmp.QFDPoB5KdD.mp4

New behavior:

tmp.hxQOb0nHw7.mp4

[HeliumAnt]

Awesome! Just some minor performance nitpicks and comment syntax.

[Causeless]

Sorry, GitHub mobile is shit and won't let me comment on specific lines, says an unknown error occurred.

So two thoughts:

1. I would rather we search everything for the closest. Walkpaths are not big, and they are also loops. It is very common that we may move further away from the outbound foot movement while the inbound foot movement is still closer.
2. Add a comment explaining the copy in matrix division. It's unclear why it's needed, and that code in isolation screams to me "this is dumb, why are we doing that?". Obviously it's required, though, so we should add a comment explaining that.

[Architector4]

Sorry, GitHub mobile is shit and won't let me comment on specific lines, says an unknown error occurred.

Happens to me too sometimes, especially when loading the page from an email for some reason; the fix seems to be to reload the page

• I would rather we search everything for the closest. Walkpaths are not big, and they are also loops. It is very common that we may move further away from the outbound foot movement while the inbound foot movement is still closer.

Just to be clear, by "outbound" and "inbound" to do you mean collision-disabled and collision-enabled segments? I think I made the code not check the former because I figured that landing slightly too hard or carrying too much weight would periodically cause the code to focus both legs to those collision-disabled segments, promptly causing a torso landing. I should experiment I guess.

2. Add a comment explaining the copy in matrix division. It's unclear why it's needed, and that code in isolation screams to me "this is dumb, why are we doing that?". Obviously it's required, though, so we should add a comment explaining that.

Yeah, I think I want to investigate if I can just avoid doing the dumb thing altogether. I wonder if I could make both by-mut-ref and by-const-ref versions of the operators lol

[Causeless]

Sorry, GitHub mobile is shit and won't let me comment on specific lines, says an unknown error occurred.

Happens to me too sometimes, especially when loading the page from an email for some reason; the fix seems to be to reload the page

• I would rather we search everything for the closest. Walkpaths are not big, and they are also loops. It is very common that we may move further away from the outbound foot movement while the inbound foot movement is still closer.

Just to be clear, by "outbound" and "inbound" to do you mean collision-disabled and collision-enabled segments? I think I made the code not check the former because I figured that landing slightly too hard or carrying too much weight would periodically cause the code to focus both legs to those collision-disabled segments, promptly causing a torso landing. I should experiment I guess.

2. Add a comment explaining the copy in matrix division. It's unclear why it's needed, and that code in isolation screams to me "this is dumb, why are we doing that?". Obviously it's required, though, so we should add a comment explaining that.

Yeah, I think I want to investigate if I can just avoid doing the dumb thing altogether. I wonder if I could make both by-mut-ref and by-const-ref versions of the operators lol

I was originally talking about the early-out check in the code finding the closest segment. Once the next segment is further away than the current one, we immediately exit out and claim we've found the closest.

This is very unreliable- depends on the order of the walkpath (for some given walkpaths, it could always return the furthest point!), but even for typical ones that involve a loop we could find a bad point 50% of the time.

With that said, we could experiment to find both collision enabled and disabled segments. Given we'd expect the walkpaths to be 180 degrees out of phase for both legs, though, in theory it would be best to actively force one leg to the collision-enabled-segments and the other to the disabled segments, at least when actively walking.

If the situation is that both feet are genuinely misplaced, maybe thats where we'd expect to see a genuine trip (and maybe we could trigger prone or something to make it feel more physically proper). But perhaps that's too aggressive here.

[Architector4]

I was originally talking about the early-out check in the code finding the closest segment. Once the next segment is further away than the current one, we immediately exit out and claim we've found the closest.

Ooh, yeah. I think I was just being too overly concerned with performance while making an assumption that seemed true from my observation of brain robot's walk path. There's not really that many segments and it could probably be allowed to iterate through all just fine lol

With that said, we could experiment to find both collision enabled and disabled segments. Given we'd expect the walkpaths to be 180 degrees out of phase for both legs, though, in theory it would be best to actively force one leg to the collision-enabled-segments and the other to the disabled segments, at least when actively walking.

To note, I wrote the code to always pick some segment other than the current target to look at, and code that advances to the next segment if the target threshold is reached, together with that, basically guarantees that the non-colliding segments will all be went through anyway.

Hmm, I think a fair solution might be to skip collision-disabled segments iff the current segment is collision-enabled?

[Causeless]

Yep, sounds reasonable. I think it ultimately depends on how it looks in-game, but in theory that sounds good.