Is It possible to alter OnCollisionEnter order? I have two objects, a Cube and a Sphere. Both objects have a Scipt With OnColissionEnter. When the sphere colider with cube, I need to check:
Which position of the cube the sphere hit it. But the problem is that the OnCollisionEnter of the Cube is execute AFTER the OnCollisionEnter of the Sphere.
I.e., when sphere colider when cube, your (of the sphere) OnCollisionEnter is called. If hit point of the cube is between two specifc value (that I check by using OnCollisionEnter of the cube) then the action occurs.
As far as I know there’s no way to define the order that these two callbacks are called. You should be moving the logic all into one or the other instead of relying on a particular order. The same goes for things like Update (though there is a way to change Update order of scripts), in general you need to write your code so it will work no matter which order the callbacks are called.
To be honest, game development is a bit more complex than web development. In a typical web application, whether it’s a straight up set of PHP scripts or an MVC framework there’s a single path of execution. A request comes in, a controller and action are selected, the action uses the model to get data and the view to generate output. There is one single path through all that and it’s very predictable. Now imagine if your page were hundreds of PageObjects (like a GameObject) that can all react to events, react to interactions with other PageObjects, etc. It suddenly becomes a lot messier, you can’t rely on the order of anything reliably. You have to write around this, it’s a problem with the paradigm and not something specific to Unity.
There are, however, different programming environments if you want something more structured. Entity systems, for example, use the observer pattern to manage this problem. There are collections of entities and systems that act on these entities. These systems execute in a known, very well defined order and this cuts down dramatically on the weaknesses of a system like Unity’s. However, it doesn’t mix well with Unity’s style of development. Most of what makes Unity great is that you can just throw objects into the scene and let them interact with each other. It’s manageable if you know what to expect.
Edit:
And you don’t necessarily need to put everything on one script, but you should have one object be the “actor,” the one that triggers the script on the second object to be called. This way, for any given interaction there is one known object that initiated the interaction, even if the logic is spread across two scripts. The “actor” type object needs to know what type of passive objects it can interact with though, so there is some coupling involved.
Any suggestion how I can do it? Because I need to get the contact point of Cube (the only way I know is by OnCollisionEnter in Cube), but this value just appear after the OnCollisionEnter of Sphere be executed.
Now that I think about it, I’m a bit confused as to what you’re asking. A collision only has one set of contact points. When A collides with B, the Collision object’s contactPoints array will be the same. If all you’re after is the contact point, both calls to OnCollisionEnter will have that.
But maybe I’m not understanding what you’re asking. You could do this instead, in your Sphere’s script, add a public HitCube method. When the cube received an OnCollisionEnter it can see if the thing that hit it has a Sphere (or whatever you’re calling your script) component using GetComponent and, if it does, call HitCube with the information you need. This is what I meant by having one object be the “actor,” only one object in that particular interaction detects the collision.
Yes, that is it! You right: “A collision only has one set of contact points”. I was thought that each object has your proper collider, but they have the same colider. I do not need check sphere collision and cube collision because is the same. Now, it works.