Creating custom functions

Once you’re comfortable enough in the system to make your own functions and/or change the current functions, here are some things to keep in mind.

You should always assume an item does not have a widget version of itself. If you need access to the widget of an item, you can use GetWidgetForItem. Remember to check if the widget is valid. Widgets also can’t be transported through a network, so if multiplayer is important to you, your server functions can’t rely on data from widgets.

---

Best practices

• Do not rely on widgets being valid. Your code should as often as possible rely on data from the inventory component, rather than relying on using the widgets as a proxy.

• In most contexts, you should assume the data asset is loaded and just fetch the ItemAsset variable and assume it has been set. If it isn't, you are then trying to work with an inventory component that hasn't loaded all the items inside of it.

---

Finding Items

Finding an item is a very common scenario when you start making your own functions.

The container's TileMap combined with an item's UniqueID is the most reliable way of finding items.

The component includes a function to get an item at item at a specific index of a container called GetItemAtSpecificIndex.

• The UniqueID is the most reliable method of finding a very specific item, container or item component, other than a direct reference to the item, container or item component, but even then a direct reference might get outdated if the player moves the item or modifies it in some way. The UniqueID is only updated for containers and items if they are moved to a new component. You can update a outdated item struct by calling UpdateItemStruct

---

Network optimizations

It is recommended, where ever possible, to use the item or container UniqueID instead of the struct in your RPC calls, and then have your server use the UniqueID to figure out which struct to use.

Here you can see 2 sets of RPC calls. One is ReduceItemCount (indicated in red), which is passing the item struct to the server and then to the client. The other is IncreaseItemCount (indicated in blue), which is passing the UniqueID to the server and the server is then using that UniqueID to resolve what item we are trying to modify.

Switching to using the UniqueID method reduced the RPC size from around 75 bytes down to 13. |||

The only downside is that it is not possible to verify if the client has illegally modified it's data, and it's very difficult to verify that the data inside the item/container are synced. It is up to you whether that is a big enough problem to do this. Some anti-cheat methods already do a very good job at preventing clients from modifying the games data with external tools. If you need to validate the data, you can have the server function still accept the full item/container struct, validate the data, then only pass the UniqueID to the client.

We covered that UniqueID's scale extremely well on another page, but to give you an idea of how well it scales, here's an example

These are two functions using an array with 5 entries of FS_UniqueID's (Blue) and an array with 5 entries of FS_InventoryItem (Red)