Runtime Components

Runtime Object Model

The runtime layer turns target-definition data into live interaction state. UInteractionRuntimeTargetComponent is the state owner for an interactable actor. UInteractionRuntimeInteractorComponent is the scanner and activation owner for the pawn or actor using interactions. UInteractionRuntimeWorldSubsystem is the world registry that target components register with and interactor components query against.

Keep this separation clear when debugging. If authored data is wrong, fix the UInteractionRuntimeTargetDefinition. If the actor is not discoverable, inspect the target component and point bindings. If the actor is discoverable but cannot be activated, inspect the interactor surface, requirements, cooldowns, busy state, and authority path.

Target Component Setup

1. Add UInteractionRuntimeTargetComponent to the actor that should expose interaction points.
2. Assign Definition to a target definition asset.
3. Assign stable save identity only when the target should persist state through snapshots.
4. Add PointBindings when authored point ids should resolve to actor components or sockets rather than a default actor transform.
5. Use RefreshRuntimeStateFromDefinition after changing the definition, point bindings, or authored layout at runtime.

Target State Owned By The Component

The target component owns shared runtime state: enabled state, point enabled bits, command enabled bits, cooldown end times, point variant overrides, resolved variants, command layout compatibility, busy state, multi-participant routes, and save ids. State-changing Blueprint functions on the target component are authority-oriented where the API marks them that way. Read-only functions are safe for UI or diagnostic code, but changing shared state should stay on the server-owned gameplay path.

Interactor Component Setup

1. Add UInteractionRuntimeInteractorComponent to the pawn or interaction actor.
2. Make sure the pawn or owning actor is available to the local player UI path when prompts should show automatically.
3. Assign input assets on target definition command rows, More markers, Back markers, and cancel controls. The interactor reads command surfaces; it does not invent missing input actions.
4. Use interactor read functions to inspect focus, visible handles, prompt surfaces, progress, route state, and paging state.

Runtime Update Flow

At runtime the target registers handles, the interactor queries candidates, focus scoring chooses a current handle, and prompt projection builds the surface that UI displays. Activation requests use the focused or selected surface entry and move through validation before execution actions run. If a prompt is visible but activation fails, the target and interactor have already found each other; the failure is usually requirements, cooldown, busy state, authority, route state, command id, or input phase.

Choosing The Correct Owner

• Use target component APIs for target-level state: enabled, cooldown, point or command availability, variant override, target save id, and command event delegates.
• Use interactor APIs for player-facing state: focus, visible handles, surfaces, paging, activation request, local variants, participation, and active progress.
• Use the world subsystem for registration lookup and save import/export workflows.
• Use the UI manager only for local prompt presentation and local-player widget ownership.

Runtime Mutation Matrix

Use the target component when the state belongs to the target and should be shared: target enabled, point enabled, command enabled, cooldown, busy state, variant override, target save id, and command outcome delegates. Use the interactor when the state belongs to the actor using the interaction: focus, visible handles, page index, local prompt presentation, activation request, participant intent, and owner-scoped state. Use the world subsystem for target registration queries and save import/export.

Lifecycle Timing

Definitions are read when target runtime state is built or refreshed. Registration happens through the target component/world subsystem relationship. Interactors query registered handles during runtime updates. UI state is downstream of interactor focus and projection. If a system reads too early, it may see no registered target, no focused handle, or an empty surface. If a system writes too late, UI may briefly show the previous state until replication or the next projection update arrives.

Runtime Change Checklist

• Changing authored data at runtime: refresh target runtime state.
• Changing shared target state: call authority-owned target APIs.
• Changing local prompt presentation: use interactor or UI state.
• Changing a command’s effects: edit execution actions, not widget code.
• Changing availability: edit requirements or enabled/cooldown state, not row rendering alone.