Networking And Authority

Authority Model

Interaction Framework separates local presentation from shared gameplay state. Clients can gather focus, show prompts, and forward player intent. Shared target state is owned by the authority path. Functions marked BlueprintAuthorityOnly should be called from server-owned gameplay flow when they change enabled state, cooldowns, variants, save ids, busy state, or participation state.

Activation Request Flow

1. The local interactor resolves a focused surface and the input phase for the selected command.
2. The interactor sends a server request for a surface index or control entry.
3. The server validates target identity, point id, command id, layout compatibility, snapshot tolerances, route state, enabled state, cooldowns, requirements, and busy state.
4. If validation succeeds, execution actions run according to their trigger policy.
5. Replicated target state updates client prompt and focus behavior.

Replicated Target State

UInteractionRuntimeTargetComponent replicates target identity, target enabled state, point and command enabled bits, cooldown end times, point variant overrides, resolved variants, command layout hash, allowed instigator actors, busy state, busy point and command sets, and multi-participant routes. UI and client-side read paths should treat these values as replicated state, not as local-only decisions.

Interactor Replication

UInteractionRuntimeInteractorComponent owns local focus and prompt presentation, but it also carries synchronized outcome/progress/participation state where the component exposes replicated behavior. Owner-facing deny or cooldown state should be handled through the interactor path when it belongs to the actor using the interaction rather than the target itself.

What Belongs On The Server

• Changing target enabled state, point enabled state, command enabled state, cooldowns, and variant overrides.
• Executing command actions that mutate gameplay state.
• Accepting or rejecting multi-participant route progress.
• Importing or exporting authoritative world save snapshots.

What Can Stay Presentation-Side

• Showing prompt widgets and projected screen positions.
• Reacting to focus and surface changes for local UI.
• Paging a visible command surface through interactor controls.
• Displaying requirement failure text, cooldown timers, progress, and participant stage text.

Common Network Failures

If a client-side Blueprint node does not change state, check whether the function is authority-only. If activation fails only in multiplayer, compare local focus data with server validation inputs: target id, point id, command id, route id, layout hash, and activation snapshot tolerance. If prompts show stale state, verify the target component is replicated and that runtime state is changed through the target component rather than a widget-only path.

Server Rejection Diagnosis

A server rejection means the local prompt state was not enough to complete the command. Compare what the client selected with what the server validates: target id, point id, command id, current route, activation phase, layout compatibility, enabled bits, cooldown, busy state, requirement results, and snapshot tolerance.

Replication Contract

Replicated state should be read by prompt UI and local feedback, but written through the runtime authority path. A widget that hides a row locally has not disabled the command. A client Blueprint that changes a local variable has not changed target state. Use target/interactor APIs that own the relevant replicated state.

Multiplayer Test Plan

1. Run with two clients and one server.
2. Confirm both clients see the same target enabled/cooldown/variant state after activation.
3. Confirm only the interacting client sees owner-specific prompt or deny state when that state is owner-scoped.
4. Confirm rejected activation does not run execution actions.
5. Confirm route state updates for every participant that should see it.