This weekend, I finally got to take advantage of collections being unmanaged and migrated some of my custom command buffer and collection dependency tracking tech to work in Bursted unmanaged systems. Almost everything is working correctly, but I did come across a few surprise bugs.
Bug 1: Discard in idiomatic foreach
// Broken
foreach ((_, var entity) in Query<RefRO<Faction> >().WithEntityAccess().WithAll<FactionTag>())
{
m_factionsCache.Add(latiosWorld.GetCollectionComponent<FactionShipsCollisionLayer>(entity, true));
factionEntities.Add(entity);
}
// Works correctly
foreach ((var unused, var entity) in Query<RefRO<Faction> >().WithEntityAccess().WithAll<FactionTag>())
{
m_factionsCache.Add(latiosWorld.GetCollectionComponent<FactionShipsCollisionLayer>(entity, true));
factionEntities.Add(entity);
}
Bug 2: Concrete generic jobs aren’t picked up by codegen for early init
Two years ago, there was a hot topic on the forum revolving around the use of generic jobs. That ultimately lead to this repo: GitHub - Dreaming381/BurstGenericsTest: Experiments showing how to use a Fluent API with generic jobs and Burst
Anyways, I have been using this pattern since, and it has always worked, except when I tried to use it inside a Burst ISystem. Bug report is IN-19950. If you want a working version of the project, you can find it here, linked to the exact line where I had to comment out [BurstCompile] for one of the systems that was reliant on this pattern: lsss-wip/Assets/_Code/SubSystems/Gameplay/ShipVsBulletDamageSystem.cs at ccebc78a2e9562eead13e0e74c19deb07579d08d · Dreaming381/lsss-wip · GitHub
Note, the bug report made a mention of another type handle warning issue. I just found the culprit and it is my fault, so ignore that.