That tutorial has an odd way of doing things. Most tutorials are very specific to the authors game design. They aren’t in any sense standardized, nor flexible. Especially inventory system tutorials. At most you’d treat them as “Learning Tools”. Most would be very hard pressed to shoehorn someone else’s Inventory system into their game unless the game is very very similar.
Standard approach for world interaction is to have the client do a local interaction, if successful, Play an appropriate montage/animation, and call the server to interact. Server interacts, if successful, apply authoritative logic.
For example, Client does a trace. It hits and actor that’s a pick up item (Axe). It plays a montage to simulate picking the item up and RPC’s the server to interact. Server interacts, hits the axe and determines it can pick it up. Server calls a multicast for sims to play the pickup montage, then destroys the axe actor on the ground and spawns a “Useable Axe Actor”, sets an inventory variable referencing the Axe and Attaches it to the hand.
Client is faking the interaction because it does not have the authority to actually modify inventory. Inventory management is the servers job.
There are two variants of the Axe. A simple static mesh, low/no data version and a complex high data useable version. Both are set to replicate.
My setup…
World pickup items, the ones spawned or placed in the level, are simplistic actors. A mesh, an interactive collision, simple data to identify what it is (Gameplay Tag, Actor Tag etc), and an interface. These actors are all set to replicate. When the server does something to them the changes are replicated to all remote clients. Like Destroy, Spawn, etc.
The Gameplay Tag tells the code logic what the item is.
- WorldItem = An interactable actor that is to be picked up.
- Weapon = Type of Item (weapon, ammo, health etc). This is used to determine what logic to execute for picking it up and inventory handling.
- M416 = the specific weapon, this value is used for gathering data table/asset specs etc to configure the weapon.
My interaction system narrows down to the server calling a specific function/event based on the gameplay tag parent type (World Item, Vehicle, Door, Switch).
For looting it calls Srv Pickup Item
.
This function further narrows down to specific item type (weapon, ammo, health etc) and calls a very specific function.
Reasoning for this is my inventory is specific to the needs of the mechanics.
My characters can only ever have 2 primary weapons. Those are always rendered. Either in hand or attached to the players back. Secondary weapon is in hand or attached to holster. So 3 guns, 3 specific inventory slots.
Melee can either be in hand (current melee) or stored as data.
Grenade can either be in hand or attached to vest (current melee) or stored as data.
Both Melee and Grenades can also have multiples of each type stored as data.
e.g. Current grenade (in hand/vest) could be a Frag, but also have a frag, 3 stuns, a Molotov and a smoke in the backpack.
Gear (Backpack, Vest, Helmet) are always rendered and attached to the character. Either modular skeletal mesh or static mesh.
Everything else is Data.
Point here is your inventory needs to be designed around your game’s needs. When learning you apply tutorials to a secondary test project. Learn, then develop to fit your specific needs.
One of the issues I see in your inventory code is you’re creating components vs spawning actors. Axe should be a replicated Actor that’s spawned, reference stored in inventory (hand object), then attached.
Attach Actor to Component (Hand obj, character mesh, hand socket)