Custom Requirement And Action

Goal

This recipe adds project logic to a command without hard-coding behavior into the target definition. Requirements decide whether the command can be used. Execution actions run after command outcomes.

Custom Requirement

1. Create a Blueprint subclass of UInteractionRuntimeRequirement.
2. Add editable fields for the condition, such as an item tag, permission tag, quest state, or minimum count.
3. Implement the Evaluate event using the supplied context. Return true to allow the content and false to block it.
4. Return pass/fail without mutating gameplay state.
5. Provide failure text when UI policy should tell the player why the command is unavailable.
6. Add the requirement entry to the point, variant, selection, or command list where the gate belongs.

Custom Execution Action

1. Create a Blueprint subclass of UInteractionCommandExecutionAction.
2. Add editable fields for the project state change.
3. Choose which outcome should trigger the action.
4. Implement the matching lifecycle event.
5. Keep shared state changes on the authority path.
6. Assign the action to the command row’s execution action list.

Test Matrix

• Requirement passes and command activates.
• Requirement fails and prompt displays the intended unavailable state.
• Execution action runs once on success.
• Execution action does not run on blocked activation unless configured for that outcome.
• Multiplayer activation runs the state change from authority-owned flow.

Combining Requirement And Action

A typical locked interaction uses both systems. A requirement checks whether the player has a key and supplies failure text. An execution action consumes the key or changes door state after successful activation. Keeping those responsibilities separate lets the prompt explain the block without accidentally consuming resources during prompt evaluation.

Authority And Blueprint Events

Requirement evaluation may happen for UI and validation. Execution action state changes should run where the runtime command outcome is authoritative. If the action calls project Blueprint events, make those events safe to run once for the intended command outcome.

Failure Diagnosis

• Prompt is hidden but should be disabled: review requirement UI failure policy.
• Failure text is generic: set project-specific failure text from the requirement.
• Action runs when requirement fails: action trigger is attached to the wrong outcome.
• Action works in single player but not multiplayer: shared state is being changed on the client path.

Reusable Blueprint Design

Make custom requirements and actions reusable by exposing designer-editable properties. A Key Required requirement should take a key id or tag. A Grant Reward action should take reward data. A Toggle Target action should take the intended target id or state. Reusable objects reduce duplicate Blueprint graphs across definitions.

Validation In Content Review

Review every command row that uses custom logic. Confirm the requirement is placed at the right scope, the action trigger matches the intended outcome, and failure text is readable. A content reviewer should be able to tell why the command is blocked and what will happen when it succeeds.

Example Locked Interaction Split

A locked door should use a requirement to check whether the player can unlock it. The requirement can return failure text such as a missing key message. The execution action should perform the unlock or open state change after successful activation. This split keeps prompt evaluation safe and makes command outcome behavior explicit.

Blueprint Data Shape

Expose designer fields rather than hard-coding values inside Blueprint graphs. Requirements might expose required tags, counts, or object references. Actions might expose a target id, cooldown amount, enabled state, or gameplay event tag. This keeps the same Blueprint class useful across definitions.

Review Before Reuse

• Does the requirement run without side effects?
• Does the action run only on the intended outcome?
• Does failure text help the player?
• Does authority-owned state change on the server path?
• Can another target definition use the same Blueprint with different property values?