Mover causing unexpected velocity drop when landing

Development Programming & Scripting
, , ,
1

In 5.5 Preview 1, I’ve been testing out Mover 2 and occasionally the velocity unexpectedly drops upon landing.

Most of the time when you land it works as expected, but occasionally the velocity drops and it’s perceived as a hitch.

I’ve attached a video with a demonstration of what is going on in the mover examples, but I observe the same behavior in my project, you can see the hitch and where the velocity trail is packed tighter than expected.

Anyone have any idea of what might be going on here? I’ve tried tweaking settings and nothing seems to improve it.

2

I’ve been digging into this a little more and I think I know where it’s going wrong, but the correct fix isn’t super obvious to me.

If you look at these 2 logs:

This one worked correctly:

LogMover: VeryVerbose: TrySafeMove: AnimatedMannyPawn_C_0 (role 3) Delta=V(X=13.37, Y=0.13, Z=-14.71) DidMove=1
LogMover: Verbose: AdvanceToNextMode: AnimatedMannyPawn_C_0 (ROLE_Authority) from Falling to Walking
LogMover: VeryVerbose: TrySafeMove: AnimatedMannyPawn_C_0 (role 3) Delta=V(X=14.19, Y=0.14) DidMove=1

This one hitched:

LogMover: VeryVerbose: TrySafeMove: AnimatedMannyPawn_C_0 (role 3) Delta=V(X=4.81, Y=12.42, Z=-14.78) DidMove=0
LogMover: Verbose: AdvanceToNextMode: AnimatedMannyPawn_C_0 (ROLE_Authority) from Falling to Walking
LogMover: VeryVerbose: TrySafeMove: AnimatedMannyPawn_C_0 (role 3) Delta=V(X=0.64, Y=1.64) DidMove=1

You can see the DidMove is 0 on the hitching one, and there is a huge change in the Delta which shouldn’t be there.

Digging into the code, the hitch appears to trigger in UFallingMode::OnSimulationTick when UMovementUtils::TrySafeMoveUpdatedComponent runs.
If that TrySafeMoveUpdatedComponent returns false, it will hitch.

What I am not sure about is how it might be fixed, because it seems the act of calling TrySafeMoveUpdatedComponent is what induces the behavior, so I am not sure if it can be corrected for from UFallingMode.

At any rate, this definitely seems like a real issue rather than something in the setup

1 Like
3

Hey there @Joeh! Good catch, it seems like an edge case that stems from TrySafeMoveUpdatedComponent. It could be possible that for the frame it’s triggering the depenetration/sweep back that happens with collisions hadn’t occurred yet causing the safe move to read as unsafe, though that is just conjecture. Going to try and confirm that’s the case then submit a report if I can replicate it.

1 Like