move_and_slide compatibility breakage between 3.0 and 3.1-alpha1

[Banduck]

Godot version:
v3.1.alpha.official

OS/device including version:
Windows 10 Home, Version 1803

Issue description:
This code worked in previous versions of Godot:



But in the current version the idle animation is not played if motion.x is set to 0.
The problem also occurs with other Lerp/move_and_slide related Code, not only with animations.
For some reason, Godot doesn't realize that the value is 0.
(In another project Lerp couldn't even set the value to 0 but only to -4 for some reason, but I can't reproduce that anymore.)

Minimal reproduction project:
Bug.zip

[groud]

You are comparing floating point numbers, while you can't expect perfect equality of two floating point values.
Use a delta to compare the number to, like if motion.x<0.001, or clamp the value between 0 and 0.2

[akien-mga]

I can confirm the issue, though it seems to me that it was a bug that it worked properly in 3.0.

lerp(motion.x, 0, 0.2) will never reach 0, it will always cut the current motion value by 20% towards 0 but not reach it. So in that sense lerp works fine both in 3.0 and 3.1-alpha in my tests.

The difference is in move_and_slide, which in 3.0 seems to return 0 on X if passed less than 5 as input, while in 3.1 it keeps going with more precision.

In 3.0:

pre-motion: 6.184752
post-motion: 6.184752
pre-lerp: 6.184752
post-lerp: 4.947802
pre-motion: 4.947802
post-motion: 0
pre-lerp: 0
post-lerp: 0

In 3.1-alpha:

pre-motion: 6.184752
post-motion: 6.184752
pre-lerp: 6.184752
post-lerp: 4.947802
pre-motion: 4.947802
post-motion: 4.947802
pre-lerp: 4.947802
post-lerp: 3.958242
pre-motion: 3.958242
post-motion: 3.958242
pre-lerp: 3.958242
post-lerp: 3.166593
pre-motion: 3.166593
post-motion: 3.166593
pre-lerp: 3.166593
post-lerp: 2.533275
pre-motion: 2.533275
post-motion: 2.533275
pre-lerp: 2.533275
post-lerp: 2.02662
pre-motion: 2.02662
post-motion: 2.02662
pre-lerp: 2.02662
post-lerp: 1.621296

and so on and so forth.

[akien-mga]

And yes as @groud mentions, if you actually want to lerp the value all the way down to 0 by cutting 20% each frame, you will never reach the integer 0, so you should compare to an epsilon - but I doubt that's the logic you want to go for anyway, as it means the friction takes quite some time to slow the player down to standstill.

[akien-mga]

I think the new behaviour is correct and this was actually fixing a bug in 3.0, but as it breaks compatibility, we need to decide how to handle it properly.

CC @reduz @AndreaCatania

[groud]

And yes as @groud mentions, if you actually want to lerp the value all the way down to 0 by cutting 20% each frame, you will never reach the integer 0, so you should compare to an epsilon

My point was about comparing floating point values in general, but indeed in that case the code also leads you to never reach the value.

[reduz]

@akien-mga the old behavior was pretty broken. we are breaking compat but it was not working well before.

[akien-mga]

As long as we document it properly, that's fine with me. @Calinou Could you add a mention to this in your 3.1 release notes as compatibility breakage?

[Calinou]

@akien-mga I added it to the changelog 🙂

[akien-mga]

Thanks, closing then.