koobas.hobune.stream
Incorrect Unity Execution Order for OnApplicationQuit?
I'm aware of this doc that tells the execution order of Unity events:
http://docs.unity3d.com/Manual/ExecutionOrder.html
There's also a beautiful chart: 
However, recently I put Debug.Log messages in OnDisable and OnApplicationQuit, and it seems like OnApplicationQuit is actually called first, contrary to what the chart shows. Is this just my copy of Unity, or does everyone else get the same thing?
If someone can try it quickly, here's a script:
using UnityEngine;
using System.Collections;
public class ScriptOrder : $$anonymous$$onoBehaviour {
protected void Awake()
{
Debug.Log("Awake");
}
protected void OnEnable()
{
Debug.Log("OnEnable");
}
// Use this for initialization
protected void Start () {
Debug.Log("Start");
}
protected void OnApplicationPause()
{
Debug.Log("OnAppPause");
}
protected void OnDisable()
{
Debug.Log("OnDisable");
}
protected void OnApplicationQuit()
{
Debug.Log("OnAppQuit");
}
protected void OnDestroy()
{
Debug.Log("OnDestroy");
}
}
I have noticed this too. I wouldn't $$anonymous$$d an official word on it
@alec-slayden: "an official word"? UnityAnswers is not a place for that ^^. Either consult the Forums or if you think the documentation is wrong / misleading file a bug report in Unity.
Of course OnApplicationQuit is executed before OnDisable and OnDestroy since it's
Sent to all game objects before the application is quit
If Unity would destroy the objects before sending OnApplicationQuit there would be no gameobject that could receive that message.
The final OnDisable (as well as OnDestroy) will be invoked as a result of destroying the object when the application quits. Also note there are no arrows within the "decommissioning" section.
The chart might be a bit misleading. Since a lot of these messages can be invoked in different cases, that chart can never cover all situations at once. If it would there would be arrows and lines all over the place. That chart mainly shows the mainloop and everything related to that.
For example "OnEnable" is positioned before "Start". However if a Gameobject was already "started", got disabled and is enabled again OnEnable will be called again but Start won't. Another thing is the way the physics step is described. It doesn't cover the case when a physics step is skipped. In that case the update loop should bypass the whole physics block. In a real flowchart all conditional events (OnCollisionXXX, OnMouseXXX, OnBecameVisible, ...) would need a bypass as well.
