I made some modifications to the layering last night to make my game more efficient but now it is acting strange. When using the IgnoreLayerCollision(12,24) on 1 single Prefab, will that set the matrix for all there other objects?
Testing my game I have 2 cannon balls and 1 shield. 1 cannon ball can penetrate the shield and the other can not. I shot the first cannon ball at the shield and it hit the shield, as expected. Then I fired the one that can penetrate the shield and it went through as expected. But then when I fire the first one again, and used the cannon ball that should have hit the sealed, it went through, which it should not have.
I am looking for any confirmation that when you use the IgnoreLayerCollision() in a script, that then changes the LayerCollision for all other GameObjects? So it’s like a global LayerCollision adjustment instead of a local on specific to the gameObject in question?
For sure, it’s in the docs: Unity - Scripting API: Physics2D.IgnoreLayerCollision
In the (non-2D version), there is also a note about how this will reset the trigger states for OnEnter/OnExit… which I would guess probably happens in 2D, also, but wasn’t written down.
In your case, if you have 2 types of cannon balls, maybe you want to use 2 separate layers for those.
Ahhh, thanks! Since my original idea for the game has expanded I find myself writing lots of extra code. I was trying to consolidate that now and remove some layers to make things easier to work with. Thanks for verifying it!
Thanks. I tend to go to the Doc’s first or a Google search. I am going to hit the Docs now to see if there is the reverse of the Ignore Layer so that I can reset it in the destroy function for the cannon ball. That was I can just ignore it for this one object and they set up the collision after it’s destroyed.
Found it in 5 seconds looking at the Doc’s. I wasn’t aware that the IgnoreCollision(5,8,false); had a 3rd argument, for setting whether the collision happens or not. That method should always require that 3rd argument. I think it makes for a better written code.
Sometimes, methods are written with those optional parameters… I guess the authors thought that might be more than a 50% chance people use it for true? lol I’m not sure.
Glad you found it, though.
