KinematicBody2D.move result in weird movement between KinematicBody2D

[alexzheng]

bugsquad edit: reproduction project for 3.0 is here #8757 (comment)

---

Operating system or device - Godot version:
Mac OS godot version 2.1.3

Issue description:

when KinematicBody overlapped(for example they are spawned at the same position), call move, even the argument is vector2d(0,0), the bodies will move to some uncertain positions, far away from its original position, it seems a force is add to the bodies, and it can even move through static collide bodies.

Steps to reproduce:
create some Kinematic Bodies at the the same position
add some static bodies with rectangular shape to create walls surround them
call move on each body
the Kinematic Bodies will move through the static bodies to the outside of the walls

please check the demo project, and click to make the KinematicBody move
Link to minimal example project:

kenimatic.zip

[eon-s]

I have noticed this behaviour in many (if not all) engines, what method should be used for separation if the first attempts fail? stop trying and leave the body as "stuck"?

[alexzheng]

This bug makes a game using Kinematic Bodies to move unplayable, some bodies will just move out of the screen and become unreachable, even if I have a wall at each side of the edge, the bodies will still move through the walls.

[eon-s]

@alexzheng yes, I understand the problem, even if I see it as a bad design problem (two colliding bodies should never be forced into full overlap situation and expect a good separation) I would like to see a reasonable reaction from the Physics server (like ignoring them).

[alexzheng]

Could the developers of Godot take Attention to this issue, It's really very serious, I have made a prototype for a game, but this issue prevent me from developing further for publish. Kinematic bodies will be out of control for some situations.

[RebelliousX]

Don't use KinematicBody then, there are plenty of closed issues about the same problem, reduz will tell you it is not a bug and can't be fixed.

A workaround is to move using set_pos() and check for collisions using direct space state for World2D, using intersection functions, it is your responsibility to stop the object from moving when colliding then.

For me I ditched the whole Physics for 2D. I admit they have their uses and produce awesome mechanics, but for specific issues like in platform games, you will be dealing with physics issues not related to your code more than when you are coding your game. And that is for all engines.

[kubecz3k]

First of all thank you for your report and sorry for the delay.

We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.

We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about its current status here?

For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

Thanks in advance.

Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

[eon-s]

By b61021d, overlapping KinematicBody2D nodes still have the same behavior on the first separation.

Example ported to 3.

overlappingkinematics.zip

[akien-mga]

Still reproducible with the above project in the current master branch (631cf67).

[KoBeWi]

Still happens in 46e0e13
Although it's not as big problem as it sounds, because you rarely get two kinematic bodies inside each other. And even if they do, it's usually very slightly, so the push is not that big. So just don't put kinematic bodies on top of each other (why would you even need that).

[alexzheng]

Overlapping happens when spawn a kinematic body.

[KoBeWi]

Then prevent spawning them at the same position. E.g. put Area2D on the spawner and don't spawn if it's occupied. Or add some offset. You can't just put two physic objects at the exact position and expect them to behave predictably.

[alexzheng]

The issue is it would pass through static bodys,that’s weird.

[KoBeWi]

Yeah, that should definitely be fixed. Maybe it will happen with the planned physics rewrite.

[madmiraal]

#35945 will all but solve this issue, by ensuring that KinematicBodies are only moved the required distance to not overlap before attempting the move. However:

1. When both bodies are moved in the same physics frame, as in the example project above, they are both moved from each other; so they look like they're being moved too far, but they're really only being moved away from the original position of the other body.
2. If the pre-move to stop them from overlapping results in a new collision, as in the wall in the example project above, this will only be resolved in the next movement call. Note: if the body is stuck i.e. the pre-move cannot resolve all the collisions, the body is deemed stuck and no move is attempted.

I'm not sure whether these two minor points are enough to keep this issue open if #35945 is merged.

[akien-mga]

This seems to be fixed in 3.3 (at least the MRP).