Title sums it up, I just found the inconsistency annoying when using those functions. It might be problematic to change it due to backwards compatibility though
Is this only about argument name? I don't see a problem. They do two different things, so it makes sense that they aren't named the same.
I agree that it's confusing that the two move_and_* methods have a completely different API: move_and_slide expects velocity and returns the modified velocity, move_and_collide expects an offset and returns a KinematicCollision2D.
In Godot 2 there was only move, which behaved like move_and_collide. move_and_slide was then added, which uses _move internally (which is what move_and_collide binds to).
I find that the KinematicBody[,2D] move API is pretty cumbersome overall, and I hope we can refactor it for 4.0 to be more intuitive and convenient to use (especially regarding the many parameters passed to move_* methods). Currently it's quite inconsistent due to seeing several iterations of improvements while trying to preserve compatibility.
I think it should be move, take an optional parameter slide, and return a collision
@nathanfranke Boolean parameters aren't very readable when you skim over the code, so I'm not sure if it's a good idea.
Most helpful comment
I agree that it's confusing that the two
move_and_*methods have a completely different API:move_and_slideexpects velocity and returns the modified velocity,move_and_collideexpects an offset and returns aKinematicCollision2D.In Godot 2 there was only
move, which behaved likemove_and_collide.move_and_slidewas then added, which uses_moveinternally (which is whatmove_and_collidebinds to).I find that the KinematicBody[,2D] move API is pretty cumbersome overall, and I hope we can refactor it for 4.0 to be more intuitive and convenient to use (especially regarding the many parameters passed to
move_*methods). Currently it's quite inconsistent due to seeing several iterations of improvements while trying to preserve compatibility.