Zum Hauptinhalt springen

Cross-Affect Internals

Routing Sequence​

  1. Component SetData loads settings and, when its source-affect flag is enabled, builds a whitelist from exact map keys under its state root.
  2. UpdateStateTags compares old/new containers. Only exact changed tags present in that whitelist generate trigger calls.
  3. USurvivalSubSystem validates owner/tag/manager and calls ApplyCrossAffect or RemoveCrossAffect.
  4. The manager casts owner to APawn, chooses one of four source maps by Health/Stamina/Food/Temperature root and uses Find for the exact trigger key.
  5. Destination tags are routed by CrossAffect.Health/Stamina/Food/Temp roots through subsystem concrete getters.
  6. Interface AppendCrossAffect/RemoveCrossAffect updates the destination's AffectTags; its pulse handler consumes recognized exact affects.

Health's source whitelist only accepts the Health root. Armor is a separate root and therefore is not automatically a mapped health trigger in this path. Incoming destination affects do not require the destination's outgoing-source flag.

Map and Affect Lifetime​

Maps are copied once when the manager initializes. SetData refreshes component defaults and source whitelists but does not refresh cached manager maps or comprehensively reset destination AffectTags. bUseCrossAffects is used for editor visibility, not a runtime guard in the reviewed manager path.

AffectTags is a set, with no source ownership/counting. Two source triggers can add the same affect; removing either removes it. UpdateStateTags processes additions before removals, so replacing one mapped source with another that shares an affect can also remove the just-added effect. Define and test overlap behavior before relying on it.

The manager has hard-coded destination families and concrete component lookups. An additional component/interface or tag root does not automatically extend routing. Custom effects need both emission/routing and consumption logic. See Gameplay Tags and Extensibility.