Quick answer: Mass fragments are raw structs in chunks; the engine doesn’t save them through the standard UObject path. Write your own snapshot processor that exports/imports fragments to a SaveGame UObject.

A MassEntity-based simulation saves the game and reloads — entities respawn but with default values. Fragments aren’t part of the standard save pipeline.

Fragments Aren't UObjects

Mass stores fragments densely in archetype chunks for performance — not as UObjects. SaveGame serialization walks UProperties on UObjects; fragments are invisible to it.

Roll a Snapshot Processor

// On save: iterate entities, copy fragment data into a USaveGame's struct array.
// On load: spawn entities from the saved array, populate fragments.

A MassProcessor that runs once on save/load gives you control over exactly which fragments persist (transform, hp, faction) and which are transient (path, target).

Stable Entity Identity

Mass entity handles aren’t stable across sessions. Store a stable GUID in a fragment (or in the save record itself) and rebind on load — otherwise references between entities break.

Spawn Config First, Fragments Second

Spawn with the right archetype (so the right fragments exist), then copy values in. Don’t try to graft fragments onto an already-spawned mismatched archetype.

Verifying

Save a populated world; reload. Entity count and per-entity values match. Cross-entity references (target IDs) resolve correctly.

“Mass fragments need a custom save path. Snapshot to a USaveGame on save, spawn-and-restore on load.”

For huge populations, a per-archetype binary blob is faster than per-entity records — you control the format.