Execution Order of Components

Hello,

Are there any guarantees made to the execution order of components?

Specifically, if I have a component a and a component b, can I be sure that b will receive exactly 1 update between any given 2 sequential updates of a? Must I assume it is possible that a may have 2 updates before b receives any, forcing a two-frame window for state checks, and complicating the matter beyond a simple bit switch?

Thanks for any insight you can give.

Just to expand on what I originally wrote:

I need to set some state indicating when a component has made a change. To do this, I expose a bool, and set it to true whenever the change occurs, which is somewhere in the scope of the Update() method. At the start of Update(), I set the flag to false. The result is, the flag is on for the rest of the frame that the change was made in, and from the start of the next frame until Update() is called again on the component.

With a guaranteed execution order, I can be sure that this flag can be seen by all other components.

Without, I cannot be sure of that, and must extend the flag's lifetime to two frames to be sure it is seen by all observers. The complications this introduces are not significant, but better to be avoided.

 

All components are updated once per frame (fixed update is more variable than that... but all components will get the same number of fixedupdates per frame).

The order of the components updates are not guaranteed.

Unless you define the execution order for components:
https://docs.unity3d.com/Manual/class-MonoManager.html

All components without an execution order basically occur at the "0" point in that setup (noted as 'Default Time' in the inspector). So all negatives go in order, then all unconfigured ones in a non-guaranteed order, than all the positives ones go in order.

...

My suggestion though is that you usually shouldn't have too many scripts defined in the Execution Order. There are definitely times that you need it (especially for Start ordering)... but if you're heavily relying on it (talking 10's if not 100's of components in there). I would start to rethink your design.

 

Does execution order stay consistent, whether ab-ab-ab or ba-ba-ba, vs. ab-ba-ab or ba-ba-ab? Is there anything in particular that could make the order just change unexpectedly?

 

Thanks very much for the details. I appreciate the reference link, too.

Knowing this, I probably only need a single coordinating component to do what I need to do.

 

My guess, and it is a guess, is that the order is not guaranteed to stay the same, but the likelihood that it changes is probably fairly low, with the exception of adding/removing components to the schedule.

 

So the order isn't exactly documented, so it could change from version to verson.

From my years of experience, it appears the order is defined by the when the object was created. So... so the scene loaded with an A in it, then a B was loaded in... it'll go AB,AB,AB,AB,AB, but if another A is loaded it'll become ABA,ABA,ABA,ABA.

But yes, it generally stays consistent from frame to frame.

My theory is that on the C++ side when components are created I bet they're inserted into a linked list based on their execution order number. There must be some collection out there somewhere since they have to have a way to reference them. And that collection changing order from frame to frame would be more costly than it staying constant. But what that collection is, how it's order is initially defined, and all that... Unity doesn't tell us.

So like I said... it's not guaranteed, and it's not exactly documented. This "could" change for any unknown reason. So you shouldn't rely on it. Instead use the execution order utility I linked to configure anything you need guaranteed.

...

Also, to give you an example of an execution order, here is one of mine:


Note several of them are for tools brought in. Like Aron Granberg's A* project, or Text Mesh Pro.

My personal scripts there are only 10 of. And arguably, that's on the high end IMO. Most of them are scripts I could use for controlling others around just like @CashewTheCat considered:

But some of them are just hacked in there like PlayerWeaponPouch/WeaponPouch because well... sometimes you just need to get a game done and not worry too much about things.