Ability lifecycle

Mass Forge supports instant abilities, delayed casts, and periodic channels without requiring an Actor or UObject per entity. One cast or channel may be active on an ability-enabled entity at a time; compact grant, cooldown, and charge data remains in the Mass fragment, while only currently active lifecycle definitions are retained by the world subsystem.

Authoring modes

Choose Execution Type on a Mass Forge Ability Data Asset.

Mode	Required settings	Commit point	Periodic output
Instant	No lifecycle timing	Inside Activate Mass Forge Ability	None
Cast	Positive Cast Time Seconds	When the cast finishes	None
Channel	Positive Channel Duration Seconds and Channel Period Seconds; cast time may be zero	Before channeling begins	Channel Self Effects and Channel Target Effects

Instant preserves the original synchronous behavior. A cast/channel activation request first runs the complete grant, target, policy, tag, cooldown, charge, requirement, and affordability check. If accepted, bLifecycleStarted is true in the activation result and the active state begins in Casting.

Commit and cost rules

Costs, charges, individual/shared cooldowns, activation Instant Effects, and activation Persistent Effects commit together only after the cast delay ends. The complete activation is revalidated at that point. A target that vanished, a newly blocking tag, an exhausted resource, or another changed rule produces Commit Failed without a partial transaction.

• Cancelling or interrupting before commit spends nothing.
• After a channel commits, stopping it prevents future pulses but does not refund its already committed cost, charge, cooldown, or activation outcomes.
• A cast completes immediately after its one atomic commit.
• A channel commits once, then each pulse is a separate atomic self/target Instant Effect transaction. Ability costs are not repeated per pulse.
• Execute Channel Tick On Start adds a pulse immediately after a successful channel commit. It does not replace the regularly scheduled pulses.

This contract deliberately avoids implicit refunds after gameplay effects may already have been observed.

Blueprint control and state

Use these entity-handle nodes:

• Get Active Mass Forge Ability Lifecycle
• Cancel Active Mass Forge Ability
• Interrupt Active Mass Forge Ability
• Queue Active Mass Forge Ability Cancellation
• Queue Active Mass Forge Ability Interruption

Matching ...from Actor nodes resolve represented Mass entities for Actor-driven UI and gameplay. The lifecycle state reports a positive world-local lifecycle ID, ability ID, target handle, Casting or Channeling phase, remaining phase time, completed channel-pulse count, and whether the activation transaction has committed. Idle entities return No Active Ability with lifecycle ID zero. The ID distinguishes successive instances of the same ability on the same entity; it is runtime coordination data, not a persistent or replicated identifier.

Safe queued ownership and lifecycle control

Every common mutating Ability operation has a bounded deferred counterpart:

Direct operation	Safe queued operation
Grant Mass Forge Ability	Queue Mass Forge Ability Grant
Revoke Mass Forge Ability	Queue Mass Forge Ability Revocation
Activate Mass Forge Ability	Queue Mass Forge Ability Activation
Cancel Active Mass Forge Ability	Queue Active Mass Forge Ability Cancellation
Interrupt Active Mass Forge Ability	Queue Active Mass Forge Ability Interruption

All five operations share one FIFO, one pending limit, one per-frame budget, and positive world-local request IDs. Bind On Ability Operation Request Completed and match its request ID. The completion identifies the operation, full source/target generations, submitted Ability ID, captured lifecycle ID where applicable, terminal result, and detailed activation result for Activate. The older On Ability Request Completed event remains available for Activate requests only.

Grant and Activate retain a soft definition reference plus its stable ID, then reload and revalidate both at execution. Revoke retains the submitted stable ID. Cancel and Interrupt capture the exact positive lifecycle ID observed at submission, so delayed control cannot end a later replacement cast/channel. No Active Ability means the captured lifecycle ended before execution; Lifecycle Changed means another lifecycle replaced it. Rejected submissions have request ID zero and never emit completion.

Successful grant/revoke/lifecycle events publish before the operation completion. Work enqueued by an Ability-operation completion callback waits for the next Ability Requests phase even when budget remains, preventing an unbounded callback flush.

For a progress bar, VFX controller, audio controller, or Blueprint-only HUD, use the async Observe Mass Forge Ability Lifecycle node with an entity handle and optional ability ID. It observes an already-active matching lifecycle or waits for the next one, then exposes Started, Committed, Channel Tick, Ended, and Failed execution pins. It automatically releases its subsystem bindings after the matching lifecycle ends. Calling Cancel Observation only releases the observer; it never cancels the gameplay ability.

Starting another ability while a lifecycle is active returns Active Ability In Progress. Can Be Cancelled and Can Be Interrupted are independent authoring switches; blocked requests return Cancellation Blocked or Interruption Blocked. Revoking the definition currently being used force-ends that lifecycle with the Ability Revoked reason regardless of the interruption switch.

Events

Bind on Mass Forge Ability Subsystem when presentation or project rules need lifecycle notifications:

