OnEnable, Awake, Start order

I believe this actually answers @sebas' question. See my answer for a more detailed explanation/analysis.

It may be fixed in Unity 5.1.3, or maybe my case has some subtle differences.

I tried to make a MonoBehaviour B with OnEnable be run after another MonoBehaviour A with no OnEnable, and it worked. I wanted A.Awake() to quickly deactivate the game object of B so that B.OnEnable() was not called at the beginning of the game (not critical, but it would cause unneeded initialization of B just before being deactivated anyway). Script A managed to deactivate game object B before B.OnEnable() was called.

This IS NOT FIXED even in the latest Unity (March 2016).

Adding OnEnable in your low-order script DOES NOT SOLVE the problem unfortunately.

I can confirm that this DOESN'T WOR$$anonymous$$ in 5.3.4f1. What worked for me was to change the execution order for the two scripts.

Edit > Project Settings > Script Execution Order

Thanks for the answer. Are you telling me that the script execution order controls only the Start order and not the Awake order?! However I do not think they are called inside the constructor, but I do think they are called right after.

Yes, you can't control when Awake is called since it's actually the direct replacement for the constructor. Awake might be called from the constructor, but we don't know how Unity handle those things behind the scenes. That's why i said the "internal constructor". Don't forget that almost every object in Unity has also a c++ native code class-part behind the scenes. Unity isn't written in managed code, only the scripting environment uses Mono. When you "add" a component a lot things happens which you don't see and you can't influence.

According to the docs there are several aspects that are incorrect from Bunny83's reply. Firstly script execution order does determine when Awake is called (http://docs.unity3d.com/Documentation/Components/class-ScriptExecution.html). Secondly 'Awake is called after all objects are initialized so you can safely speak to other objects or query them' (http://docs.unity3d.com/Documentation/ScriptReference/MonoBehaviour.Awake.html), so its perfectly safe to use code in Awake that replies on other objects.

Further more you need to take care if using Start to initialise object dependencies since if the object is enabled, its OnEnable will be called first, and if you try to use those dependencies they will not be set up yet.

As to your problem check my reply below and see if its to do with a known bug when using OnEnable in other scripts but not in the one you are trying to force the script execution order for.

@Noisecrime: I believe with "Avoid code in Awake which relies on other object" @Bunny83 is talking about situations where you are referring to other objects that also initialize themselves in Awake(). For example, for a given scene hierarchy where the same script type is attached to all objects, the children (or some children) of an object might already have their Awake() being executed, while the parent object has not. Or vice versa - it might be non-deterministic. In addition, if you are instantiating stuff in Awake(), you cannot relie upon in other Awake() functions that these objects have been created already. So you might want to do your instantiations in Awake(), but any Find()/FindObjectByType() etc. in Start.

The whole execution order thing doesn't work at all. It does work when a level is loaded, but try instantiating a prefab at runtime... The only thing that follows the execution order is Update / LateUpdate ... Start / Awake / OnEnable ... are not in the specified correct order.

You also have to distinguish between serialized objects which are stored in a scene and runtime generated instances. Awake is called when the object is "loaded". Again, when you call AddComponent to add a certain script, awake will be called before the AddComponent function returns. Same thing for Instantiate(). Awake and OnEnabled will be called before Instantiate returns. If you have two scripts attached that have been arranged in a certain execution order, they won't follow it.

btw. I've done a lot analysis on this issue in the past. The script execution order is a quite new feature which was buggy since it has been implemented. Afaik they fixed it partially, but in the end it still doesn't work.

It actually doesn't make much sense to overanalyse it. Fact is: you can't rely on it, so don't rely on it!

It is true that when a scene is loaded, all serialized objects are created before Awake is called. The objects are actually created two times (just put a debug log into the constructor). First time in the object creation order (the order they have been created / saved / ...) and again when they get deserialized. The deserialization for scene objects follows the execution order. Then all Awake functions are called then Start. They follow the execution order, but only when they are serialized objects in a scene.

You shouldn't take the docs for granted. There are many cases where the docs had wrong examples or misinformation. It often describes how it should work, not how it actually works.

Did you ever get resolution on this bug? We're seeing something similar that is completely messing up our scripts (unreliable order of execution will do that to you!)

Unfortunately not.

We are doing our own execution callback system (for various other reasons as well. This one in case here is actually not the biggest problem. Much worse - for example - is an totally undefined and jagged destruction order)