Problematic Areas of the Asset and How to Fix Them

Another, less serious weakness of the asset is the Use Item function in the Inventory Component.

First of all, once again, checking items by name is not very convenient. The name can change, and even the ItemID can potentially change, which means you always have to keep this in mind, go back into the function, and update the corresponding name or ID.

Second, once the number of items becomes large, this function and its graph will grow too much and become difficult to maintain. The inventory will end up containing too much information about things it theoretically should not even need to know about. This creates unnecessary references, increases memory usage, and makes individual items harder to isolate. It also increases the risk of breaking existing items and dependencies because of the growing number of branches.

Overall, this approach does not scale well.

The solution is very simple: give each item its own UseBehaviorClass.

You need to create two Blueprints:

• One Blueprint of type Object, called UseBehaviorClass.

• One Blueprint Interface, for example BPI_UseBehavior, and add this interface to UseBehaviorClass.

Next, add a new variable to S_Item with the type of your base UseBehaviorClass.

You should also create a new structure called S_UseContext. Add the following variables to it:

• Item Info

• Slot — Integer

• InventoryComp

• PlayerController

In the behavior interface, create a function/event called UseItem_BPI and add an input variable of type Object.

Then open the base UseBehaviorClass object and implement the UseItem_BPI interface event. Save and close it.

This object will be the parent class for all item use behaviors. Right-click it and select Create Child Blueprint Class. This will be your first item behavior. Inside that child Blueprint, implement the same UseItem event and attach whatever item-specific logic you need to it.

After that, all that remains is to implement the code shown in the attached screenshot.

If you are completely new to Unreal Engine, I would not recommend making these changes directly in your main project. It is better to create a backup first and spend some time testing the system separately.

That said, I recommend making regular backups in general, regardless of your experience level.

Keep in mind that modifying structures can affect code that has already been created. Sometimes Unreal Engine may report errors in specific places, or some logic that uses the modified structure may stop working even though it previously worked correctly.

In most cases, this means you simply need to recreate the affected nodes in the locations where errors appear, then use Refresh All Nodes and compile the Blueprint again.

So after changing a widely used structure, it is a good idea to check all dependent Blueprints carefully and make sure they still compile and behave correctly.

WIP

After changing the item structure to use a proper ItemID, another issue may appear in the weapon system.

The weapon can stop equipping correctly and fall back to Unarmed, even though the correct item is being selected.

The reason is the initialization order.

Currently, the weapon reads Item Info inside BeginPlay and uses it to load Weapon Info from the DataTable:

BeginPlay
→ Item Info
→ Break S Item
→ Datatable Name
→ Get Data Table Row
→ Set Weapon Info

However, Item Info is assigned to the weapon only after the weapon actor has already been spawned:

Spawn Actor
→ Cast to BP_WeaponMaster
→ Set Item Info
→ Set Active Weapon

The problem is that BeginPlay has already executed before Set Item Info is reached.

So the actual order is effectively:

Spawn Actor
→ Weapon BeginPlay
→ Item Info is still empty/default
→ Datatable Name is empty
→ DataTable lookup fails
→ Weapon Info stays at default values
→ Weapon Type becomes Unarmed

then:

→ Set Item Info

At that point it is already too late, because BeginPlay will not run again.

This issue may remain hidden for a long time if the weapon Blueprint already has some valid default values. After changing the S Item structure, Unreal may reset or reconstruct those defaults, which exposes the initialization problem.

The proper solution is to remove the Item Info-dependent initialization from BeginPlay and move it into a dedicated function, for example:

InitializeWeapon(NewItemInfo)

Inside that function:

Set Item Info = NewItemInfo
→ Break S Item
→ Datatable Name
→ Get Data Table Row
→ Set Weapon Info

Then the equip logic should be:

Spawn Actor
→ Cast to BP_WeaponMaster
→ InitializeWeapon(Item Info)
→ Set Active Weapon

This guarantees that the weapon data is initialized only after the correct item information is available.

I would recommend fixing this in the base asset as well, because relying on BeginPlay to read data that is assigned only after spawning is fragile and can easily break after structure changes or default-value resets. 

Actually its very easy fix, look at screenchots, and dont forget unlink from begin play.

And add this init here

Another potential issue is the naming and the way the framework checks whether an ID contains the word "Empty". The framework often relies on checks like this.

The problem is that if users add items such as EmptyBottle, or any other item with "Empty" in its ID, it could break the logic as well.

The checking approach should either be changed entirely, or at the very least, it should not look for IDs that contain "Empty". Instead, it should compare the ID directly, for example: if ID == EmptySlot, then return true. 

Look at screenshot

@g-honorgames Thanks this is very useful,localizable is very important for a game developer.

@g-honorgames Thank you for taking the time to share these useful points and solutions! I hope this will be helpful to everyone using the framework. We’ll take a look at these points and, where appropriate, consider addressing the more important ones in future updates.

@farshad I’m happy to share useful things. The only issue is that doing it on the forum isn’t very convenient, especially because the file limitations make it difficult to properly show and share things.

It would be really cool if you had a Discord server with different sections where people could chat with the community, exchange experiences, and also showcase their projects.

@g-honorgames Thanks for the suggestion. We went with a forum because discussions stay searchable and easy to find later, similar to Epic's own forums. Also, Discord isn't accessible here in Turkey, so this is our alternative. That said, if something about sharing files feels clunky, could you point out what exact limitation is getting in the way? We might be able to adjust it.