Godot: Make KinematicBody methods available when RigidBody is in kinematic mode

[zejji]

Operating system or device, Godot version, GPU Model and driver (if graphics related):

OS: Windows 10
Godot 3 alpha 2

Issue description:

I have implemented a FPS puzzle game where the player can pick up and position objects (e.g. putting a box on a table). The objects which can be picked up are currently KinematicBodies and the collision detection is handled by using KinematicBody's move_and_collide() method to prevent the objects from clipping through other objects.

However, I realised that, when you put an object down, gravity needs to act on the object. Accordingly, I converted the KinematicBodies into RigidBodies and specified that they should be in MODE_KINEMATIC when being carried by the user (switching back to MODE_RIGID when dropped). However, my original code did not work any more because the move_and_collide and move_and_slide methods are no longer available. Presumably I now need to handle the collision detection and movement manually, which adds a lot of extra complication?

Is there any reason for not simply making the move_* methods available when using RigidBodies in MODE_KINEMATIC?

If this is not an option, how is the user meant to move the RigidBody in MODE_KINEMATIC (in particular to emulate the move_and_collide functionality)? I note that the RigidBody docs say:

As a warning, don't change RigidBody's position every frame or very often. Sporadic changes work fine, but physics runs at a different granularity (fixed hz) than usual rendering (process callback) and maybe even in a separate thread, so changing this from a process loop will yield strange behavior.

If this is not true in MODE_KINEMATIC, do the docs need to be updated accordingly?

Steps to reproduce:

N/A

Link to minimal example project:

[zejji]

@vnen @reduz - I propose to implement this feature as it is something we need for our game. (Currently we are using a very hacky workaround which involves dynamically creating a KinematicBody whenever the player picks up an object and applying an identical transformation to the RigidBody.)

I think the most logical way to implement this feature is to:

• make RigidBody inherit from KinematicBody; and
• override the new inherited KinematicBody methods (e.g. move_and_collide and move_and_slide) in RigidBody to add a check that the RigidBody is in kinematic mode.

(I had originally considered interposing a DynamicBody class between PhysicsBody and KinematicBody/RigidBody to hold the shared methods, but it is difficult to see what methods would be left in KinematicBody in that case.)

Would you be happy with this approach? (It should only take a few hours to implement and test.)

[lane-s]

I agree that the current structure doesn't make much sense. Why should there be a difference between a KinematicBody and a Rigidbody in kinematic mode? They seem to refer to the same thing.

[enthus1ast]

3.1 ? :)

[JoshuaManuel]

This feature would be fantastic for 2D platformers where the player can interact with boxes/crates.

[io12]

I need this for a game [bump].

[DrZanuff]

We are facing the same problem in our project [bump].

[FrederickDesimpel]

I would do the reverse, make the rigidbody functionality available in kinematicbody, since it IS a kinematic rigid body.

[Calinou]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!