MonoBehaviour.Start() after Instantiate(GameObject) in Start(): immediately or postponed after Start

https://forum.unity3d.com/threads/when-is-start-on-script-instantiated-game-objects-run.10642/

gives an answer for dynamic script addition. And it answers exactly as asked but that is not enough for me here .

When calling Instantiate(GameObject) inside a GameObject's start() method, is the instatiated GameObject's start() method run immediately or postponed after the instantiating GameObject's start() has finished? If this is documented, where? If not and you have inside knowledge: can this behaviour be relied upon? My test shows it is postponed.

 

Start runs before the first Update call on a GameObject. Which means it's delayed.

If you want something that runs immediately, try Awake.

It's all documented here. https://docs.unity3d.com/Manual/ExecutionOrder.html

 

Hi, the page behind your link doesn't have an answer. It's about start from start and I'm happy with the current behaviour but is it random or reliable?

 

Start is always called immediately before the Update loop on the first frame the GameObject is active. So there is always a delay till the end of the current frame, longer if the GameObject is Instantiated inactive. It's documented, it's reliable.

 

Code (CSharp):

1. void A::start() {
2.   Instantiate(B);
3.   f();
4. }

B::start() before f() ? Reliable?

 

B.Awake will be called before f(), assuming B is active. B.Start will be called after f().

This is reliable, and documented at the link I shared above.

 

This isn't documented at the link shared above, which I already knew, but is surmisable from the introductory text of https://docs.unity3d.com/ScriptReference/MonoBehaviour.Start.html:

"Start is called on the frame when a script is enabled just before any of the Update methods are called the first time."

The key word is "is" in "is enabled" which is not "gets".

Regarding "Awake", "Awake is called when the script object is initialised" is stated in the same text which lets surmise "B.Awake will be called before f(), assuming B is active" in fact.

I don't call this "documented" though because it is not stated explicitly and the execution time of "Awake" still is not clear. My original question is likely answered though.

For items of the "Order of Execution for Event Functions" their execution appears to be horizontally sliced ie. each of these is executed across all actice GameObjects first, then the next item is executed across all active GameObjects. This is deducable from the effect coroutines executed code have on properties of other GameObjects which have a behaviour which also modifies those properties in their "Update".

A publicised spec of the order of execution of these functions when multiple GameObjects and instantiation is involved would make this reliable -- save for bugs or implementations which don't follow that spec unintentionally.

 

Would it be fair to summarize this as: all GameObjects are synchronized across all lifecycle phases, with each phase completing for every GameObject before the next begins, with the exception of Awake and OnEnable, which run out of turn at any phase that a new GameObject is instantiated?