Multiplayer
Client prediction and server-authoritative validation.
Interaction Engine is designed for responsive multiplayer interactions: focus and prompt updates run locally, interaction attempts can be predicted locally for instant feedback, and authoritative results are validated and confirmed by the server. Blueprint logic should treat local prediction and server-confirmed interaction results as different stages of the same interaction request.
Network model at a glance
| Layer | Where it runs | Purpose |
|---|---|---|
| Focus and tracing | Local client / owning player | Keeps prompt display responsive without waiting for a server round trip. |
| Input prediction | Owning client | Starts immediate local feedback for tap, hold, mash, hit, and damage-style interactions. |
| Validation | Server | Checks target validity, range, line of sight, slot rules, cooldowns, damage requirements, and contested state. |
| Confirmed result | Server, then replicated/returned to clients | Commits gameplay state, fires confirmed Blueprint events, and keeps all machines synchronized. |
| Runtime slot state | Server-owned state replicated to clients | Replicates dynamic slot data such as progress, enabled/completed state, health, cooldown, and runtime changes. |
Predicted versus confirmed events
Multiplayer projects should avoid putting authoritative gameplay results in local prediction events. Prediction is useful for animations, sounds, temporary UI, and input feel. Confirmed events are the safe place to open doors, award items, consume resources, destroy actors, update save state, or trigger world-changing Blueprint logic.
| Event | Recommended use |
|---|---|
OnInteractionPredicted_LocalOnly |
Immediate local feedback on the owning client. Do not use this for authoritative gameplay state. |
OnInteractionStarted_Confirmed |
Server-confirmed start. Use this when other clients or authoritative systems must know the interaction started. |
OnInteractionCompleted_Confirmed |
Server-confirmed success. Use this for final gameplay results. |
OnInteractionCancelled_Confirmed |
Server-confirmed cancellation. Use this to stop authoritative looping effects or release contested state. |
OnInteractionRejected_LocalOnly |
Feedback for the requesting player when the server rejects the attempt. |
OnHitSent |
Local hit feedback, such as a swing impact attempt or temporary hit marker. |
OnHitConfirmed |
Authoritative hit result after server validation. |
OnButtonMashProgressUpdated |
Mash progress updates for UI and gameplay feedback. |
OnButtonMashFailed |
Failure feedback when the mash requirement is not met or expires. |
Server validation
Interaction requests are validated on the server before they become authoritative. This is the layer that prevents clients from completing interactions from invalid distance, through blocked line of sight, against disabled slots, during cooldowns, or with the wrong damage type. Rejected attempts should be handled through the local-only rejection path so the requesting player receives clear feedback.
Common rejection causes
- The target is no longer valid or no longer interactable.
- The requested slot is disabled, completed, blocked, or cooling down.
- The player is outside the accepted range.
- The server line-of-sight check fails.
- The interaction requires a specific damage type and the current request does not match it.
- Another player already owns or completed an exclusive interaction.
Runtime slot state replication
Static slot definitions describe what an interactable can do. Runtime slot state describes what is happening now. Runtime state is replicated through the plugin's slot runtime state system, including dynamic values such as enabled/completed state, health, cooldowns, progress, and other runtime slot changes. In Blueprint, prefer the provided slot/state functions instead of directly mutating the slot array during play.
Common scenarios and expected handling
| Scenario | Expected handling |
|---|---|
| Opened or toggled objects | Start cosmetic feedback locally if desired, but commit the final open/toggle state from the server-confirmed event. |
| Harvested or consumed objects | Validate on the server, then disable, hide, destroy, or mark the target as completed from the confirmed path. |
| Hold interactions | Use local progress for responsiveness, but treat completion as authoritative only after server confirmation. |
| Button mash interactions | Display progress locally, respect server-side mash interval validation, and handle failure through the mash failure/rejection path. |
| Damage or multi-hit interactions | Use local hit feedback for feel and OnHitConfirmed for authoritative damage, health changes, and completion. |
| Contested interactions | Resolve on the server. The first valid request to pass authority-side validation should own or complete the interaction. |
| Foliage proxy interactions | Let the server validate the virtual foliage target and spawn/confirm the proxy. Use confirmed foliage/proxy events for final results. |
| Save/load restore | Run restore from authority. Clients should receive the restored state through replication rather than applying restore locally. |
Blueprint implementation checklist
Useful debug commands
These commands are useful when validating multiplayer behavior, rejected interactions, and foliage handoff issues.
ie.Debug.Net 1
ie.Debug.Transaction 1
ie.Debug.Validation 1
ie.Debug.Foliage.EventTrace 1
ie.Debug.FoliageProxy 1