Execution Actions

Role In Command Execution

UInteractionCommandExecutionAction is the extension point for behavior that happens after a command reaches a lifecycle outcome. Requirements decide whether a command is allowed. Execution actions change state or notify gameplay once the command starts, completes, fails, cancels, or reaches the configured trigger condition.

Built-In Actions

• UInteractionCommandApplyCooldownAction applies cooldown state. Use it when a command, point, or target should be temporarily unavailable after an outcome.
• UInteractionCommandDisableInteractionAction disables a target, point, or command depending on its configured scope. Use it for one-time interactions, consumed pickups, opened one-way switches, or commands that should disappear.
• UInteractionCommandSetTargetEnabledAction changes target enabled state. Use it when an interaction command should enable or disable an entire target.

Outcome Trigger Design

Choose the trigger before writing the action. A hold command may need visual progress while held but only commit state on completion. A cancelable route may need cleanup on cancellation. A failed command may need feedback without changing state. Keep irreversible gameplay changes on the success or completion path unless the command specifically requires failure or cancel side effects.

Participant Scope

Participant-aware actions should be explicit about who receives the effect. Multi-participant commands can involve an initiator, contributors, required participant counts, and shared thresholds. When authoring an action, decide whether it affects the target, the initiator, every participant, or project state outside the interaction framework.

Blueprint Subclass Workflow

1. Create an execution action Blueprint from the provided factory or subclass UInteractionCommandExecutionAction.
2. Add designer-editable fields for target ids, gameplay tags, values, or external state references.
3. Implement only the lifecycle events needed for the command.
4. Keep network-sensitive state changes in the authority-owned execution flow.
5. Assign the action instance to the command row’s execution action array.
6. Test success, failure, cancel, cooldown, and repeated activation paths.

State Safety

Execution actions should be idempotent where possible because activation may be retried or rejected before completion. Use target ids, command ids, and route context from the execution context instead of hard-coded actor references when the action should be reusable across target definitions.

Choosing Requirement Versus Action

Use a requirement when the question is “can the command be offered or activated?” Use an execution action when the statement is “the command outcome should change something.” Inventory checks, key ownership checks, or player count checks are requirements. Removing the key, opening the door, applying a cooldown, or disabling the command are execution actions.

Action Reuse Guidelines

A reusable action should avoid assuming one specific actor class unless that is the point of the action. Prefer configuration fields, target ids, command ids, gameplay tags, or context data. A reusable action can then be instanced across target definitions and edited by designers without code changes.

Ordering Multiple Actions

When a command has multiple actions, order matters if one action changes state another action reads. Prefer independent actions, or make the dependency obvious in the authoring order. For example, run project gameplay notification before disabling a command if the notification needs command context that may change after the disable.

Failure Diagnosis

• Action never runs: outcome trigger does not match the command result or the command never activates.
• Action runs too early: trigger is attached to start/progress instead of completion.
• Action runs more than once: repeated input phases or multiple participants are reaching the same trigger.
• Action changes state only locally: authority path is wrong.

Guarded UI Flow Actions

Interaction Action Begin Flow Guard starts a per-interactor presentation guard from command execution. Place it before actions that make the current prompt surface empty, switch the projected variant away, or disable the last visible command. The guard broadcasts a start event to the local interactor so widgets can close or transition deliberately before they clear the guard.