Time, travel, and save contract

Mass Forge uses Unreal gameplay time for simulation. It does not use wall-clock, platform, or UTC time, and it does not silently carry world-owned runtime state into another world or SaveGame.

Clock sources

The systems intentionally use two equivalent forms of the host world's gameplay clock:

State	Clock	Consequence
Per-ability cooldowns	UWorld game-time deadline	Remaining time is deadline minus current game time.
Shared/global cooldown groups	UWorld game-time deadline	Every ability in the group observes the same scaled clock.
Charge recovery	UWorld game-time deadline	Lazy queries and activations recover every elapsed interval deterministically.
Cast and channel phases	Scaled world delta supplied to the coordinator	Zero delta preserves remaining time; large deltas use bounded channel catch-up.
Persistent durations and periods	Scaled world delta supplied to the subsystem	Zero delta performs cleanup but consumes no duration or period time.
Regeneration and degeneration	Scaled Mass processing delta	Interval accumulation and continuous rates follow the Mass simulation clock.

No Mass Forge duration advances from real time while the game simulation clock is stopped.

Pause behavior

The deferred-command coordinator explicitly does not tick while the game world is paused. Persistent Effect scheduling is invoked only by that coordinator, rather than through an independent tick, so Unreal's normal paused-world scheduling produces these results:

• casts, channels, persistent durations, periodic pulses, regeneration, cooldowns, and charge recovery do not advance;
• queued Entity State Restores, focused Attribute Snapshot Restores, Attribute Changes, counted Gameplay Tag changes, Instant Effects, Persistent Effect requests, Damage, Death Handling, and Abilities remain pending; and
• no gameplay completion or lifecycle event is generated merely because real time passed.

On the first normal tick after resume, queues continue under their ordinary budgets and timed state receives only the gameplay delta supplied by Unreal. Mass Forge does not synthesize the wall-clock pause interval as catch-up time.

A native caller can invoke a subsystem method directly, including the coordinator's public C++ Tick(0) used by automation. A zero-delta coordinator pass may flush queued work and lifecycle validity cleanup, but it does not consume cast/channel time. A zero-delta persistent pass may retire invalid owners, but it does not consume duration or period time. Projects should use the public operation APIs instead of manually ticking subsystems during gameplay.

Time dilation behavior

Global/world time dilation affects Mass Forge because Unreal supplies scaled gameplay delta and advances UWorld game time by that scaled amount.

• At 0.5 global dilation, one real second normally consumes about 0.5 seconds of cooldown, recovery, cast, channel, persistent-effect, and regeneration time.
• At 2.0 global dilation, one real second normally consumes about 2.0 gameplay seconds.
• Variable frame steps preserve earned persistent periods and channel pulses; their configured per-frame caps carry excess work forward.
• Actor CustomTimeDilation is not a Mass Forge clock. Actorless entities have no Actor, so per-Actor dilation does not alter their cooldowns or durations.

If a project needs faction-, entity-, or effect-specific time scales, it must author that as an explicit gameplay rule. Do not infer it from representation Actors.

Seamless travel and world replacement

Mass Forge subsystems and Mass entities are owned by a UWorld. On world teardown, pending queues, request counters, active lifecycles, AI tickets, persistent-effect metadata, inspection providers, and deferred event buffers are discarded without gameplay callbacks. Entity, request, lifecycle, death-handling, and persistent-effect handles from the former world are invalid in the destination world.

Seamless travel may preserve selected project Actors, but Mass Forge does not interpret that as preservation of their former Mass entity or representation mapping. In the destination world:

1. recreate/configure the Mass entity;
2. reacquire its complete generation-checked handle;
3. re-resolve any represented Actor mapping; and
4. restore only the state covered by an explicit supported snapshot or project-owned reconstruction.

Never copy an entity index/serial pair or world-local request/effect/lifecycle ID across travel.

Save and load behavior in 0.2.0

Mass Forge exposes two distinct versioned formats:

