How does the system work?
Design structure
With how strict the performance requirements were for this plugin, I’ve had to design this inventory system slightly differently from other systems you might find either on the marketplace or Youtube tutorials. The biggest thing to keep in mind is that this system does NOT rely on widgets being valid or created to keep track of its data or run gameplay logic.
This is to achieve five things:
This greatly speeds up widget construction since all the data they need (for example where an item is inside the container and so forth) is already prepped.
Allows you to remove widgets from memory and still have the necessary data to find out important things like looting an item and finding a free space for that item.
Since widgets have way fewer references, there is less work to be done to manage widgets getting garbage collected properly.
Designers are able to create new widgets and prototype much faster since all the data they need about containers and items is always available from the component.
You have complete control over when you want to construct these widgets, meaning you can reduce lag spikes when starting your game or even speed up the time it takes for your players to load a level or area.
ContainerSettings is an array inside of AC_Inventory.h and this is your inventory. Each container hosts a set of items and dictates its dimensions, compatibility settings and so forth. Some settings are hidden as they are not relevant to designers.
When creating a widget for a container, the widget uses a UniqueID to find out what container it is representing. This is typically referred to as "Binding" a container with a widget.
Items differentiate themselves from each other by using a UniqueID as items can have the same name, same data asset and so forth, they can even share the same position inside a container while in-editor. A component can not give items or containers the same UniqueID twice. This is essential for functions to work properly.
The component is designed to live on individual actors, not the player controller. Though there is no reason why it can't live on the controller, but I won't be actively testing it that way.
It is highly recommended to head over to the AC_Inventory page and giving a read. Understanding the main component that makes this system work is crucial to understanding the in's and out's of the system.
How are the infinite items inside of items achieved?
Since UE does not support recursive structs and recursive structs are difficult to manage, containers use a coordinates system explaining what item they belong to. The array is simply containers and those containers have an array of items. The only thing the compoonent needs to know whether a container is owned by the component or owned by an item is by checking FS_ContainerSettings.BelongsToItem.
I recommend reading the code comment for the FS_ContainerSettings.BelongsToItem property and then looking at AC_Inventory.h -> GetItemsContainers for an example.
Last updated