Blueprint async actions

Mass Forge's async Blueprint nodes combine bounded queue submission, request-ID correlation, and delegate cleanup into one latent-style node. Use them for ordinary gameplay events that may overlap Mass processing. The detailed direct and queue APIs remain available for advanced orchestration and high-volume C++ code.

Choose the right call style

Situation	Recommended API
A setup or editor-owned path that is guaranteed to run while Mass is idle	Direct node
An input event, timer, animation event, callback, or other ordinary Blueprint gameplay path	Async node
Several systems share one central completion listener	Queue node plus subsystem delegate
Thousands of homogeneous operations are produced in a Mass processor	C++ processor/deferred-command integration

Async nodes do not turn a rejected request into a success. They expose two explicit paths:

• Completed means the accepted request reached its terminal execution result. Inspect the returned result structure because execution can still reject a stale entity, invalid definition, or changed lifecycle.
• Rejected means no positive request ID was allocated. Typical reasons are an invalid world, invalid input, stale entity, or a full bounded queue. No later completion will arrive.

Calling Cancel stops this Blueprint object from listening. It does not retract gameplay work that was already accepted by a subsystem.

Attribute change

Use Change Mass Forge Attribute (Async) for a safe Set, Add, or Multiply operation. Select the schema-backed Attribute ID, supply the complete entity handle, and branch from:

• Completed: inspect Result, Old Value, New Value, and Was Clamped.
• Rejected: handle the submission result immediately.

For damage or healing that needs reusable authored rules, several atomic modifiers, source context, tags, or events, use a Damage Definition or Instant Effect instead of a raw attribute change.

Instant effect

Use Apply Mass Forge Instant Effect (Async) for reusable healing, resource restoration, and atomic attribute/tag transactions. The node retains the definition until submission and waits only for its own request ID. Completed returns the full Instant Effect application, including every modifier result.

Damage

Use Apply Mass Forge Damage (Async) with a Damage Definition and a complete Damage Request. Damage still resolves through the authored shield, mitigation, critical, tag, and death policy. Completed returns the same complete damage application used by C++; it is not a simplified boolean.

Ability ownership and activation

Use the operation-specific nodes:

• Grant Mass Forge Ability (Async)
• Revoke Mass Forge Ability (Async)
• Activate Mass Forge Ability (Async)

All three return a common Mass Forge Ability Request Completion. Inspect Operation, Result, Ability Id, entity handles, and the detailed activation payload where applicable. A successful activation request can start an authored cast or channel; observe its presentation phases with Observe Mass Forge Ability Lifecycle.

Persistent effects and tags

Use Apply Mass Forge Persistent Effect (Async) and Remove Mass Forge Persistent Effect (Async) for finite or infinite buffs, debuffs, damage over time, healing over time, and slows. The apply completion contains the exact stable handle required for a later removal.

Use Add Mass Forge Gameplay Tag (Async) and Remove Mass Forge Gameplay Tag (Async) for counted tag changes outside a larger atomic gameplay transaction. The completion reports previous and new counts and never permits underflow.

Projectile travel and impact

Use Launch Mass Forge Projectile (Async) when gameplay must wait for actual travel and resolution:

1. Build a Mass Forge Projectile Launch Request with the projectile Entity Config, start, target, speed, radius, lifetime, source/target entities, presentation channel, cue, and optional Damage Definition/request.
2. Use Launched to create or register presentation for the returned projectile ID and entity handle.
3. Read projectile snapshots each presentation update, or bridge them into project-owned Niagara, HISM, or Actor rendering.
4. Use Resolved for impact/expiry presentation. Damage, when configured, has already been resolved by the projectile impact phase and is included in the result.
5. Use Rejected when no projectile was created.

Do not apply the same damage at ability commit and again at projectile impact. A projectile skillshot's ability commit launches the projectile; the projectile owns impact-time damage.

Lifetime and safety contract

• Every action registers with the current Game Instance and releases all subsystem bindings when it completes, is cancelled, or is destroyed.
• Completions are matched by positive request or projectile ID, so unrelated world traffic cannot advance the graph.
• Inputs are copied or held strongly until queue submission. Subsystems retain their documented soft/weak definitions afterward.
• Entity handles remain generation-checked at execution time.
• Queue capacity and per-frame work limits are unchanged; async nodes are convenience wrappers, not an unbounded scheduling path.

For centralized request routing, back-pressure recovery, or C++ integration, continue with Deferred Commands. For visible skillshots, continue with Mass Projectiles.