• Mass Forge Entity Attribute Snapshot contains configured Vital, Combat, and Support values plus the project schema version. Restore changes only those attributes and leaves other live state unchanged.
• Mass Forge Entity State Snapshot format 4 composes that attribute payload with exact counted tags, ability grants, remaining individual/shared cooldowns, stored charges, remaining charge-recovery time, regeneration interval remainder, active Persistent Effects, and active cast/channel phase. Restore replaces those included sections as one observable transaction.

Neither format contains world-local entity/request/lifecycle/effect handles or absolute world timestamps. The durable entity-state format rebuilds cooldown, recovery, duration, cast/channel, and period deadlines from remaining gameplay seconds in the destination world. Restored Persistent Effects and Ability Lifecycles always receive fresh handles.

Entity-state format 4 retains an active cast/channel's guarded definition identity/version, phase, remaining gameplay time, committed state, completed pulses, and earned channel backlog. A targetless phase restores directly; a self target rebinds to the destination; an external target requires a matching project-owned stable reference plus the recreated destination-world target handle. Old target/lifecycle handles never enter the SaveGame. AI tickets, async observers, deferred requests, event history, Actor representation, pooling, navigation, faction, inventory, quest, and other project state remain excluded.

Formats 1, 2, and 3 remain accepted as explicit compatibility paths. Format 1 has no regeneration section, so restoration resets destination regeneration partial intervals to zero. Format 2 identifies each remainder by stable target attribute and requires the destination to have the same unique target set and tick intervals; incompatible profiles fail atomically rather than shifting a timing phase to another rule. Formats 1 and 2 cannot describe active effects; formats 1–3 cannot describe active Ability Lifecycles. Each rejects incompatible active destination state instead of erasing it.

Projects can save format-4 durable combat state at Mass-idle checkpoints. Persistent Effect self-source contexts rebind to the destination; external source handles are cleared while logical Source ID and captured numeric inputs survive. Active Ability assets are guarded by stable Ability ID, Save Compatibility Version, execution type, and authored timing. Projects must reacquire restored handles through query APIs, rebind lifecycle observers, and never patch compact fragment slots from Blueprint.

Project policy choices

Choose and document one policy per game mode:

• Reset temporal state — use the focused attribute snapshot and recreate all other state from traits.
• Preserve durable combat state — use the format-4 entity-state snapshot at a Mass-idle point; grants, cooldowns, charges, counted tags, regeneration phase, Persistent Effects, and one active cast/channel are restored. Resolve external lifecycle-target references before restore.
• Project-owned reconstruction — retain game-specific state outside the Mass Forge snapshot and deliberately reconnect it after destination entities exist.
• Offline progression — store an external timestamp and deliberately convert elapsed real time into game outcomes during load. Mass Forge never performs this conversion automatically.

Do not mix absolute UWorld timestamps from one world with another world's game clock.

Automated proof

The isolated automation suite proves the currently advertised contract:

• the sole gameplay coordinator opts out of paused-world ticking and owns Persistent Effect scheduling;
• zero game-time delta preserves cast and persistent-effect remaining time;
• synthetic unchanged and half-speed game-clock samples preserve and proportionally consume cooldown time;
• variable-step persistent/channel behavior remains deterministic and bounded; and
• world teardown discards a deliberately pending ability request without invoking its completion callback.

Attribute snapshot tests separately prove deterministic capture, atomic restore, stable-ID slot remapping, format/schema rejection, and versioned rename migration. Durable entity-state tests prove deterministic composition, format-1/2/3 compatibility, stable-target regeneration timing, exact active Persistent Effect continuity, targetless cast continuation, targeted channel reference/remapping, fresh effect and lifecycle handles, resumed periodic phase, changed-definition rejection, complete-state visibility during callbacks, bounded queue ordering/back-pressure, full-generation safety, and teardown discard. Formats 1–4 are also serialized through Unreal's tagged SaveGame archive, deserialized, migrated where required, and restored on every supported engine line; projects remain responsible for testing their surrounding SaveGame envelope and population recreation.