Area2Ds ignore CollisionShape2D.one_way_collision

[henriiquecampos]

Godot version: 3.1.1

OS/device including version: Solus Gnome

Issue description:

When using CollisionShapes2D and PolygonShape2D to define an Area2D, if we use one_way_collision = true it has no effect for the matter of the Area2D signals, it will still emit these signals regardless of the collision direction

Steps to reproduce:

1. Create an Area2D, let's call it AreaOne
2. Add a CollisionShape2D to AreaOne and turn on one_way_collision
3. Create another Area2D, let's call it AreaTwo
4. Add a CollisionShape2D to AreaTwo and turn on one_way_collision
5. Implement some way to make both Area2Ds contact each other, from any direction other than the defined by the one_way_collision vector
6. Check if they will emit their area_entered signal

This is a gif of a test I did for a project. It is supposed to mimic Super Mario's stomp mechanic, where the player can jump on enemies' head and by doing so it will hop a bit. The Player's scene has an Area2D (in green) with a CollisionShape2D set as one_way_collision = true and rotated by 180 degrees (meaning it should only detect collisions from bottom to top, i.e. with a Vector2(0, -1) collision normal). The enemy's scene (in red) has an Area2D with a CollisionShape2D set as one_way_collision = true and no rotation (meaning it should only detect collisions from top to bottom, i.e. with a Vector2(0, 1) collision normal).

In the .gif, the player is idling and the enemy is moving towards Vector2(-1, 0). Technically, the collision normals should be for the Player's perspective a Vector2(-1, 0) collision and from the enemy's perspective a Vector2(1, 0) collision, I dunno if this is correct, but regardless of the actual normal, none should be neither Vector2(0, -1) nor Vector2(0, 1). Nonetheless, both Area2Ds (the player's and the enemy's) are triggering their behaviors.

[henriiquecampos]

The platform in black is a Tilemap and has one_way_collisions, the Player is a KinematicBody2D and it can properly jump through that Tilemap platform, so the problem is really the Area2Ds

[kakoeimon]

I think that this is not a bug.
One way collisions is for moving physics objects (Kinematic or Dynamic). Area2D does not have an algorithm for movement.

Edit: I mean only moving physics object will check for one way collisions.

[kakoeimon]

Further looking into this reveals that, one_way_collision is used only in space_2d_sw.cpp and in the method Space2DSW::test_body_motion
So this is not a bug.

[henriiquecampos]

This makes sense, as Areas are meant to...be areas, and as such, detect overlapping only, not detect collisions, and thus, the collision direction.

This doesn't sound like an Area2D bug, but rather a CollisionShape2D bug. or at least a misleading behavior.

If One Way Collisions aren't supposed to happen with Areas, which in my opinion they should, since in 3.0 we lost the ability to use CollisionShapes as triggers, thus, there is no other way to achieve that behavior. But anyway, if One Way Collisions aren't supposed to happen with Areas, this property should emit a warning when CollisionShapes are children of Areas and this property CollisionShape.one_Way_collision is turned on.

[kakoeimon]

You are not taking in acount several things.
Collision Shapes can be shared by several physics bodies. For example, you can duplicate the Collision Shape you have in a Kinematic body and drag it over the Area (which is a child of the Kinematic body) and make those two Physics bodies share the shape.
That's why the one way collision button must stay, as it is, Cause collision shape is agnostic of the ti's users.

As for Mario physics you do not need the Area at all you just get the normal from the collision. If it faces upwards you just hitted the head of your enemy.

[henriiquecampos]

CollisionShapes are nodes, they can't be sahred between other Nodes, the One Way Collision is a property of CollisionShape nodes, I think you confused them wih the Shape Resources.

I don't mean to change the behavior of the CollisionShape, I am proposing to add a warning on the CollisionShape when it is a child of an Area and the One Way Collision is true, otherwise this confusion will keep happening.

Another approach is to add support for Areas to take advantage of One Way Collisions, in either case the behavior of the CollisionShape itself won't change.

Yeah for the Mario stomp we already solbed the issue using KinematicCollision and checking the collision normal.

[KoBeWi]

This is still valid, but as others said, it's not a bug. It should be either documented or give a warning. If you want areas support one-way collisions, please fill a proposal on the proposal repository.