Order of startup function after deserialization

Hi, since I started developing my plugin for the editor, every day I am faced with more and more problems due to a lack of understanding of some of the features of its inner work, I decided to do my own research and fully understand how the editor works and in what conditions.

And when I tried to figure out the order in which all editor functions were run, I ran into strange behavior (maybe it’s not). So, look, when there is a “hot reboot” occurs (recompile the scripts), the following scenario runs (hereinafter referred to as MonoBehaviour - MB, Editor - ED):

MB disable → ED disable → MB before serialization → MB after deserialization → MB VALIDATE → MB ENABLE → ED Validate → ED Enable and so on.

BUT this scenario only works if you add the script to the game object and DO NOT change any of the serializable values. If you change, then the last “nodes” are swapped like this:

ED Validate → ED Enable → MB Validate → MB Enable.

That is, the editor script will be launched first, and only then the MonoBehaviour script, because of this I could not understand for a long time why my editor script constantly spits “null reference” after deserialization.

So, my question is - why does the order of launching functions change like this? Is this normal or a bug?

Screen 1: 2.jpg - Google Drive
Screen 2: 1.jpg - Google Drive

Fascinating bit of advanced timing research you did there. This is the only timing info I know of:

I see something vague about OnValidate() that says: “which can occur at various times,” so maybe other things are similarly hamajang timing-wise?

Can you get it to work in your application by maybe making “lazy” getters so they tolerate either order rather than throwing a nullref?

Yeah, i was surpirsed myself when i discovered this behaviour after deserialization.

“Execution order” in manual mostly describe behaviour in play mode, but when you’re writing scripts for editor only it works little bit different.
About OnValidate() i think you missed the part:

i think various time mean the unity events such as load, reload and so on, but not the various time in the code.

And, of course i can, we’re proprammers, we can do everything even repair the oven ;D But the fact is, it is a strange bahaviour, when think it should work in one way every time and trust it, but it dont.

1 Like

If I had a dollar for every time that happened to me. :slight_smile:

1 Like