There’s an undocumented DefaultExecutionOrder attribute for which I don’t find any documentation. Is it supposed to work or is it considered internal and subject to change?
[DefaultExecutionOrder(100)]
public class SomeClass : MonoBehaviour
{
}
There’s an undocumented DefaultExecutionOrder attribute for which I don’t find any documentation. Is it supposed to work or is it considered internal and subject to change?
[DefaultExecutionOrder(100)]
public class SomeClass : MonoBehaviour
{
}
It works, I’m using it right now. I googled it because I want to know if the default is 0, why is it undocumented? Weird.
The employees should put this in documentation because when I search this, there are very few results and even the top result is not even showing that it can be used in the script!
I can confirm that the default value is 0.
Awake () of a script with [DefaultExecutionOrder(-1)] runs before Awake () of the rest, in the same frame, for example.
This is great for managers.
This is used in the NavMeshComponents high level API.
I am guessing it is some sort of ranking order for when to run scripts.
This one is collecting a bunch of meshes and terrains into lists so it can dynamically build a navmeshes on them at runtime.
It chooses [DefaultExecutionOrder(-200)] as its rank, although I could swear I have seen some with [DefaultExecutionOrder(10000)], so I think [DefaultExecutionOrder(10000)] means as “last” as possible, and [DefaultExecutionOrder(-10000)] means as “first” as possible.
I think the numbering is done “roughly”, as it is rarely explicitly queued more than once or twice anyway, so no need to try to keep track of integers.
this is the first result from Bing
Official Unity FAQ from the NavMeshComponent high level API:
https://github.com/Unity-Technologies/NavMeshComponents
Q: What’s the deal with the ‘DefaultExecutionOrder’ attribute?
A: It gives a way of controlling the order of execution of scripts - specifically it allows us to build a NavMesh before the (native) NavMeshAgent component is enabled.
See Unity - Manual: Script Execution Order settings for related documentation. Scripts that you order with a DefaultExecutionOrder attribute don’t show up in the Execution Order settings, but the order values follow the same rules.
It’s still undocumented in the built-in attributes section. Some other attributes might be too, I’m not sure.
Here is an example of one that is documented:
On the left you can see others documented but some are missing.
How can I add documentation? Is that even possible?
Edit: I submitted it as a suggestion on the docs page.
If something isn’t documented, there’s often a reason – though sometimes it is just an oversight. For example, the DefaultExecutionOrder was probably left undocumented because its effect doesn’t show up in the Execution Order window, which could lead to confusion.
We aren’t set up to allow community additions or edits to the Unity documentation, though it is something we hope to achieve in the future. Using the suggestion function on the page is the probably the most direct route to doc team. We do see these reports. The more detail in the report, the quicker it is for us to fix. Thanks!
I think this attribute is incredibly useful and should be documented.
Specifically in my case, i actively searched for a way to set the execution order from code, because sometimes unity crashes and some gamobject’s scripts need to be re-added. If these are also part of the script execution order, they get removed from it.
Having it in code is safer, but the script execution order documentation page does not show a way of determining the order in code in any way.
obviously they should, when is this getting fixed?
That’s a joke right? It has to be a joke because “it works but the effect is hidden” is an extremely good reason to document something, not an excuse to skip it. Documentation needs to answer questions such as “My script with a [DefaultExecutionOrder] is not showing in the Execution Order window so is it actually working?” and “This attribute is undocumented so how do I know if it’s reliable?”. If you don’t properly document things like then every individual user needs to waste time testing it to make sure it does what they want (and then they just have to hope it will reliably keep working).
Yeah, I wish.
Take a look at this bug report: https://issuetracker.unity3d.com/issues/iserializationcallbackreceiver-example
The person handling the bug report took the time to figure out exactly what needs to be changed to fix it … but evidently that’s not enough detail because they marked the issue as “Won’t Fix”.
Does that make sense to you? You have an example that is known to not work and the documentation team couldn’t even be bothered to copy and paste some code. So instead, you again waste the time of everyone who tries to use that example as well as more QA time if anyone else sees it and reports another bug.
I’m pretty sure I also re-reported the issue using the suggestion function at the bottom of the page, but there’s no record of that and it was years ago now so I can’t be sure. I guess encouraging people to do it that way instead of reporting bugs through the engine is a convenient way of avoiding the need to tell people that you’re ignoring their reports.
It would be a simple fix for them to have it show up in the UI as well. Just update the Script Execution Order data to have a private isSetFromCode
bool. That way if this bool is set, then during compilation Unity can check whether those marked classes still have the attribute or not, or if the value has changed.
This would not be a breaking change to Unity either, since upon script recompile, the private bool would get updated accordingly for any classes that currently have this attribute, and from then on if attribute is removed, entry is removed from script execution order UI. This shouldn’t affect any existing systems…
MAYBE just maybe try and make the results visible in the window then???
It’s been 14 months since I reported it in the Show Us Your Pain thread. How quickly are we talking about?
Please add docs to this thing.
A better place to ask for this would be the Documentation forum as I very much doubt anyone from the docs team look here.
I have no idea why it’s not documented in the docs. Maybe it was originally private then was made public but the docs were not changed. I’m a little confused because this action should result in a failure to land the change as the doc verification should detect it.
I’ll ask the docs team to see why this might not have been detected. Maybe it’s on some whitelist thing or something.
So I spoke to a nice dev in our internal scripting channel not long ago who said it looks like it was a simple oversight, probably because the attribute was whitelisted in the docs (maybe it was private initially, not sure) so it wasn’t flagged as an undocumented API error.
I was told a few mins ago that they’d look at getting that documented, potentially with any caveats of its usage that might still apply. That won’t happen overnight but it will happen.
Hope that helps.
Minor update then I’m outta’ here: A documentation ticket has been raised and assigned for triage so that’s a real work assignment.
I’m searching and searching but looks like it is still not in Manual.
Is it safe to use this attribute ?
Yes, lots of assets use it.