Skip to content

Ability targeting policies

Mass Forge targeting policies are reusable Data Assets that validate a chosen source/target pair before an ability changes any state. They do not select targets. Projects remain free to choose targets through AI, player input, traces, Mass queries, or their own C++ systems, then pass the selected entity to the normal ability check or activation node.

Authoring workflow

  1. For a distance gate, create a Mass Forge Range Targeting Policy Data Asset.
  2. Give it a stable PolicyId, then set inclusive minimum and maximum ranges.
  3. Choose three-dimensional or XY-only distance and the desired position source.
  4. Add the policy to an Ability Data Asset's Targeting Policies list.
  5. Call Can Activate Mass Forge Ability to preview the complete result, or use the direct/queued activation nodes as usual.

A Mass Forge Range Targeting Policy asset configured for an inclusive 0 to 2500 cm two-dimensional range using Mass transforms with represented-Actor fallback

The policy stores only reusable admission rules. This actorless-safe setup measures XY distance from Mass transforms first and falls back to represented Actors; target discovery remains a separate bounded selection step.

For a project-specific rule, create a Blueprint subclass of Mass Forge Ability Targeting Policy and override Evaluate Target. The query provides the world context, stale-safe source and target entity handles, and optional represented Actors. Return Allowed to continue or a non-allowed result, stable policy ID, and optional reason for UI, logs, Behavior Trees, or StateTree decisions.

Policy assets are shared. They add no UObject to each Mass entity.

Composition and transaction contract

An ability may reference several policies. Mass Forge evaluates them in authored array order and stops at the first rejection. All assigned policies must allow the pair.

Targeting policies run after the source grant and basic target-handle checks, but before tag gates, cooldowns, charges, attribute requirements, costs, or effects. A rejection therefore consumes nothing and publishes no successful ability/effect event.

The activation result returns:

  • Targeting Policy Rejected as the ability result.
  • Failed Targeting Policy Index for the authored array entry.
  • The policy's stable ID and optional project reason.
  • A machine-readable policy result such as Below Minimum Range, Beyond Maximum Range, or Missing Target Position.
  • Evaluated Distance when the range policy reached its distance calculation.

An unassigned policy reference or a loaded policy without an ID makes the ability invalid. Editor validation reports unassigned references, missing policy IDs, non-finite ranges, negative ranges, and inverted minimum/maximum bounds.

Built-in range policy

The range policy resolves positions using one of these modes:

  • Mass Transform, Then Represented Actor — prefer the entity's standard FTransformFragment; fall back to its represented Actor.
  • Mass Transform Only — require standard Mass transform fragments on both entities.
  • Represented Actor Only — require both entities to have represented Actors.

The default mode works for actorless entities and stays stable across representation changes when Mass transforms are present. Actor-only mode is useful when the project's authoritative interaction position intentionally comes from Actor representation.

Both range bounds are inclusive. Set MinimumRange to zero when only a maximum matters. XY-only distance ignores vertical separation; three-dimensional distance includes it.

Blueprint safety

Custom policy overrides must be deterministic and side-effect free. Do not grant abilities, apply effects, change attributes, or activate another ability from Evaluate Target. Mass Forge rejects recursive policy evaluation with Targeting Policy Evaluation In Progress instead of allowing unbounded recursion.

Direct checks and activations still return Mass Is Processing while Mass owns the entity manager. A queued ability reevaluates every targeting policy when its ability phase executes, so movement or representation changes between submission and execution cannot bypass the current rules. See the deferred command contract.

Scope and current limits

Target validation and target selection are deliberately separate. Use the built-in radius, trace-segment, represented-Actor, collision-hit, or custom-provider adapters described in the target selection guide. Multiplayer is outside the initial supported release; a networked project must revalidate untrusted target requests on its own authority path.

For attribute and Gameplay Tag gates that are intrinsic to the ability, use the existing ability requirements rather than recreating them in a custom policy. See the abilities guide.

Mass Forge documentation — generated from the shipping Markdown source.