Question How automatic are job dependencies in ISystem?

I see multiple examples that seem to handle it differently. Some just seem to call:
new Job {}.Schedule()

while others do:
state.Dependency = new Job{}.Schedule(state.Dependency)

Do these end up doing the same behavior? Can I just call the first version without issue or is that a potential source of bugs if the job runs long enough for some other job to attempt to access the same data?

Also do component lookups automatically factor in their read/write status when a job uses one?
I've been getting some error messages like "The system <systemname> writes <componentname> via <jobname> but that type was not assigned to the Dependency property. To ensure correct behavior of other systems, the job or a dependency must be assigned to the Dependency property before returning from the OnUpdate method." I've only seen this issue show up on jobs that access via component lookups. I'm not sure if the problem is not properly assigning the dependency of the job schedule, or if there's something going wrong with how I am grabbing and passing component lookups.

Basically I'm trying to convert a lot of my SystemBase stuff over to ISystem and I'm kind of confused exactly what needs to be updated. There's so much more boilerplate and data passing I need to do manually with ISystem, but the perf on SystemBase is pretty bad =(

 

For IJobEntity, yes. For anything else, use the latter form.

Acquiring the lookup inside the system is when the dependency is registered with the system.

 

Ok, good to know IJobEntity can do it automatically, that covers the majority of my uses.

If I understand what you mean about the lookups correctly, acquiring the lookup anywhere (e.g. OnCreate or OnUpdate) will apply it to the system's dependencies, but in the case of dependencies between jobs within a single system, I'd need to manage their dependencies manually if they aren't all IJobEntity, right?

 

Yes. Usually that involves getting and assigning state.Dependency.

 

I would suggest always use latter for code consistency and explicit look

 

I agree, one thing less to remember and it is more explicit.

 

In case anyone stumbles upon this thread looking for "The system <systemname> writes <componentname> via <jobname> but that type was not assigned to the Dependency property. To ensure correct behavior of other systems, the job or a dependency must be assigned to the Dependency property before returning from the OnUpdate method."

This turned out to just be a nonsense error caused by a different error that led to the OnUpdate not completing normally and leaving things in kind of a broken state. In my case a copy paste error leading to both a writable ComponentLookup<ComponentA> and a (ref ComponentA) for the same component in a job throwing an error in one of my jobs for a duplicate alias.

 

Just want to add to @Ryetoast 's comment (and also because this thread is the top search result for the aforementioned error msg).

The error msg can be deceiving because there are many things that can indirectly lead to it. Here's one more (quite nasty to debug if you are not careful). This will throw the error:

Code (CSharp):

1. new FooJob() { // IJobEntity
2.     entities = buffer.AsNativeArray()
3. }.Schedule();
4.  
5. new BarJob() { // IJobEntity
6.     entities = buffer.AsNativeArray()
7. }.Schedule();

And this will not:

Code (CSharp):

1. var entities = buffer.AsNativeArray()
2.  
3. new FooJob() {
4.     entities = entities
5. }.Schedule();
6.  
7. new BarJob() {
8.     entities = entities
9. }.Schedule();