Ability condition extensions

Mass Forge ability conditions are reusable Blueprint/C++ Data Assets for project rules that do not belong in the framework's fixed attribute, tag, target, cooldown, charge, or cost gates. Examples include match phase, quest state, equipment ownership, line-of-command approval, or a project-specific faction relationship.

Create a Blueprint derived from Mass Forge Ability Condition, assign a stable Condition Id, and implement Evaluate Condition. Add condition assets to an Ability's Activation Conditions array in the order they should run.

Query and response

The immutable query contains:

• the current world context;
• source and optional target entity handles;
• optional represented source and target Actors;
• the stable Ability ID.

Return a response with Passed only when the rule allows activation. Any other condition result rejects the ability as Condition Rejected. Set a stable Reason for UI, AI, logs, and support diagnostics. Mass Forge fills an omitted response Condition Id from the asset, then reports the response and zero-based Failed Condition Index in the ordinary activation result. Event History records the top-level ConditionRejected outcome while the full activation result carries the detailed condition response.

The native base implementation returns Invalid Configuration with reason NoConditionImplementation. This fail-closed behavior makes an accidentally unimplemented condition visible instead of silently allowing gameplay. It can also be used intentionally as a data-authored kill switch.

Evaluation contract

Mass Forge evaluates built-in target, tag, cooldown, charge, attribute-requirement, and affordability gates first. It then evaluates custom conditions in authored order. The first failure stops evaluation. A successful activation re-evaluates every condition during the final commit check, including after a cast delay, so a changed project state cannot reuse an earlier approval.

Condition implementations must be:

• deterministic for the supplied query and current authoritative world state;
• side-effect free—do not spend resources, add tags, activate abilities, dispatch effects, or alter external state;
• safe to execute more than once;
• bounded and fast enough for the expected activation rate;
• explicit about unset targets and actorless entities.

Re-entering ability admission from condition evaluation is rejected as Condition Evaluation In Progress. This guard prevents recursive evaluation; it does not make side effects safe. Use the queued Mass Forge APIs after the current activation completes when a later gameplay action is required.

Blueprint workflow

1. Create a Blueprint class based on Mass Forge Ability Condition.
2. Implement Evaluate Condition and branch only on read-only project state.
3. Return Passed, or a specific failure result plus a stable reason such as Match.NotStarted.
4. Create a Data Asset from that class and give it a stable Condition Id such as Condition.MatchActive.
5. Add the asset to the Ability's Activation Conditions list.
6. In failure UI or AI, inspect Result, Failed Condition Index, Condition Response.Condition Id, and Condition Response.Reason.
7. Use the gameplay-asset Details panel to browse the outgoing condition dependency and run Validate Assets before packaging.

If a condition requires a target, also enable the Ability's existing Requires Target setting. Conditions may inspect a supplied target, but they do not implicitly change the Ability's target requirement or target-selection contract.

C++ workflow

Derive from UMF_AbilityCondition and override EvaluateCondition_Implementation. Keep the class shared as a definition asset; do not attach one UObject per Mass entity. Query entity state through the public generation-checked subsystem APIs and return stable diagnostics rather than logging as the only failure channel.

Current extension boundary

Reusable targeting-policy assets, custom target-provider objects, inspection providers, damage-policy providers, and ability activation conditions are implemented. Custom magnitude-calculation and transaction-safe execution-plan extensions remain roadmap work; do not mutate gameplay from a condition to emulate either feature.