Skip to main content

Multiplayer Setup

Inventory entries and carry weight replicate through UInventoryComponent. The Game Instance subsystem, manager,
widgets and drag payloads are local objects. The plugin contains no Server RPC declarations for automatically
forwarding its subsystem mutation calls.

Project RPC Route​

Local input/drop delegate
    → owned PlayerController or Pawn Server RPC (project)
    → server resolves current Pawn/component/slot
    → validates permission and requested quantity
    → InventorySubSystem operation
    → replicated component state → client UI

Use the owning client's network actor for the RPC. On the server, derive the requesting player from that actor rather
than trusting a client-supplied arbitrary player reference. Validate current slot identity, quantity, target inventory,
distance/access rights for external interactions and any trade/equipment rules.

Replicated Owner and Visibility​

Place the component on a replicated Pawn or PlayerState. The component enables replication by default,
and GetLifetimeReplicatedProps registers InventoryData and ActualInventoryCarryWeight with DOREPLIFETIME.
No owner-only condition is declared for these properties; visibility follows owner actor replication/relevancy.
If inventory privacy is required, provide and test an appropriate project/plugin replication policy.

Standard manager add/remove/transfer helpers check authority, but low-level component interface methods and the
native split/merge paths do not consistently enforce it. Restrict all mutation entry points to
authoritative integration code.

Singleplayer, listen server and dedicated server can use the same component data model.
They still need testing: slot receive callbacks do not produce an automatic local server UI refresh,
and UI prediction needs rejection handling. See Replication Flow.