System is not running if Entities query cant find any

It is a bit confusing but it actually makes the most logical sense for most use cases (and it's performant)

Anyway there are basically 4 cases
1. if there are any entity queries in the system then the system will only run if at least 1 have a result
2. if there are no entity queries in the system, the system will always run
3. if you have multiple queries in a system but require a specific query to have results, you can use RequireForUpdate()
4. if the system has [AlwaysUpdateSystem] it will always run regardless of any of the above

 

To me it's confusing because you don't have an easy overview of what is being run from where. At least with gameobjects you can assume it's enabled when the script and the gameobject are on and it's in the scene you're running.

 

Well, before docs even exist we learned all of this through reading source code (which is easy to understand in that case), don't forget - it's still in preview. But for that specific case, it's past and if you'll open package documentation about Systems in ECS you'll see an absolutely clear description of that behaviour

 

But this requires you to know where these OnUpdates() are by digging through the code. I am slightly in favour of the gameobject-to-entity workflow as you at least know that if it's in the scene it will be a part of ther system(s) running. There are no secrets or obscurities. Very easy to quickly scan to get an overview, especially for non-technical people.

 

There is entities debugger for that. You can easily see. what systems are running and what not. Also DOTS.Editor has Systems window.

 

Additionally there is info regarding query match, telling why system runs, or not.

Worth investigating. Specially when combining entityQuery with Entities.ForEach in the same system.
There are few cave cats catches there, for someone unaware.

 

This caching of entity queries is unintuitive and leads to unexpected behavior without warning. If you wrap your Entities.ForEach query in something like a check to see if a MonoBehaviour exists, you'll be looking at bugs where it ignores that check and performs the query anyway. I ran into exactly this and couldn't figure out what was going on until this thread, in fact.

 

I was not aware it does this, and actually for me this is great Thanks for pointing that out and everyone who explained it!

 

It's important to note that it's not just Entities.ForEach.
Any call on a system that asks for some kind of entity data will trigger this behaviour.

I honestly think it's incredibly misleading and [AlwaysUpdateSystem] should be the default.
Its not uncommon for systems to do things other than query for entities.
The DOTS compiler extensions do some incredibly voodoo S***, this is among the most confusing for new people.

 

Should the more common behaviour not be default? You learn this behaviour pretty quickly and at that point I don't see why you want want it opt out instead.

I just had a quick scan of our project. We have 661 systems and 34 usages of [AlwaysUpdateSystem] for 5.1%

An early out from no matching queries is actually much more efficient as it skips the whole JobHandle dependency combining.

-edit- to just give you a vague idea about how much more performant it is, from unity's patch notes way back

 

Thanks for the numbers @tertle. I can't really argue with that.
I imagine most cases where [AlwaysUpdateSystem] is required is for GameObject interop and are an edge case, e.g. for me, the one that was tripping me up was my camera follow system, I expected it to throw an error when it couldn't find the camera but instead it just didn't run. In this case I expect it to always run as I expect there will always be a camera.

It's really just the way that it's done that is so left of field.
Like you can write a line of code and it not get executed because further down in the body there is an entity query, that's just not normal in any programming language I know of.
TBH, this is probably a problem for tooling to solve.
If Rider gave me a warning that I had some code that wouldn't run when there are no matching entities then I wouldn't get caught out.

 

It's not really *that* 'out of left field', considering this behavior has been mentioned in Unity talks, it's plainly written in the docs, etc. I have seen it mentioned many times in many places and have known this for, what, 3ish years now or however long it's been since DOTS came about? I am not sure what more you are wanting/expecting?

 

First of all, many thanks to tertle for his help!
One crazy thing remains that if I encapsulate a foreach job in a if then{} test, including a query getting some entities in the process of being created (Entity Manager instructions upstream the foreach job), the use of [AlwaysUpdateSystem] appears necessary, while the test can not be

Here is an example:

Code (CSharp):

1. EntityManager.SetComponentData<PhysicsVelocity>(_band, physicsVelocity);
2.  
3.         if (1 == 2)
4.         {
5.  
6.            Entities.ForEach(
7.                        (ref PhysicsVelocity physicsVelocity) => {
8.                            float3 linear = 1f; //just for fill it up
9.                        }).Run();
10.         }

_band is a global Entity in the system

Thanks in advance

 

Of course this has now changed:

 

Yes. Thanks for the useful reminder: system are now always updated, thus it is the opposite to the previous situation.