Please replace the archaic script selector in the Script Execution Order settings screen.

News & General Discussion
1

The dropdown doesn’t respect taskbar placement (it’s impossible to use if you have more scripts than can fit on screen and you have your taskbar set to the top of the monitor), and when there’s a lot of scripts, your only option is to find the tiny down arrow and hold it for a minute or two until you get to the page of the script you need.

Please replace it with just a simple drag & drop object field so we can drag script files onto the field and it adds them to the list to have their execution order changed.

This would be both easier for users and more consistent with how this sort of thing is done elsewhere.

2

I could have sworn this was already supported? Drag a script from the Project panel to somewhere near the “default” slot.

Edit: Yeah, just checked. Definitely works that way in 2019.2. I agree that the other selection UI should be removed / updated, though.

3 Likes
3

Yep, works on mine as well. Thanks!

But there’s nothing in the UI to indicate that’s possible, so I had never discovered it after years of use. They should add a label or something “(drag script here to add)”

1 Like
4

To be honest though, if you’re using Script Execution Order settings you’re probably designing your application wrong.

1 Like
5

Generally true… but you might have deal with a 3rd party tool that is outside your control.

6 Likes
6

Script Execution Order is pretty useful for game startup, since almost all runtime code is reliant on scene objects.

2 Likes
7

Depends…

8

that’s why I said almost my friend

9

“Almost all” implies majority. It many times is not the case.

[Edit: but this is not the point, sorry for the derail]

1 Like
10

Like what? What code can initialize without reliance on a scene object, unless you’re hooking into the PlayerLoop, which is a experimental feature?

EDIT: Actually, never mind. Even code accessing the PlayerLoop of course needs to be initialized.

11

I would love to agree but unfortunately Unity’s own packages require this system as well.

4 Likes
12

You only need one such object if you want to take control of this stuff yourself. Doing this to varying degrees can give you other benefits, too. Eg: if execution order is important for you, you can ignore Unity’s update calls and propagate them yourself, giving your per-object granularity rather than just the per-type ordering Unity gives you.

In general, though, designing your code to be as execution-order independent as possible is the way to go. It’lll help you avoid lots of implementation trickiness and potential subtle issues.

1 Like
13

This is great advice in an academic vacuum, but real game development is about solving problems and optimizing. As a simple example, my camera matcher script (that makes sure multiple cameras match each others’ transforms and FOVs) needs to run after the base camera logic, but before LateUpdate. Otherwise, everything’s off by a frame and it makes the render swimmy when there’s fast camera movement.

There are hundreds of use cases for this feature, which is why Unity included it in the first place. Moreover, your best argument against it is to re-implement the stack yourself in one object? Why even use Unity at all then? Just re-implement everything yourself in a perfect way in your perfect world. The rest of us will continue to use the tools at our disposal to make games.

1 Like
14

Making sure the level of control you have is represented in the UX is far more interesting a discussion than "why would you want to do that?"

2 Likes
15

Excuse me? I think there’s been a miscommunication somewhere.

1 Like
16

Enjoy your tools while they last, because on the topic of re-implementing everything yourself in a perfect way, DOTS doesn’t use the Script Execution Order dialog. Instead it uses attributes such as UpdateInGroup, UpdateBefore, UpdateAfter, etc.

2 Likes
17

Sorry. While I was arguing against the points presented in your post, my tone of annoyance was meant to be directed more towards xVergilx’s original asinine comment. I should have made that more clear in the original reply.

18

No worries. Please do note that I wasn’t saying you shouldn’t use Unity’s built-in version, or that you need to roll your own as I was saying you could. My points were deliberately idealistic and/or extreme to illustrate a point, which is why I qualified them with “if you want to” and “in general” and such. :wink:

I’ll have to look into this. That sounds like a much better system. I absent-mindedly wonder how they deal with cyclic references in those update order dependencies…

1 Like
19

I mean, this is a good thing. This is actually offering the kind of control that’ll be a major boon in this situation.

But as a future solution, it doesn’t do very much in terms of dealing with present monobehaviour… behaviour.

2 Likes
20

On topic:
If you need something to be updated in a certain order - I highly suggest you to do not use script execution order. Do it manually. It is usually one or two things that need that manual ordering.

Everything else should work as is in your application. Don’t communicate between components in Awake, do it in Start.

As for the LateUpdate:
I’ve had a huge trembling issue with a camera / IK / FP model / that I’ve spent a whole two weeks reordering script execution order and debugging.
Then I’ve fixed it by simply making single script that controls what should be done and when regarding camera control.

Three lines of code and that issue went gone.

Not everything in Unity should be treated as given. And no, it is not academic or anything.
You can and should think about application architecture. Otherwise you’ll screw yourself in the long run.

Script execution order may be useful for prototypes, but it will bite you in the end. Everything in your application should be order independent and work correctly without any ordering. If its not working - then you’re doing it wrong.

Nobody’s talking about re-implementing everything, I’m just suggesting that some things better done manually, than blindly trusted upon non-reliable compilation and meta files.

Events is another option as a solution. But that’s another story.

Offtopic:
My initial intention was not to irritate you or anything, its just an advice. Even if it is harsh - it is a reality.
SEO usage is quite limited, and the whole Unity’s default design fall down to pieces as the size of the project grows.
If you don’t enforce some kind of architecture for your application at that point - everything will breakdown and burn in flames. Eventually.

Its up completely your decision to use SEO, or not.
I do not advice to use it if you’re planning to make anything but the smallest games.

Convienient solution doesn’t mean it is a correct one.

Also, as mentioned above, DOTS actually provides a semi-correct way of ordering execution.
Although it is still worth noting that custom bootstrap for DOTS is also a highly viable option for large projects.