Hello everyone I am currently making a simple inventory system. It works on singleplayer as intended and I am trying to adapt it for multiplayer.
The inventory is an actor component. Everything works, picking up items, moving items inside same inventory, opening the chest UI and putting items inside chest. The porblems comes after this. A client cant move items FROM other inventory, it can put items in from their own inventory. On the listen server the player can both put items and get items FROM other inventory. I checked and inventory slot OnDrop function gets called on client but the Run On Server Move Item event doesnt get called on server. The interesting thing is when I make another event inside player character blueprint and wrap the move item function there with a run on server, and call it from the OnDrop UI function everything works.
But I feel like there should be a way of move item logic staying inside the inventory component and as a beginner I am trying to learn. I set the owner for the chest on the server when client is opening the UI. I have been working on this for 2 days nonstop can someone please help me? Guide me through or tell me where to look, I feel like I tried everything.
Interact with interface to call function on chest.
On chest, show inventory from inventory component to client.
Inside inventoryslot OnDrop function, call move items from payload inventory reference. (Server Move Item is the part where client code doesn’t execute, OnDrop is called without error)
Instead of calling the Server Move Item from referenced variable, if I add a wrapper inside player character blueprint everything works both on server and client.
it’s difficult to follow your implementation through screen caps so let’s just work with the theory.
In order for a server RPC to execute from a client, the actor must be owned by the client’s player controller. This is most efficiently done at the time of spawn using the “Owner” pin. It is highly unusual to flip-flop the owner during runtime. You’re going to run into problems with respect to replicated actors and having replication “channels” opened and closed, etc.
Now, in your example it seems like you have a chest that you want players to be able to store items in and you want that to propagate. For a shared resource like this there isn’t really an owner per say. It would simply be a replicated actor with a replicated inventory variable. The trick is that if a connected client wants to place something in the chest they need a way to do it on the server. One way to do this is from the client’s pawn. You would essentially have a reliable server RPC in the pawn which “places” the item in the chest.
Yes that makes sense, so putting the Server Move Item wrapper on the player pawn is a valid solution? Since I’m a beginner it felt wrong to put inventory logic on another pawn.
Yes, that’s absolutely an acceptable solution and a typical design pattern. I wouldn’t so much call it “inventory” logic…think of it more as “input action” logic. The pawn has an item in its inventory which it wishes to place in a chest. The placement of which is initiated with an input action, which should largely be handled in the pawn anyway. Good luck!
