KinematicBody player with RayShape does not respect snap argument in move_and_slide_with_snap()

[DenisBelmondo]

Godot version:
3.2 dev

OS/device including version:
Windows 10 x86_64

Issue description:
KinematicBody no longer snaps as per the snap argument in move_and_slide_with_snap(), as evidenced by the fact that the player "hops" when walking down slopes.

Steps to reproduce:
Download the provided project in the zip file, run test_map.tscn, walk up the red slope immediately in front of the player, descend it, observe the player "hopping" as they descend.

Minimal reproduction project:
kinematicbody-demo.zip

Additional notes:
There are two types of player scenes in the project. One has the 3D equivalent of the RayShape setup as seen here (which does stop the player on slopes properly and prevents them from incurring more effort when walking up them as of 3.2) and the other (called "PlayerNoRayShape") which does respect the snap argument (But also slides down slopes even when stop_on_slope is true unlike ordinary Player. May submit this as a separate issue.)

To observe the behavior of PlayerNoRayShape, replace the player scene with a player_no_rayshape scene in test_map.tscn and place it in front of the red slope.

[aaronfranke]

@DenisBelmondo Can you test in 3.2 beta 3? Possibly related: #33864

[akien-mga]

Can you test in 3.2 beta 3? Possibly related: #33864

I already tried, the project has the same behavior in 3.1.2-stable and 3.2 master.

[oeleo1]

I have this issue too, circumventing the problem by applying tons of gravity when the player is on_floor() to make it stick. But I'd love if it snapped properly in the first place.

[pouleyKetchoupp]

Can still reproduce in 3.2.4 beta 5.

As a side note:

But also slides down slopes even when stop_on_slope is true unlike ordinary Player.

This can be fixed by applying gravity only when is_on_floor() is false, because some excess velocity from the gravity can prevent stop_on_slope from working properly.

[Setadokalo]

notably, enabling slips_on_slope for the RayShape seems to allow snapping to work (but of course also negates the main advantage of using the RayShape).

[oeleo1]

Hang on a second. Is there a fix for the production 3.x branches for this?

[aaronfranke]

@oeleo1 No. The PR which fixed this, #51896, breaks compatibility, so it can't be backported. A separate fix would be required for the 3.x branch if the problem is possible to fix without breaking compatibility.

[pouleyKetchoupp]

For info, I'm planning to try and backport some of the fixes to 3.x and it will probably include this issue.

[oeleo1]

So be it. So why is the issue closed then? It has been reported as an issue for 3.2+.

Our experience on 3.x with this is that snapping is a gamble. Make a sinusoid terrain. Have a character 128 pixels hight, 64 pixels to the terrain. Make it move. Make the snap 70 pixels, then 128 pixels, then make it 1024 pixels. You will be fascinated by the random jumping of the character.

[pouleyKetchoupp]

@oeleo1 Issues are closed when fixed in a future version, whether it's the current master or backported to 3.x, and the main development focus is 4.0 at the moment. The only exception is regression bugs specific to 3.x.

But as mentioned before, an issue like this one will be likely fixed in a separate PR for 3.x, it's just going to take more time to do it in a way that doesn't break compatibility.