Networking and prediction

Replicated owner setup

The inventory-owning actor must replicate. URicContainerManagerComponent enables replication and uses the registered subobject list.

On the server, every attached container and item is registered separately with COND_None, including nested contents. Existing property replication conditions still apply; this is not owner-only inventory privacy. Actor relevancy determines which connections can receive the actor and its subobjects.

Iris replication fragments are registered when Iris support is compiled in. Registration is maintained at mutation boundaries rather than by traversing the inventory each frame.

Client component setup

For a player inventory, put these components on the same appropriate owning actor:

• URicContainerManagerComponent
• URicItemOperationsRPCsComponent
• URicClientPredictedInventoryComponent

Server RPCs require the actor's owning connection. Choose ownership and relevancy as part of your game's multiplayer setup.

Present the client view

Read GetContainerCopies() or GetAllContainerCopies() for the player-facing inventory. Resolve items with FindItemCopyByID, and call predicted operations with the references belonging to that view.

Bind to OnSync, OnSyncContainer, or SubscribeToContainer to rebuild affected widgets. Unsubscribe when the UI closes. Notifications may be debounced; the declared default broadcast interval is 0.05 seconds.

For authority or standalone paths, some accessors can return the source inventory instead of allocating predicted copies.

Observe another inventory

Call SetObservedContainerManager when opening a chest or another inventory. Read GetObservedContainersCopy(), then clear the observed manager when the view closes.

Observation is a presentation scope. It does not itself grant gameplay permission to transfer from that manager; the relevant actor state must also reach the client.

Reconciliation and identity

Use GUIDs to reconnect selection, drag state, and visual resolvers after Sync() or a container synchronization. Predicted copies are excluded from authoritative subobject registration.

A transfer between different networked managers uses the existing clone-and-remove path. Do not assume the same item UObject survives every transfer.

Custom container mutations

Wrap custom C++ code that directly modifies slot storage or ownership in FRicScopedReplicationUpdate before making changes:

#include "System/RicScopedReplicationUpdate.h"

{
    FRicScopedReplicationUpdate SourceUpdate(SourceRoot);
    FRicScopedReplicationUpdate TargetUpdate(TargetRoot);
    // Perform the complete mutation or rollback while both scopes are alive.
}

SourceRoot and TargetRoot are the affected inventory objects. Nested scopes join the same batch. Pass true as the second argument when removed objects should also be destroyed on remote peers. Keep an outer scope alive through the entire composite operation.

Validate multiplayer integration

Use a server and at least two connected clients to check moves, nested containers, transfers, restoration, and removal. The repository's registration and GC automation tests do not replace a real network-session test.

The built-in RPCs perform inventory operations but do not provide a complete game-specific permission or quantity-validation layer. Add your game's ownership, access, and economy rules before exposing privileged inventory changes to clients.