So the gist is that on collision, I set the velocity of the object to blast backwards on collision, and turn the collider into a trigger.
Technically when this happens depending how fast the code to switch isTrigger = true; is run, either OnTriggerExit2D will run, or OnCollisionExit2D will run, right? One of which must run, right!?
However what I’m seeing is that neither of them will run and I do not get either of the Debug.Log() calls.
This was working perfectly fine on Unity <4.5.1. At some point (I believe it’s 4.5.2 that broke it, but not too sure which version)
Any idea what might have changed and why this is happening?
Just an thought that doesn’t answer your question: why are you using a collider and then turning it into a trigger? If your dealing with the ‘rebound’ yourself (i.e., not using the physics engine to produce the rebound force), why not make it a trigger and avoid all this trouble? I’ve done that myself and it can sometimes work just as effectively as a physics-based buffer/launch pad/rubberised wall or whatever it is that you’re creating here.
It’s slightly complicated (and not likely the best way of going about things) but long story short I am turning it into a trigger to avoid further collisions.
When this object1 collides with another object2, it will sometimes have other object3 connected to object2. object1 must only collide once, and so it is triggerised to disable further collision, until gravity brings it downwards, clear of all collisions - at which point the collider becomes ‘untriggerised’
Other ways I have considered to achieve the same effect are:
Disable the collider2d - this does not work as I need to know when the object is clear of all collisions. If the collider is disabled then this is not possible
Use a different layer - same as above really, a different layer would make it impossible to use OnCollisionExit or OnTriggerExit
Ah, I see… Well, yes, it does sound complicated, which is why I think you might be better using triggers rather than colliders, unless you really need their physics properties. At least triggers are passive and you can simply set flags/cooldown timers and then move all the game logic into the code, testing the identity of the colliding objects and responding accordingly. For example, a bool flag or even an int value attached to the trigger could be incremented every time something enters the area, decreased when they leave, ensuring you know it’s state. Of course, I don’t really know your game logic so apologies if it sounds like I’m stating the obvious.
Haha yeah I did consider that as well actually, unfortunately… there is a object4 (It’s the ceiling) that needs to interact with object1 using actual physics (object1 is the character, he cannot go up past the ceiling!)
So some collisions need to be actual collision, and some need to be trigger-based. It’s horribly complicated the solution I came up with was actually fairly good in my opinion, and it was working perfectly, but Unity went and broke it
So it’s the old need-to-bounce-off-the-ceiling-sometimes-if-object1-is-attached-to-object2-but-only-if-object5-is-untrigggerised scenario? I know it well but unfortunately don’t have an answer, damn this feeble brain of mine. Sorry.
It seem that I’m able to make it work somewhat if I add a delay before setting the rigidbody2d velocity for the ‘blowback’
If I use a timed Invoke (delay of 0.05f) it seems to work fine most of the time, however when I test it on slower devices it doesn’t work every time, only about 90% of the time.
There have been a lot of bugs in Physics2D with relation to firing the proper events. It’s been going on since they launched Physics2D. They had made some patches a while ago that were supposed to fix these, but they’ve not all been wrapped up. Some of the discussion:
There was at least one more thread but I can’t find it.
My solution was to write my own wrapper for Physics2D and fire the Enter, Stay, Exit events myself. It adds a bit of overhead, but it works.