 |
Attention | Topic was automatically imported from the old Question2Answer platform. |
 |
Asked By | Fishtail |
 |
Old Version | Published before Godot 3 was released. |
So I’m using the 2.2 alpha version of Godot and fiddling with move_and_slide for a kinematic character, but I’m having issues with movement along slopes.
I notice the demo just uses a constant FLOOR_NORMAL Vector2(0,-1). I figured maybe I could do a get_collision_normal() to replace the FLOOR_NORMAL, but that didn’t seem to work out too well. I set up a state machine to print out the current state and sure enough, it’s constantly switching between “ground” and “air” so long as I’m moving on the slope.
Is there an easy way to fix this so I stay on the “ground” when going uphill/downhill? Gravity is already set decently high (around 3000), which comes with its own issues so I’d rather not make that any higher.
Preferably, I’d like to avoid using a bunch of raycasts to detect collision sideways and beneath in order to set specific x and y velocities.
I’m still struggling with slopes with and without move_and_slide with a fixed speed…
Going down in steep slopes is my bigger problem, maybe limiting the x speed when the normal is at an angle > PI or when the remaining Y motion is too big.
But a raycast may be unavoidable to get floor normal when going down (mostly to slow X and prevent the starting jump that ruins all the movement).
In the github demo project, there is a platformer demo that uses move_and_slide and almost solves slope issues, i think because the controller does something like an accelerated movement.
Remember that move_and_slide is still a work in progress, I don’t know if it will suffer some changes or even if will be added to Godot 3.
eons | 2017-01-11 13:47
I have a similar problem, not using move_and_slide (but using both move and slide).
My solution attempt was to do an extra ‘move’ downwards after my horizontal motion, then if that move hits floor, keep it, otherwise undo it and go into “not on the floor” mode.
However, this solution causes a different problem - it turns out that move(0, 3) hitting a diagonal slope causes a small amount of horizontal motion, which causes ugly disruption when walking uphill, and causes unwanted sliding downhill.
I think that’s a bug (move shouldn’t cause any motion you didn’t ask for!) so I’ve filed a bug. KinematicBody2D move leaks some unexpected motion colliding with static · Issue #8603 · godotengine/godot · GitHub
Apart from that issue this seems like a pretty good solution, significantly simpler than a mess of raycasts.
ravenblack | 2017-05-01 03:59