Issue with shared FEntityCreationContext in UMassAgentSubsystem::HandlePendingInitialization

Development Programming & Scripting
, ,
1

This question was created in reference to: [Mass entities initializing fragments on the incorrect archetypes due to shared [Content removed]

With reference to the previous question, we have applied the suggested fix (CL 45139186); however, we are still experiencing some issues related to the behavior described there.

In UMassAgentSubsystem::HandlePendingInitialization, there is a FEntityCreationContext for all iterations of the PendingAgentEntities processing loop. This results in the CreationContext accumulating all EntityCollections created up to that point in the flow.

To illustrate what we are seeing, we have the following configuration:

* ActorA, with a MassAgentComponentA and EntityConfigA (containing Fragment1 and Fragment2).

* ActorB, with a MassAgentComponentB and EntityConfigB (containing Fragment1 and Fragment3).

In UMassAgentSubsystem::HandlePendingInitialization, there are two entries in PendingAgentEntities. We do not observe the issue during the first iteration of the loop.

However, during the second pass, within the flow UMassSpawnerSubsystem::SpawnEntities -> UMassSpawnerSubsystem::DoSpawning -> FMassEntityManager::BatchSetEntityFragmentValues, the call to CreationContext->GetEntityCollections(*EntityManager.Get()) returns two EntityCollection objects. These are then processed using the FragmentInstances belonging to EntityConfigB.

At this point, the Entity from ArchetypeA is being processed using the Fragments from ArchetypeB. This causes FMassArchetypeData::SetFragmentData to exhibit unexpected behavior regarding the memory of EntityA’s Fragments:

- Fragment1 (the one present in both configurations): It is reset to its initial values, overwriting any values assigned during the first iteration of the loop.

- Fragment3: It triggers a Warning (and previously triggered a FindCheck without CL 45139186) because Fragment3 does not exist in the archetype defined for EntityConfigA.

Our current understanding is that FMassEntityManager::BatchSetEntityFragmentValues should only operate on entities matching the EntityTemplate passed as an argument, but it seems to be affecting all collections within the CreationContext.

Is this understanding correct? Do you have any suggestions for a potential fix or a workaround we could apply here?

Thank you for your help.

[Attachment Removed]

2

Steps to Reproduce

1. Create a MassEntityConfigAsset (EntityConfigA), add the AssortedFragments trait and add two different fragments (Fragment1 and Fragment2).

2. Create an Actor (ActorA), add the MassAgentComponent and assign EntityConfigA.

3. Create another MassEntityConfigAsset (EntityConfigB), add the AssortedFragments trait and add two different fragments. One should be the same and the other different from the ones on EntityConfigA (Fragment1 and Fragment3).

4. Create an Actor (ActorB), add the MassAgentComponent and assign EntityConfigB.

5. Place ActorA and ActorB on a level and hit Play.

6. Set a breakpoint on UMassAgentSubsystem::HandlePendingInitialization, and monitorize the callstack UMassSpawnerSubsystem::SpawnEntities -> UMassSpawnerSubsystem::DoSpawning -> FMassEntityManager::BatchSetEntityFragmentValues -> FMassArchetypeData::SetFragmentData

7. On the second iteration of the loop, you should observe that Fragment1 on the Entity of type “A” resets to its initial values, and when Fragment3 is processed, the FindCheck will be triggered (without CL 45139186) or a Warning will be logged (with CL 45139186).

[Attachment Removed]

3

Hi there,

Thank you for the detailed report and the repro steps. That context was very helpful.

I was able to reproduce the issue on my end, and your understanding is correct. In the current implementation, HandlePendingInitialization creates a single FEntityCreationContext that is reused across all iterations of the PendingAgentEntities loop. When SpawnEntities eventually calls into BatchSetEntityFragmentValues, the function operates on all entity collections registered with the provided CreationContext. It does not internally filter those collections by archetype or by the EntityTemplate used in the spawning flow, which leads to the warning.

The reasonable workaround would be to move the creation of the FEntityCreationContext inside the PendingAgentEntities iteration, so that each iteration operates on a fresh context. For example:

TArray<FMassEntityHandle> Entities;
TSharedPtr<FMassEntityManager::FEntityCreationContext> CreationContext = EntityManager->GetOrMakeCreationContext();
CreationContext = SpawnerSystem->SpawnEntities(EntityTemplate, NewEntityCount, Entities);

This ensures that the CreationContext only contains the entity collections relevant to the current template.

I hope this clarifies things. I’ll update this case with the issue tracker link once it’s available. Please let me know if you have any further questions.

Best regards,

Henry Liu

[Attachment Removed]

4

Hi there,

I have submitted a new bug report for this issue, and once it is reflected publicly, you will be able to view it here.

An engine developer will investigate the bug at a later date. We don’t provide updates on EPS, but progress can be followed on that public issue tracker page. I will go ahead and close this case now, but feel free to respond here if you have any follow up questions.

Thanks,

Henry Liu

[Attachment Removed]

5

Hi,

We have implemented the workaround on our side, and it is working fine.

Thanks for your support!

[Attachment Removed]

6

Thank you for the update.

I will close this case now. Feel free to respond here if you have any follow-up questions.

Cheers,

Henry Liu

[Attachment Removed]