OnCollisionEnter still called when disabled, and destroy sets enabled to false.

OnCollisionEnter() gets called even if the component is disabled. So, I added an enabled check to all my collision functions. However, when Destroy() is called on an object, it apparently sets all components’ enabled to false immediately. So if Destroy() is called (even if I never set enabled to false myself) and then an OnCollisionEnter() is called on the same frame, enabled becomes false regardless from the Destroy() and so the OnCollisionEnter() doesn’t continue.

I get why OnCollisionEnter() gets called on disabled objects (as you can add a check for enabled yourself like I did), but I don’t get why Destroy() would set enable to false. Is there another variable similar to enable that only gets set when I set it myself (and not when other functions like Destroy are called)?

If not, is there any way to call collision logic on components that only doesn’t get called if I myself disable them or the gameobject?

If not, I’ll have to write custom destroy logic that sets enabled back to true if it already was so before the destroy (iterating through all components to do so, (potentially extremely inefficient). I just want to know what the Unity way to do this is supposed to be before I go undoing what Unity wants to do.

EDIT: Another alternative would be a custom setEnabled() method that also sets a custom bool accordingly. However I’d have to derive all the classes I’d want to use this feature (probably all of them) from a custom extended monobehaviour class, which I was hoping to avoid. And even then whenever I want to check that bool I’ll probably also want to check if the gameobject is active.

If you switch to Unity 5, you benefit from this

Disabled MonoBehaviours will no longer receive collision or trigger callbacks.

In your case, I would recommend to destroy OnCollision, and not handle collisions after destruction.