Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KinematicBody2D collision detection occurs depending on movement of it and the collider #46513

Closed
Tracked by #45334
ghost opened this issue Feb 28, 2021 · 7 comments
Closed
Tracked by #45334

Comments

@ghost
Copy link

ghost commented Feb 28, 2021

Godot version:
3.2.3 stable

OS/device including version:
xubuntu 20.04

Issue description:
KinematicBody2D only detects collisions from all sides when stationary(and not even that in some cases)
when moving it only detects collisions from the direction its moving towards even though there is no oneway collision enabled.

the project in the video is the same as the reproduction project attached below.
the "collision detectors" should all disappear when colliding with the "actors"
they all have identical code meaning they should all detect collisions the same way and "queue_free()" themselves

collision_test.mp4

Steps to reproduce:

  1. create KinematicBody2D moving along one axis
  2. create KinematicBody2D colliding with the first one from a direction that isnt the one the first one is moving towards
  3. check for collision on the first one

Minimal reproduction project:
no sprites, so enable [ Debug > Visible Collision Shapes ]
collision_test.zip

@pouleyKetchoupp
Copy link
Contributor

In general, it would be much safer to detect collision from both kinematic bodies, because move_and_collide is not meant to detect if other bodies have collided with the kinematic body, but only if the current kinematic body is bumping into something else. So there will always be some edge cases that are not supported. When using move_and_slide on the other kinematic body, you can use get_slide_count to check if a collision happened.

About the specific scenarios:

In 3.2.4 RC3, all stationary cases detect collision (which is more consistent), although I'm not sure this should be the expected behavior since they don't technically bump into anything.

For the (-15, 0) case:
This one looks like it's the expected behavior. Since the left kinematic body is moving away from the other one, it does make sense for move_and_collide to return no collision, as at the moment this function is called, it does not bump into the other kinematic body and can safely move with no hit (the right kinematic body has already moved left and stopped right at the collision).

For the (0, -10) case:
It would be interesting to investigate what's going on with this one and see if things could be made more consistent with the stationary cases. Since in this scenario the left kinematic body (moving upwards) doesn't technically bump into anything, I wonder if we can consider this is correct, and change the collision detection so that stationary cases don't detect collision either.

@ghost
Copy link
Author

ghost commented Mar 1, 2021

first of all thanks for you answer :)

In 3.2.4 RC3, all stationary cases detect collision (which is more consistent)

yeah i'm just looking for consistency. i can somewhat accept if move_and_collide doesn't detect passive collisions but then i would expect it for all of them. if what you wrote about 3.2.4 is gonna be in the next stable though its just gonna be even less consistent...
so maybe this doesn't make sense and i'm too smol brain but i would say either

a) only detect active collisions (meaning when bumping into something) and it shouldn't matter if its moving away from it
or
b) detect all collision no matter the position or velocity

if its gonna stay the old or some other way i think it would be a good idea to document its behavior in some way.

also the bottom left case really freaked me out, where the outcome is really just decided by the x position of the detector being a multiple of 5 or not ~

@pouleyKetchoupp
Copy link
Contributor

In 3.2.4, since all stationary cases detect collision, it will be a bit more consistent as the edge case in the bottom left is not happening anymore.

a) would be probably the way to go to make everything consistent though, as b) would be difficult to do without breaking the current API in other scenarios.

In any case, your best shot for consistency is really to detect collision from both KinematicBody2D motions, otherwise your game's behavior will be still dependent on how the collision algorithm handles edge cases.

@ghost
Copy link
Author

ghost commented Mar 1, 2021

a) would be probably the way to go to make everything consistent though

i agree :)
so the 3.2.4 change for stationary cases should be cancelled then?

In any case, your best shot for consistency is really to detect collision from both KinematicBody2D motions

yeah thats what i'm gonna do, thx

should this issue remain open until something is done or how do we manage this stuff?

@pouleyKetchoupp
Copy link
Contributor

should this issue remain open until something is done or how do we manage this stuff?

Yeah, it can stay open until things are made more consistent.

@ghost
Copy link
Author

ghost commented Mar 1, 2021

alrighty thanks again!

@pouleyKetchoupp
Copy link
Contributor

Closing as the inconsistent cases are fixed in 3.4 beta 6.

The only remaining case that doesn't detect collision is (-15, 0), which is the expected behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant