I’m unsure if this was introduced in 5.6, as looks as if it could have happened back in 5.5, but we’re seeing a failure in FMassEntityManager::BatchSetEntityFragmentValues->FMassArchetypeData::SetFragmentData->FragmentIndexMap.FindChecked(FragmentType) when starting some levels. This is because in UMassSpawnerSubsystem::DoSpawning, the CreationContext grabbed from BatchCreateEntities->…->ObserverManager.GetOrMakeCreationContext gets a ActiveCreationContext that is shared across all PendingAgentEntities in UMassAgentSubsystem::HandlePendingInitialization. So the entity collections passed into BatchSetEntityFragmentValues from CreationContext->GetEntityCollections(*EntityManager.Get()) contains all of the entities created so far in the pending creation loop, even if those entities have very different archetypes. There is nothing seemingly gating the set of initial fragment data on entities that actually share the template/archetype of the entities being actively spawned and so it just tries to set it on all of the entities that have been spawned so far and fails the FindChecked call when it can’t find a fragment on one of those earlier spawned entities.
This seemingly should have been an issue in 5.5 because GetOrMakeCreationContext existed in FMassEntityManager back then and similarly used a shared CreationContext, so I haven’t quite found what saved it or if this was just a timing case we had not hit. Generally entities of the same archetype are spawned together and rarely do we have multiple in the same frame so perhaps that is why this has flown under the radar.
It does appear to also rerun RunProcessorsView for each entity accumulating on each spawn. I’m surprised this isn’t running BatchSetEntityFragmentValues/RunProcessorsView just over the SpawnedEntities here.