I discovered that collisions work globally, which forced me to double the amount of sprites and use pin behavior to work around some collision problems. That's why I would like to request an option to disable collisions only between selected instances.

Instance variables should let you do that so when you check them you know they should be allowed to interact with each other.

Another thing is using families, but that also would require multiple objects. However you can have all the properties those objects need applies to the families and thus are able to add new objects without needing to re-do all the variables/behaviors.

Most of the time when collisions are being triggered globally, you're checking for a very generic collision event that includes the objects colliding.

I actually tried that, but it doesn't seam to work well.Also for example I need one instance to be able to check for collisions with other instances like bullets for example, while other instances of the same need to have the collisions turned ON even if one of them is "allowed" to overlap a solid.

Here's how it work in my program: I have group of instances that are moving alongside the collision masks of other instances. Every now and then one, or few of them needs to enter the area of that instance, and interact with other instance from another group. So I only need to turn off collision with one instance but still need to detect overlapping with another one, and keep collisions detection for the instances outside. If its sounds complicated, it is, but I can't think of any other way around it other then having possibility to turn collisions on and off only with certain instances. As I said, tried with events, but doesn't work. megatronx2013-12-19 19:23:00

Sorry to bump but are there any plans to add this? It's been requested almost a dozen times and would really come in handy for an ability in my game. It allows you to walk on water, lava, spikes, etc. which requires turning them into solids - but if they are solid then everything else can walk on them too!

If your player becomes invincible or able to walk over lava etc., you could run a loop that goes through all "obstacles" like lava etc, and places an invisible sprite the same width/height as your obstacle temporarily over them. And then destroy them again once the invincibility wears out.

@megatronx @MadFactory it should work fine with instance variables. I did something similar some time ago using simple boolean to check which instance can do things others can not. On the other side I never use solid behavior, i prefer do my own collision checks...

@justifun That is exactly the same as just turning the water/lava into solids. The problem is that the object becomes a solid for anything with a behavior, not just the player. (Water enemies are pushed out, everything else treats it like any other floor, etc.)

@shinkan Yep, very easy if you wrote your own collisions but I'm using built-in behaviors so pretty much all collision stuff is out of my control.

This is mostly an issue with the Solid behavior, rather than collisions in general. Each Solid should keep a list of objects it can act on, with every object on the list by default. That feature would be a huge boon for some tasks.Squidget2014-01-26 05:29:23

Here's my really drawn out thoughts and ideas on this subject, as I have hit points where I have had problems dealing with this whole "turn on and off individual collision" thing.

So the problem is that if we are using a behaviour (such as platformer) that relies on another sprite having the "Solid" behaviour in order to be able to collide/stop/land on, we can't. Instance Variables (like @Thndr mentions), would honestly be the most AWESOME way to handle this, but we don't actually have the action avaliable to make a behaviour sprite act properly unless the target sprite has a Solid behaviour on it. So the current methods we have aren't good because:1) Deactivating the Solid behaviour on the sprite, would mean all other behaviours that rely on the Solid platform will also be deactivated.2) Deactivating the Platformer behaviours collision would mean that if they were to land on a Solid, or walk into a solid that they should be able to collide on whilst still being over the floor that should be deactivated, the result could end with the player being able to walk through obstacles they shouldn't be. (So for example, your within some lava that causes you to be deactivated of collisions since you don't have a powerup to walk on lava. Whilst you are in the lava and collide with a wall, you would go through that wall.).

If I were to implement 1 (seemingly) easy feature into C2 to help, that would be some form of "Treat as solid" action. "Treat as solid" would be available in all behaviours that interact with Solids (platformer, 8 direction, ect), and it could be called during a "Is Overlapping" event (or however collisions are usually called within the code of behaviours normally).What this action would do, is simply make the behaviour behave as if it has just collided with a sprite that has a "Solid" behaviour applied to it, even though it doesn't have a solid behaviour...*mindblown*So if we take the lava example,The lava would NOT have a solid behaviour applied to it, and we could allow multiple platformer players that each have different states to determine whether they can walk on the lava. So the events to make ONLY players with the powerup able to walk on lava:

This uses instance variables to see if they are allowed to walk on lava, and then detecting if they are on lava, then colliding with the lava, stopping the player from falling through it, whilst any other players that have that variable set to False, they would fall through it.The only downside I can think of with this, is that if you would want to take advantage of this sort of mechanic, you would need to remove all "Solid" behaviours that exist in the sprites, and have to handle it manually in events.Good idea?

tl;dr Add a new "Treat as Solid" action to behaviours that rely on collision with solids, so that we can make them collide with non-solid sprites as if they are solids.