New collision mask behavior in beta 112

Previously, I could have an animation of an Object NOT have a collision mask. I would click on “Use custom collision mask” and it would clear away the default, and to add a collision mask I intentionally had to hit another button to create one. Otherwise, that animation was left without a mask.

Now, in beta 112, when I click on “Use custom collision mask” it creates a small square…that I can’t delete (if I do, it reverts back to the default).

I’ve gone into several objects that previously had an animation without a collision mask…and a small square one has been added to the middle.

Is this as intended?

1 Like

Well I wouldn’t be surprised if it did as I think I saw multiples crashes due to using a custom collision mask with none. I also do not see how something like that could be added by accident.

I’ve done some testing, and even if I do something like this, it still triggers a collision:


Am I the only one that does animations with no collision mask? I have been using it as a way to prevent collisions. For example, when Player dies the “dead” animation has no collision mask so that if it happens to collide with something (such as an enemy) while it’s dead and before the scene restarts, then nothing will happen based on all the “Player is in collision with Enemy” Events. I realize this can also be done other ways, such as with Variables. What is considered best practice for this? If I’m going to have to make a bunch of changes I want to do it the right way.

Setting all vertices to 0 still doesn’t remove the collision box. It’s small, probably 1x1 pixel, but it’s not gone. So using an object variable, or even checking the current animation, might be your best bet.

1 Like

Thanks @MrMen, I tested it and indeed it still triggers a collision.

I’m not sure how to officially do feature requests…but it would be nice if there was an Action that was “Enable/Disable Collision Mask”. Similar to how you can enable/disable platform behavior, etc.


If the Player has the “PlatformerObject” behavior added to it, and you use an Action to deactivate the behavior, does that make the Player unable to detect collisions? Because it seems to be working…though I’m not entirely sure why.

From a quick test, disabling platformer behavior doesn’t disable collision detection, but does make it no longer care about platforms. It’ll also disable any controls for movement/gravity/etc.

E.g. the “is in collision with” conditions will still work in events, but other platform objects or platformer objects will be able to just pass through the player. If you are using forces to move the player object it’ll also pass through any platform objects

I did a bit more testing. Using the “dies” animation mentioned earlier, I have found that if I use the same game file as it was before, and the only difference is opening it in beta112, then the Player DOES NOT interact with other elements (coins, enemies, etc.) when in the “dies” animation that has no collision mask.

However, if I open the Player Object and then hit “APPLY” instead of “CANCEL”, then that is when the new automatic small box collision mask I can’t get rid of is applied. After hitting APPLY and then testing, the Player DOES interact with other elements (coins, enemies, etc.) when in the “dies” animation.

Which means that all the Objects with animations that have no collision mask are fine…until such time that I ever need to make a change to that Object, at which point even a small 1x1 pixel collision box would have to be applied. Here is what it currently looks like…you can see that a small mask in the center has been created. There used to be nothing here. If I click on the trash can next to “Quadrilateral” then the default mask is restored.

If there is a reason this new “you must have at least a 1x1 pixel collision mask” feature has been applied then that’s one thing. But it feels like a mistake.

Should I report it as a bug on Github?

1 Like