MassActorSpawner budgeting vs. actual actors

Development Programming & Scripting
, ,
1

We are currently trying to use Mass Representation system to spawn a actors for NPCs in game. That means these actors actually execute logic, and are quite important for the game.

There are some issues I am running into with the whole spawning/despawning pipeline.

  1. It has a despawning budget, and if that runs out, it “deactivates” the remaining actors. However this “deactivation” doesn’t properly disable much on the actor, only visibility, collisions and ticking. Components are not disabled (or even notified) in any way.
  2. It also has a spawning budget, which is much higher by default. Is it possible that in high-density areas, actors will be spawning faster than despawning, possibly exceeding LODMaxCount? Or is spawning inherently so much slower than despawning that this won’t happen?
  3. When spawning an actor, there is no check whether an actor for the same mass entity already exists, so if despawning gets delayed a lot, there could be two actors for the mass entity.
  4. Actor can outlive the mass entity by several frames. Or is there some immediate despawn for when entity is destroyed?

From what I understand, Mass Representation isn’t really meant to be used with important actors like this, however I have the impresion, from your previous answers, that we are not the only ones using it this way, and I imagine these issues are quite universal. Have you managed to solve these issues? Or are there some plans to address any of them in future updates of mass?

[Attachment Removed]

2
  1. You are correct that the deactivation is only removing collision, visuals, and the actor’s tick. The idea was that the Actor would be destroyed shortly after in the following frames, but it would remove it from the player’s way. If you needed a more involved shutdown, you would need to modify the code to enumerate and disable tick of components as well. In our use for The Matrix Awakens, disabling was enough while the subsystem destroyed the actors on following frames. The pooling system would allow for doing something along these lines inside of PrepareForPooling, but it is only an interface so you would need to add that code. I would detach any controller if one exists and stop the more critical components from ticking which would hopefully only be a few.
  2. It normally is more expensive to spawn an actor than for the destroy. It also more impactful that Actors get spawned to support gameplay than the remove them. The delayed remove also allows for less GC impact for the destroyed actors. It is theoretically possible that more actors are spawned than despawned, but I do not think we encountered that scenario ourselves. You may also looks at the pooling system as it does not need a full destroy but release back to the pool. I don’t think you should encounter this particular situation, but I would be HIGHLY interested to get details about it if you ever do.
  3. I believe Mass should not care about the disabled actor for the entity. In fact, the MassAgentComponent should unregister before being put in the deactivated actors pool inside of DestroyActor. Are you seeing weird behavior from the “zombie” actor for the entity?
  4. If the entity is destroyed, the actor should be destroyed immediately. The representation fragment destructor processor has a call to release the actor and supplies the argument for bIsImmediate to be true.

-James

[Attachment Removed]