Unexpected behavior when Awake() makes a GameObject inactive

Questions & Answers
1

This has come out of questions with Active/Inactive objects and the Awake() function. At the end of my research I think I’ve encountered a bug - and if not, the documentation (and Unity rep’s forum explanation) are wrong…

So the basic question of “when is Awake() called?” has been asked and answered many times in many ways. One point of confusion is this sentence from the docs “If a GameObject is inactive during start up Awake is not called until it is made active,or a function in any script attached to it is called.”

A few threads I saw pointed back to this explanation by Unity’s Tim C:

This is a bit misleading, it should say: “If a GameObject is inactive during start up Awake is not called until it is made active, or an Unity lifetime function in any script attached to it is called. (OnEnable, OnCollisionEnter)”

Now here’s the issue…
I have two scripts on a gameObject, both with an Awake() function. When my object is activated for the first time, Awake() should be called on both scripts. However, if the early-executing script contains this code, the second script’s Awake() does NOT run:

void Awake() {
  gameObject.SetActive(false);
}

In every thread I’ve read, no one has mentioned this as a possibility, and I had always gotten the impression that if one script’s Awake() was called, every script on the same object will also have Awake() called.

I feel like it didn’t used to work this way, but I don’t have proof of that…

Is this a bug? Especially considering how popular doing object initialization in Awake() seems to be.

2

I don’t think its a bug, I think its just an use case that is not covered in the documentation. It makes sense with how unity processes components top to bottom (as shown in the inspector) as far as I’m aware. It makes sense that Unity would check certain criteria (like if the gameObject is active) prior to processing each successive component. Otherwise you could get conflicting actions from different scripts on a single object.

For example if the first script checked some conditions and determined that this game object should be destroyed right away, you don’t really want other scripts on that object carrying on as if nothing is happening after the object has been marked for destruction.