Collision mask is not being considered exactly as it was made

[Rasterisko]

DESCRIBED THE BUG

It seems that the collision system is not considering exactly how the mask was made, but by completing a rectangle with it.

TO REPRODUCE

• Create a object with platform character behavior and another object with platform behavior .

• Make a complex colision box like this and try to interact them:

and it looks like it's happening this:

OTHER DETAILS

• Arthuro555 described in this post briefly what may be happening: https://forum.gdevelop-app.com/t/problems-with-the-collision-mask/36848/14

• GDevelop 5.0.123 on Windows 10

[4ian]

Custom hitboxes are indeed not supported by the platformer object behavior - only the rectangle surrounding the red polygons will be used. By the way your polygon looks concave which is also not supported in the game engine (platformer engine or not)?

Only custom hit boxes on the platforms are followed exactly.

[AlexandreSi]

Custom hitboxes are indeed not supported by the platformer object behavior

Maybe I don't fully understand what "support" means, but if you specify a custom hitbox that is a rectangle, it works just fine. Maybe we should add a warning, similar to #3348.

[AlexandreSi]

We could even add on the visual editor, for objects with platformer behavior, another rectangle that represents the rectangle surrounding all the masks that will be used when the game is running?

[tristanbob]

The physics behavior uses a non-standard collision mask that is configured inside the behavior properties ("Behaviors" tab).

Perhaps it makes sense to "show" the platformer collision mask on the behavior tab? (with a note that explains what it shows, and to modify the collision masks using "Properties -> Edit collision masks")

[arthuro555]

Maybe I don't fully understand what "support" means, but if you specify a custom hitbox that is a rectangle

My understanding is that only the AABB is supported, not the hitbox itself. So if you would make a triangular hitbox, which should be valid, it'll keep on using object bounds instead of the actual hitbox:

[AlexandreSi]

Actually, on your screenshot, the object's lower bound is the same as the hitbox's lower y. See:

The recent changes by @D8H only considers the Y range of the hitboxes of a platformer:

So what do you say about this feature:
On the collision mask editor, if the object has the platformer behavior, we add a checkbox below the preview that allows to display the bounding box used for the platformer to compute which platform it is on.

I can do it in #3348

[arthuro555]

That's the issue though, we shouldn't observe that only the lower bound is used and say "look at the code that's intended", because of course the code does that, how else would we be reporting that behavior! The bug report is about the behavior of the platformer behavior being incorrect, which it is as it should not be using the hitbox bounds but the hitbox itself for collisions. The solution is to change the platformer behavior to respect the hitbox, not to warn that it will only respect it's bounds (AABB).

[D8H]

That's the issue though, we shouldn't observe that only the lower bound is used and say "look at the code that's intended", because of course the code does that, how else would we be reporting that behavior! The bug report is about the behavior of the platformer behavior being incorrect, which it is as it should not be using the hitbox bounds but the hitbox itself for collisions. The solution is to change the platformer behavior to respect the hitbox, not to warn that it will only respect it's bounds (AABB).

It's possible to follow the floor using the exact collision mask, but it will makes the code harder to maintain so, at the time, we decided to wait and see if users really needed it.

@Rasterisko , the description doesn't explain what the intent was here. What is the use of this collision mask in the game?

[Rasterisko]

@D8H , In fact I was trying to help a person who was wearing a collision mask with multiple precise points on the object with platform object behavior. So I did my test with this exaggerated collision box to make it even clearer and thought it was a bug, because like the title says "Collision mask is not being considered exactly as it was made" (I didn't know about the concave collision mask not being valid in the game engine). But in his original game the mask is not concave and the collision points follow the character's drawing, although the problem persists since it is a limitation to the platform object behavior.

Here the link of the discussion in the forum: https://forum.gdevelop-app.com/t/problems-with-the-collision-mask/36848

And I'm sorry it took me so long to answer. I'm not in the habit of using github. But I'll be more attentive

[D8H]

Thank you, I answered on the forum. I think that a rectangular collision mask will work better in this case too. Complicated shapes will often have issues with flipping anyway.

[Rasterisko]

Okay, but I think the person already understands. When the 4ian replied I suggested on the forum to use a rectangular collision box and explained the situation. Thanks for the support!

[Silver-Streak]

Thank you, I answered on the forum. I think that a rectangular collision mask will work better in this case too. Complicated shapes will often have issues with flipping anyway.

Just want to double check here as I don't want to confuse the forum poster:

With the current logic/intended logic changes/etc, this still allows someone to have a center point (for flipping and ohter purposes) be outside of the collision mask entirely, correct?

This is important in instances where a user has a sprite with a weapon on the end, and they need the hit box to be all the way to one side, but need the center point to not be in the collision mask at all. Or in instances where they want the flipping to happen not at the horizontal center of the collision mask but more to one side or another of the collision mask.

This worked before the platformer rework, so I want to confirm this logic is still possible going forward.

[D8H]

With the current logic/intended logic changes/etc, this still allows someone to have a center point (for flipping and other purposes) be outside of the collision mask entirely, correct?

As long as the collision mask is a rectangle, it should behave the same. But, I wouldn't advise to use one that is not symmetrical to the center point because it makes the collision mask to kind of teleport which will result to a lot of issue like this one:

• "Flip object horz." on platformer allows jumping after wall contact #3312

This is important in instances where a user has a sprite with a weapon on the end, and they need the hit box to be all the way to one side, but need the center point to not be in the collision mask at all. Or in instances where they want the flipping to happen not at the horizontal center of the collision mask but more to one side or another of the collision mask.

This worked before the platformer rework, so I want to confirm this logic is still possible going forward.

It's still possible, but I don't see why one would want to do this. In my opinion, a character that is stopped against a wall by the extremity of its accessory will probably look strange.

[Silver-Streak]

Thanks @D8H. That addresses my concern.

While I agree uses cases for it can be odd, it is not uncommon, so I just wanted to ensure that functionality hadn't been lost.

[AlexandreSi]

Great to see you discussed it further!
Do we carry on with a rectangular hitbox? And if yes, do you think it's okay to add the rectangle as mentionned in #3344 (comment)? Or do you fear it will disappoint users? Maybe I can add a link to a forum/wiki page where it is explained why it behaves like that.

[Bouh]

This is a missing feature, which is not a bug, so the issue is not a problem. I'm converting this thread into a discussion.