Concept: Routing and Access

The manager is deliberately dumb about players: it does not know who asked, only whether the caller has authority. Everything about who lives in UCrimsonInventoryRoutingComponent on the PlayerController.

One RPC owner per player

A PlayerController is the only actor a client owns for certain, so it is the only place a Server_* RPC is guaranteed to arrive. Putting the RPCs on the manager would break for chests, which have no owning connection. The routing component therefore takes a target inventory as a parameter, validates the request (_Validate rejects null targets and nonsensical counts before the body runs), checks the access policy, and calls the manager.

The access policy

CanAccessInventory is the single gate. Default rules: the inventory's owner is in the player's chain (controller, PlayerState, pawn); or it is one of the player's personal containers; or there is an open container session for it and the pawn is within MaxContainerInteractionDistance of the container actor. CanOpenContainer gates session creation separately. Both are BlueprintNativeEvent, so a trade window or a guild bank is one override.

Sessions and scopes

OpenContainer resolves the container's inventory by Scope: Shared uses the actor's own component; PerPlayer uses the player's personal container on the routing component; PerParty and PerMapInstance look up or spawn an ACrimsonInstancedInventoryActor in UCrimsonInventoryInstanceSubsystem keyed by FCrimsonContainerInstanceKey (ContainerTag + the key your ResolvePartyKey / ResolveMapInstanceKey returns). The instanced actor is net-relevant only to its viewers, so a stash is never replicated to players who are not looking at it. CloseContainer removes the viewer and ends the session.

Feedback

State changes arrive by replication and are announced by StackChanged / InventoryUpdated. But a failed request changes no state, so nothing would replicate. FCrimsonInventoryOperationResult on Crimson.Inventory.Message.OperationResult closes that gap: the server always answers the requesting client, success or failure, through Client_NotifyOperationResult.