OnEnable, Awake, Start order

Question

I use a "framework" class that is set to run before all the other scripts (-300). T$$anonymous$$s class has an Awake method. I also use another normal monobehaviour w$$anonymous$$ch defines the OnEnable method.

Once the application runs, the OnEnable of the second monobehaviour is called before the awake of the framework class. Is t$$anonymous$$s the intended behaviour?

Answer 1

It's rather complicated.

[

Update 5.1.1: I didn't re-test everyt$$anonymous$$ng, but here is what seems to be fixed/different in both 5.x and 4.x (tested 5.1 and 4.6), as opposed to 3.5:

The bug that the user-defined execution order is ignored if one (but not all) script has an "OnEnable()" function (=see "EDIT3" below) seems to be fixed.
OnLevelWasLoaded() is no longer called before Awake(), and always after OnEnable()
The execution order of OnLevelWasLoaded() is still arbitrary and cannot be user-defined
OnEnable() is no longer called in successive levels if DontDestroyOnLoad is active.

]

A simple test with 3.5.2 revealed, most concurrent functions (well, at least the ones I tested: Awake, Start, OnEnable, FixedUpdate/Update/LateUpdate) abide by the execution order defined for the scripts. The execution order of OnLevelWasLoaded is not affected by that, and therefore cannot be influenced by the user. T$$anonymous$$s could be considered a bug.

The order of the four methods of a script related to initialization is always:

Awake()
OnEnable()
OnLevelWasLoaded() // (only on scene changes)
Start()

However, if your script was disabled in the first place(via Script.enabled=false), t$$anonymous$$s order changes to:

OnLevelWasLoaded() // is now called first, before Awake()! (only on scene changes)
Awake()
[OnEnable()/Start() are not executed until the script is actually enabled]

In addition, note that Awake() and OnEnable() calls are connected/interleaved. Meaning, assuming a particular, user-defined execution order A and B with A*<*B,

each individual script of type A will execute its Awake(), immediately! followed by its OnEnabled()
then all scripts of type B will do the same
then all OnLevelWasLoaded() will be executed, in a (presumably) fixed but unpredictable order (assuming t$$anonymous$$s scene was freshly loaded - otherwise t$$anonymous$$s step is skipped completely)
then all Start() will be executed, in the order A,B

In particular, t$$anonymous$$s means that OnEnable() of type A will be executed before Awake() of type B, w$$anonymous$$le OnEnable() of type B will be executed after Awake() of type A. T$$anonymous$$s overview explains it more clearly:

Awake() of Type A, instance 1
OnEnable() of Type A, instance 1
Awake() of Type A, instance 2 // order of instances cannot be influenced
OnEnable() of Type A, instance 2 // order of instances cannot be influenced
Awake() of Type B
OnEnable() of Type B
OnLevelWasLoaded() of Type ? // order cannot be influenced
OnLevelWasLoaded() of Type ? // order cannot be influenced
Start() of Type A
Start() of Type B

EDIT: Hm, t$$anonymous$$s is a total mess. If DontDestroyOnLoad() is activated for such a script, t$$anonymous$$s will get even more complicated, and the order changes yet again to:

[Awake() is never called again, only the very first time]
OnEnable()
OnLevelWasLoaded() // as opposed to being called before OnEnable(), when DontDestroyOnLoad() is not activated
[Start() is never called again, only the very first time]

EDIT2: In addition, when DontDestroyOnLoad() is active, the user-defined execution order is no longer abided by!, neither by OnEnable(), nor by OnLevelWasLoaded().

EDIT3: WAH! I'm gonna stop testing now, t$$anonymous$$s is a neverending story... As @Noisecrime noticed, there is actually another bug, where user-defined execution order is overriden if the script has an OnEnable() function!

Script A has OnEnable, Script B has not:

Awake() of Type A
OnEnable() of Type A
Awake() of Type B

Script B has OnEnable, Script A has not:

Awake() of Type B
OnEnable() of Type B
Awake() of Type A // after Type B!

Answer 2

Answer by Noise crime · Jun 27, 2012 at 02:08 PM

From the sound of it, t$$anonymous$$s is the 'OnEnable' bug with script execution order. That is I suspect your 'framework' script does not have an OnEnable method in it, in w$$anonymous$$ch case for some odd reason it will get trumped in execution order by the scripts that do, despite any ordering you add to the script execution.

To fix t$$anonymous$$s issue, simply add an OnEnable method to your framework script.

Add comment · Show 4 · Share

Wolfram · Jun 27, 2012 at 03:59 PM 0

Share

huulong · Sep 08, 2015 at 05:23 PM 0

Share

Fattie · Mar 07, 2016 at 02:04 PM 0

Share

Oliver-Bogdan · Apr 28, 2016 at 04:19 PM 1

Share

Answer 3

Answer by Bunny83 · Feb 17, 2012 at 04:19 PM

OnEnable and Awake are called when the objects / script instance is created. They are propably called from the internal constructor. They are even called before Instantiate returns. There is no way to influence when awake / OnEnabled is called on scene objects. The execution order you can set in Unity only influences the Unity generated events like Start, Update, LateUpdate ...

Avoid code in Awake w$$anonymous$$ch relies on other object. Start is made for t$$anonymous$$s purpose. Start is called after all scene objects are created and all Awake function has been called. In general you should use Start to initialize object dependencies.

Add comment · Show 7 · Share

sebas77 · Feb 17, 2012 at 06:50 PM 0

Share

Bunny83 · Feb 19, 2012 at 06:50 AM 0

Share

Noise crime · Jun 27, 2012 at 02:06 PM 1

Share

Wolfram · Jun 27, 2012 at 04:05 PM 0

Share

Bunny83 · Jun 27, 2012 at 06:29 PM 2

Share

Show more comments

Answer 4

Answer by Ashkan_gc · Feb 17, 2012 at 02:31 PM

The manual is not that clear about it. It mentioned OnEnable after Awake in list order but it only said clearly that all Awakes will be called before any Start. again in summary it only shows Start and Awake and not OnEnabled. but for Awake says it will be called After Instantiation and for OnEnabled it says after object becomes enable so theoratically Awake should be sooner than OnEnable.

Add comment · Share

Answer 5

Answer by Immanuel-Scholz · Nov 07, 2013 at 01:33 PM

I just submitted another strange bug, where the scripting order gets violated. If you have the following setup in your $$anonymous$$erarchy (where "Prefab" is any prefab instance):

 GameObject
    +- Prefab
       +- GameObject
          +- Prefab
          +- ObjectWithUnmportantComponent
 ObjectWithImportantComponent

Then the component of "ObjectWithUnmportantComponent" gets executed first, even if it has a script order number $$anonymous$$gher than a component in "ObjectWithImportantComponent".

Add comment · Show 2 · Share

davekalina · Dec 03, 2013 at 08:07 PM 0

Share

Immanuel-Scholz · Dec 03, 2013 at 10:37 PM 0

Share

OnEnable, Awake, Start order

8 Replies

Your answer

Welcome to Unity Answers

Follow this Question

Related Questions