• On Ability Lifecycle Started fires after an accepted cast/channel is registered.
• On Ability Activated fires only when its atomic activation transaction commits.
• On Ability Committed is the detailed companion event and includes the complete activation result plus an immutable lifecycle snapshot captured at commit.
• On Ability Channel Tick fires after each attempted atomic pulse and includes the pulse number and detailed result.
• On Ability Lifecycle Ended fires after state is removed, with Completed, Cancelled, Interrupted, Commit Failed, Ability Revoked, or Source Invalid.
• On Ability Activation Failed still reports failed checks and failed cast-completion commits.
• On Ability Operation Request Completed reports every queued Activate, Grant, Revoke, Cancel, or Interrupt terminal outcome; On Ability Request Completed remains the activation-only compatibility event.

Every subsystem event has a native C++ mirror with the same payload. The Blueprint event is emitted first and its native mirror immediately afterward.

Lifecycle state is removed before the ended event is broadcast. An event listener can therefore start another ability safely. Presentation remains optional: Actorless entities receive the same events, handles, state, and outcomes.

All costs, cooldowns, charges, attribute/tag outcomes, persistent state, and the lifecycle's committed phase are visible before successful transaction events are released. Callback-created replacement lifecycles are identity-protected: after any event or project-extensible operation, the outer lifecycle loop continues only if the same lifecycle ID is still active. A listener may therefore cancel the committing cast or current channel pulse and start another cast without the old execution frame completing the new one by mistake.

The activation boundary coordinates the source and one target. Each later channel pulse is its own transaction, and arbitrary target-selection arrays are not one implicit transaction. The transaction and event contract defines the complete scope, publication order, and multi-target partial-success rule.

Same-tick costs, effects, channel pulses, cancellation, completion, Damage, and death handling follow the deterministic gameplay ordering contract. In particular, every earned final channel pulse publishes before natural lifecycle completion.

Source destruction, target destruction before commit, recycled generations, representation reassignment, and world shutdown follow the entity lifecycle safety contract.

Durable save and restore

Entity State Snapshot format 4 can preserve one active cast or channel exactly. It stores the guarded Ability asset reference and stable ID, Save Compatibility Version, execution type and authored timings, current phase, remaining gameplay time, committed state, completed channel pulses, and earned pulse backlog. Restore allocates a fresh world-local lifecycle ID and does not emit synthetic lifecycle-started or lifecycle-ended events; re-query the active lifecycle and rebind presentation observers after the whole-entity restore boundary.

Keep Save Compatibility Version at 1 while saved active phases remain behavior-compatible. Increment it when an Ability change must invalidate old saved lifecycle state. Stable ID, version, execution type, cast time, channel duration, and channel period all have to match at restore, preventing an old phase from continuing under materially changed authoring.

• Targetless and self-targeted lifecycles use the ordinary Entity State capture/restore nodes; self targets rebind to the restored entity.
• For an external target, call Capture Mass Forge Entity State with Lifecycle Target Reference with a project-owned relationship key. After recreating both entities, call Restore Mass Forge Entity State with Lifecycle Target or its queued variant with that same key and the new target handle.
• Never store the former target handle or lifecycle ID in the project SaveGame. Missing, mismatched, unset, stale, or self-collapsed external bindings fail before mutation.
• Formats 1–3 remain readable but cannot describe an active lifecycle; they reject an active destination lifecycle instead of erasing it.

The complete transaction and migration boundary is defined in the durable entity-state persistence guide.

Channel failures and timing

Channel Failure Policy controls a failed pulse:

• Continue Channel reports the failed pulse and keeps scheduling.
• Cancel Channel ends with Cancelled.
• Interrupt Channel ends with Interrupted and is the default.

The shared deferred-command coordinator advances existing lifecycles before it starts newly queued ability requests. A queued cast therefore never consumes the frame delta that admitted it. Timing uses world delta time, so normal pause and time-dilation behavior follows the host world.

The precise gameplay-clock, Actor custom-dilation, seamless-travel, focused attribute snapshot, and durable entity-state SaveGame boundaries are defined in the time, travel, and save contract.

Large frame gaps preserve earned pulses. Max Ability Channel Ticks Per Frame under Project Settings > Mass Forge > Global Attribute Schemas > Runtime bounds catch-up work per active ability; remaining earned pulses carry into later frames instead of being discarded. Active entities are processed in stable entity-handle order.

Practical recipes

For a cast-time projectile or heal, use Cast, put the final effects in the normal self/target lists, and drive a progress bar from Remaining Time. Cancel from player input and interrupt from damage, stun, or project-owned crowd-control logic.

For a beam, drain, or channeled heal, use Channel, put the one-time setup in normal effects and repeated output in channel effects. Use On Ability Channel Tick for presentation; simulation authority remains in the atomic effect result.

For a wind-up followed by a channel, set both a positive cast time and the channel duration/period. The state transitions from Casting to Channeling only after the activation transaction succeeds.

The lifecycle is authoritative within its owning world. Multiplayer transport, prediction, reconciliation, and replicated baselines are outside the initial supported release and must be supplied and validated by the customer project.