EDIT: got an additional issue described here
I get this error after upgrading to entities 0.14:
I think just a simple example of how to use it would help me out
EDIT: got an additional issue described here
I get this error after upgrading to entities 0.14:
I think just a simple example of how to use it would help me out
What type of generics or custom jobs are you using in your jobs?
I couldn’t create a repo myself using generics in various ways, but looking at source it appears related to the job scheduler code gen.
My use case looks like this:
Something to note is that the system inheriting from the base generic system lives in a different assembly, which I suspect might be why I get this? It worked just fine before though
public class MyBaseSystem<T> : SystemBase where T : struct, IMyInterface
{
public struct MyJob<T> : IJobChunk
{
public struct T MyThing;
// .....
}
}
// In another file and another assembly:
public class MyCustomSystem : MyBaseSystem<MyCustomType>
{ }
Can’t try right now, but if it is like RegisterGenericComponentTypeAttribute then the usage would be:
[assembly: RegisterGenericJobType(typeof(MyBaseSystem<MyCustomType>))]
In your use case
thanks! This got rid of the compilation errors
But now during play this error is spammed:
The only part of my code that is referenced in this error is “ExampleMovingPlatformSystem.cs:34”
This appears to be unrelated to my generic jobs. Line 34 is just a call to Entities.Foreach:
Dependency = Entities // this is line 34
.ForEach((Entity entity, ref PhysicsVelocity physicsVelocity, in PhysicsMass physicsMass, in Translation translation, in Rotation rotation, in ExampleMovingPlatform movingPlatform) =>
{
/// .........
}).ScheduleParallel(Dependency);
Sounds like 0.14 probably made some significant changes when it comes to job reflection data and I’d better revert to 0.13 for the time being.
EDIT: actually I get one of these errors for each of my Entities.ForEach calls in my project apparently
Are you using Entities.ForEach within generic systems? Had a couple of issues with it, migrating to IJobChunk was the only way I could find to fix it
No generics used anywhere in the systems where I get the new errors
Just out of interest, are all your foreach passed a dependency and return a dependency?
Wondering if we can narrow it down to a specific bad code gen because I’m not getting any errors in any of my libraries after upgrading. Be nice to know what to avoid.
Yes that is the case. If anything this might still be caused by another generic job somewhere in the dependency
Wondering if there are any updates on this. I am almost certain it is caused by the combination of using Unity 2020.2 and Entities 0.14. The problem does not appear with 2020.1 + Entities 0.14, or with 2020.2 + Entities 0.13
So for now I either can’t upgrade to 2020.2, or can’t upgrade to Entities 0.14
Hi, you’re right that we made substantial changes to reflection data in 0.14 and unfortunately some bugs crept in.
We have landed a couple of fixes to the reflection data post processor after we discovered the issues and the next release should sort it out. In the mean time the workarounds are: stick with 0.13, rewrite to be non-generic or stick with 2020.1, as you point out.
Sorry for the trouble!
I had the same issue with a generic IJobChunk. What i did for now is using the manual iteration over chunks in an IJobFor as shown in the Documentation.
I hit the same issue when updating my project so I guess I’ll stay on 2020.1 for now. Thanks for the info @deplinenoise !
This error hit me as well. It would be very helpful to confirm that this actually a bug, and not an intentional change going forward that will prevent us from using generic Jobs like we did in 0.13.
Is it actually a bug?
I pray that it is, rather than a design change. A fundamental part of our DOTS code hinges on us being able to use generic jobs without declaring all of the possible permutations ahead of time.
Works for me this way:
Unity 2020.2.0a21.2837 | Entites 0.14.0-preview.19
using Unity.Burst;
using Unity.Collections;
using Unity.Entities;
[assembly: RegisterGenericJobType( typeof(GenericChunkJob<Cp2> ))]
public interface IFloatValCp: IComponentData{
float Value{ get; }
}
public struct Cp1 : IComponentData{
public float Value;
}
public struct Cp2 : IFloatValCp{
public float Value{ get; set; }
}
public class SpecificChunkJobSystem : GenericChunkJobSystem<Cp2>{
protected override void OnCreate(){
var e = EntityManager.CreateEntity( typeof(Cp1), typeof(Cp2) );
EntityManager.SetName( e, "GenericChunkJobSystemTester" );
EntityManager.SetComponentData( e, new Cp1(){ Value = 10000 } );
EntityManager.SetComponentData( e, new Cp2(){ Value = 1} );
base.OnCreate();
}
}
public class GenericChunkJobSystem<T> : SystemBase where T: struct, IFloatValCp{
EntityQuery _query;
protected override void OnCreate(){
_query = GetEntityQuery(
ComponentType.ReadWrite<Cp1>(),
ComponentType.ReadWrite<T>()
);
}
protected override void OnUpdate(){
var job = new GenericChunkJob<T>{
Cp1TypeHandle = GetComponentTypeHandle<Cp1>(),
TTypeHandle = GetComponentTypeHandle<T>(true)
};
Dependency = job.ScheduleParallel(_query, Dependency);
}
}
[BurstCompile]
public struct GenericChunkJob<T> : IJobChunk where T: struct, IFloatValCp{
public ComponentTypeHandle<Cp1> Cp1TypeHandle;
[ReadOnly] public ComponentTypeHandle<T> TTypeHandle;
public void Execute(ArchetypeChunk chunk, int chunkIndex, int firstEntityIndex ){
var chunkCp1 = chunk.GetNativeArray(Cp1TypeHandle);
var chunkT = chunk.GetNativeArray(TTypeHandle);
var instanceCount = chunk.Count;
for (int i = 0; i < instanceCount; i++){
var cp1 = chunkCp1[i];
cp1.Value += chunkT[i].Value;
chunkCp1[i] = cp1;
}
}
}
I may be assuming the wrong thing about the RegisterGenericJobTypeAttribute. Based on Joachim’s comments in some other threads, I had been assuming any and all generic jobs were now intentionally undetected to Burst, unless you use this attribute.
@tertle , are you saying that, using Entities 0.14 and Unity 2020.2b (or later), you’re able to use at least some generic jobs like you did in 0.13, without the use of RegisterGenericJobType?
Commented here I finally ran into a use case where this popped up, though the bug annoyed me more.
But to be honest I use very few (if any) generic job/systems
so just to verify - you haven’t seen any cases of a generic job working with the latest versions?
Adding the "[assembly: (…)] part solves it now:
[assembly: RegisterGenericJobType(typeof(MySystemAJob<MyComponentA>))]
public class MySystemA: MyBaseSystem<MyComponentA>
{ }
Needing to add the assembly part is the problem. This constraint may seem fine on paper, but it has seriously messed up our code.