I’d like to keep a game object active, but make sure it no longer creates collisions / trigger events. The game object has no rigid body.
I was looking for collider.enabled, but that doesn’t exist. collider.active probably just delegates to gameObject.active, so that’s not what I want (besides it is deprecated).
Is there a way to do this?
There isn’t, unfortunately. The closest you can get is to put the collider on a child GameObject and deactivate that instead.
Hi Neil,
thanks for the quick reply, but … argh 
In a way, putting the collider into a separate child object sounds like an interesting idea, since I’m currently doing a lot of “move stuff into child objects”. Unfortunately, for this to be useful, I’d have to have it as a pattern I use everywhere (then I could always use the parent object for checking the type of object the collision took place with).
In my current project, that might even work - but in the long run, I guess that would mean I’d get some troubles when I want to use the physics engine for more than just collision detection… The way I understand it, physics are really something that should be handled by the “root game object” of any given composite object…
Sunny regards,
Jashan
I’d use Physics.IgnoreCollision.
–Eric
Except that only ignores a collision with an object known at that instant. Which means you also have to know in advance every object you don’t want to collide with, even if they don’t exist yet. It’s not a workable solution, unfortunately.
Argh!!! Unity needs real collision groups. Badly. :x
Not as nice as a Collider.enabled, but can’t you just use Destroy(collider)/AddComponent(typeof(Collider))?
It does work, it’s just a pain. 
Whenever you instantiate an object, loop through the objects that you want to ignore. You can set up a system to automate that and reduce the pain involved, until such time as UT hopefully implements something better.
–Eric
Wouldn’t you then need to reconfigure the collider every time? Ie, if it has specific transform settings relative to its parent, etc.
What about objects that don’t yet exist?
For example, say you have a shield that blocks enemy shots but not your own. At the time you set up the collider, not all possible shots will exist, because some will have to be created in the future.
Also, what if the set of objects you want to collide with changes? You’ll have to run through the list again and rebuild it each time that happens.
What if said shield is not just a single instance, but many and across owner types with differing criteria for which objects to block and ignore? Determining at run time what to ignore would become really complicated and possibly CPU intensive as things change over time. (Collision groups would make that scenario child’s play.)
I could invent, code, and test a manager for all this, but Unity’s so simple for most other things that it’s making me lazy. 
For my learning project, I’ve used the method of making the collider a child of a new GameObject and making that a child of my main object. I then activate/deactivate the collider object. I’m not sure this will work for all game types, though. So maybe I’ll hit this wall again in a more complex project.
Unity just needs some PhysX upgrade lovin’ so this can be a much more simple and flexible matter. 
Thanks for the help and advice!
I do it the way Eric describes - implement a collider grouping system running parallel to the layers system (in the end, what we really want would probably be collider.collisionMask = LayerMask).
Something like this:
ColliderGrouping.Instance.SetIgnoreRules( "Group", otherGroupNamesArray );
ColliderGrouping.Instance.RegisterCollider( collider, "Group" );
Others toggle isTrigger, which still gives you the PhysX overhead on that collider, but lets other colliders pass through.
Are you going to open source that? 
could you create a variable that is eighther on(1) or off(0), that all other code in your object functions are dependent on?
n:shock:b
I did it on a client project so I don’t have access or rights to the source, but I guess I could write up a similar system when I get the time.
HI angryant,
Waht language would you use to write the plugin? and would that be considered extending the functionality of Unity3d via plugins or simply more advanced scripting?
My preferred language is C#, but you could use any of the three options available (note that Boo is not currently supported on unity iPhone though). My schedule is pretty full at the moment, so I don’t have a plan of attack for this yet - as in I don’t know whether I’d do it as an assembly or just an installable script. I’ll have a look at this when I find the time