[RFC] Reset unstick handling when idle

[petchema]

Reset unstick handling frame counter when not trying to go forward or backward. This should make it harder to trigger unsticking when moving by short bursts or using a mix of moves that doesn't make you progress forward or backward

Forums: https://forums.dfworkshop.net/viewtopic.php?f=5&t=3537

Also possibly
#1759 (comment)

[Interkarma]

I really appreciate your help with this, thank you.

[petchema]

Thanks! I hope it'll be effective, because I could not reproduce the problem the way described in the forums, I guess I'm not doing it correctly. But the change looks sound, so I cross my fingers.
That PR will also conflict with #1759 because they modify nearby code. I could fix this PR afterward, or merge them beforehand, just tell me what you prefer

[petchema]

It turns out the problem described in the forums is more complex, and caused by the combinaison of crouch crawling and low MovementAcceleration resulting in slow movements for enough frames to trigger unstick handling...

[Interkarma]

I've considered either removing or changing the scale of movement acceleration. It's one of those settings that can ruin the game experience if player sets it too low without understanding what it does. Only about range 8-10 is really playable.

Perhaps some combination of adjusting movement acceleration range and tuning unstick handling thresholds will help? We might also be able to move it to a different timing system than per-frame so that users with a high frame count and no v-sync aren't adversely affected.

[petchema]

Checking that there's an obstacle ahead in the first place should prevent most false positives, but I've yet to find a way to implement that; CollisionFlags is not precise enough, and a CapsuleCast starting from a position where the capsule is already in contact with a surface misses that obstacle. Maybe by starting from a position slightly behind? Feels like a hack though.
And yes, I've been toying with the idea of using a time threshold instead of a number of frames. Let's not repeat the mistakes of the past ;) It's not even difficult, just summing Time.fixedDeltaTime instead of an increment...

[Interkarma]

Have merged #1759. If you can fix this PR when you can, I'll review and merge. Cheers mate. :)

[petchema]

With some MovementAcceleration it's still very easy to trigger unstick handling by tapping the forward key, so that's a mild improvement at best

[Interkarma]

I'll merge this one now. BTW, do you think below might be a regression from new unstick handling changes? I haven't looked into this yet, and it's the first and only time I've had such a report.

https://forums.dfworkshop.net/viewtopic.php?f=24&t=3618

[petchema]

Making sure the capsule does not collide with anything along some path to the destination should be a very safe approach, but that wouldn't be the first time they're hidden issues with similar code; Colliders is tricky business, not to mention 3D geometry in general...

[Interkarma]

Have looked at bug and seems related to an exception while a WA quest is moving player to dungeon. Not sure yet if a DFU bug or bad interaction with WA, but doesn't seem related to movement at all. Sorry to mention it. :)

[petchema]

No problem, as I said this is a difficult domain. I sometimes wonder if there's a way to rule out all bugs in such code, they're corner cases everywhere...