Hi, I have searched around for this question and it doesn’t seem to have a clear answer to it, so sorry I have annoy you guys with this. Basically what I’m trying to do is that I have to a pickup system and inventory, like pubg where you can press a button to show the widget and it will scan items around you. I do a sphere trace(the sphere trace runs on a timer whenever the character move or an item is not there anymore) and then I add it to a list and then the widget grabs a hold of that list to display information. That’s just describing what I’m doing, the problem is that I want to have an unique ID for every item that exist in the game at any spesific time, cause the user can drop items too, and I need a way to make that ID the same for server and clients and also make sure 2 items cannot have the same ID at any given time.
What I’m thinking of is to maybe have a list in the game mode that holds track of all the ID’s, and then generates something that isn’t in that list already, but is that a good way to do it or is it a better way.
PS: The reason I want to do this is just that with the current setup, I have to cast everytime to store the reference and if the character moves alot when the inventory widget is up, there will be alot of sphere traces and looping with alot of casting. I don’t actually know if the ID route is any better, but in my mind, I’m thinking creating an interface only for retrieving that ID and maybe also information about the item(stored in a struct) and then create a map instead to easier and maybe more efficiently finding that reference and either do anything with it or delete it.
Create an Enumerator for Item Types. Weapon, Attachment, Gear[bp,vest,helmet], Consumables, Ammo, Throwables etc.
Create a Parent class for loot items. Add an Enum for Item Type and a Name var for the specific item ID.
Create a Data Table for each Item Type, use the “Name” var as the “Row Name”. Having type dependent data tables will reduce seek times. You can then use Switch (Item Type] → Get Data Table Row[name] to retrieve item data locally. If you’re heading down the PubG path, then you’ll want this type of separation. They have roughly 127 different loot items and counting.
Also, anything spawned in the world is a simple static mesh class. I don’t drop or spawn full data SK weapons on the ground. For weapons (guns) I have a sm variant class that holds a class reference var for the sk variant and vice versa.
My Items are broken down into the Type structure (enum item type). I derive a child class from the parent for each. So Parent → Weapon, Parent-> attachment etc.
Loot item parent class is abstract. All derived child parents are abstract.
thank man, didn’t except this honestly, but I have one question, where would you put information about amount at least, as one item can have a different amount then another.
The engine does exactly that (for replicated Actors). It’s called the FNetworkGUID | Unreal Engine Documentation
I don’t think I fully understood why you want to do this but if you really wanted to you should be able to get the info you need. Have a look at UNetDriver and FNetGUIDCache.
What I got from the post was he wants a way to identify items in the world for data look up.
e.g I overlapped this item, what it’s name, type, icon etc.
Oh, that’s why I didn’t understand, I meant identifying that exact item, one of the reason is that if I destroy the item for example, the reference that is still in the list of ground items on the other clients still exist and I have to cast the item everytime to get the data for the actor, the item is an actor with just item data(struct) and a mesh comp. Like in pubg when you press tab the a widget appears and you get a list of the items on the ground with the information it holds, and I just wondering because that list of ground items has to be looped and casted whenever something changes
Hi, thanks, I don’t know if I actually need it honestly, but from my perspective and the way I chosed to do things, this just sounds like the best solution, but something tells me that it’s probably because the system I have built up is bad.
Your local client isn’t supposed to destroy anything. It only executes the animations of picking up/dropping.
You pickup an item (press E/drag ui)… locally you execute the proper animation and send an RPC to the server to pickup. It attempts to pickup (overlap actors, interface check etc). If successful it adds it to your inventory, destroys to the world item (replicated actor), then updates you via RPC.
Because the item is a world item - owned by the server and is replicated actor - the server will replicate that change (destroy) automatically.
Server spawns it, server owns it. If the actor is set to replicate, server will replicate via its replication interleave. See Actor Relevance and Priority.
Everything that has anything to with inventory (adding/dropping, reloading, attachments, usage) is executed on the server.
When the server drops an item from a players inventory it’s removing it from the inventory struct. Then it spawns an sm variant at the players feet…where the player is on the server. That variant is auto replicated. It’ll multicast nearby players to emulate the animation (drop item event).
I play a lot of PubG and I’ve prototyped a lot of their functionality. DM me if you have game specific functionality questions.
Use the data table setup I posted for world item info (name, icon etc). This will reduce your sm actors “weight”, which reduces client and server memory usage.
For the heavy data items like skeletal mesh guns (attached/equipped to characters) you can either go with a lot of data table and row lookups (recoil, sway, rof, projectile class, muzzle velocity, sm variant, icon zeroing etc) or preferably and highly recommended stored in wepSK class structs.
The SK classes contain all the weapons logic. Firing (single, burst, auto), Reloading etc. Not the character. When you fire/reload you call an event on the currently equipped weapon. It executes the local logic. do i have ammo, which montage to use (shotgun vs AR vs SR etc).
I’d also create a weapon attachment inventory in the weapon class itself. Slot based, where each slot has a config of what can be attached.
muzzle: can attach (A, B, C, D) … on attach: Get attachment name → find (tmap, can attach) → true RPC server to attach.
Obviously there’s a lot to it. Plot out everything, then prototype BP, then translate to C++.
