Quick start — Blueprint

Fifteen minutes, no C++. At the end you will have a character with three containers, an item that can be picked up, and a panel that draws it — working in multiplayer.

Everything here is authored in the editor. The C++ quick start reaches the same result from a character class; neither is the "real" way.

1. Create an item

Content Browser → right-click → Miscellaneous → Data Asset → ED Item Definition. Name it DA_Apple.

Set:

Field	Value
Category	Inventory.Category.Consumable (declare the tag if it does not exist)
Fragments	add Display Fragment and Stack Fragment

In the Display fragment set a Display Name and an Icon. In the Stack fragment set Stackable true and Max Stack Size 16.

That is a complete item. Fragments are the only extensibility mechanism — an item is what its fragments say it is, and there is no base class to pick.

tip

The Item Composer (right-click an item definition → Compose) is a guided editor for fragments if you would rather not use the array picker.

2. Create a container

Data Asset → Container Definition. Name it DA_Container_Main.

Field	Value
Container Tag	Inventory.Container.Main — required; this is the container's identity
Display Name	Inventory
Layout	ED Grid Layout Config, Width 9, Height 3
Priority	50

Duplicate it twice more:

• DA_Container_Hotbar — tag Inventory.Container.Hotbar, ED List Layout Config with Slot Count 9, Priority 100.
• DA_Container_Equipment — tag Inventory.Container.Equipment, ED Slot Layout Config, Priority -100.

For the equipment layout, add one slot per body part. Each slot has a Slot Tag and Accepted Tags:

Slot Tag	Accepted Tags
Inventory.Slot.Head	Inventory.Slot.Head
Inventory.Slot.Chest	Inventory.Slot.Chest
Inventory.Slot.MainHand	Inventory.Slot.MainHand

Priority is how eagerly a container claims an item nobody routed: the hotbar at 100 fills before the grid at 50, and equipment at −100 is a last resort.

Give equipment an Item Query

A slot with empty Accepted Tags takes anything, which is what an off-hand is for — but it also makes the paperdoll six slots of spare storage for whatever gets picked up. Set the container's Item Query to any tags match → Inventory.Slot so only equippable items are ever routed there. Dragging by hand is unaffected; the query only gates automatic placement.

3. Give the character an inventory

Open your character Blueprint. Add Component → ED Inventory Manager Component, name it Inventory.

In its details, fill Initial Containers with the three assets, in the order you want them consulted:

1. DA_Container_Hotbar
2. DA_Container_Main
3. DA_Container_Equipment

Optionally add Initial Items — a definition, a count, and an optional container tag — for a starting loadout.

That is the whole setup. One component, three data assets.

4. Pick something up

The plugin does not decide what a pickup is; that is your game. The minimal version:

1. Make an actor Blueprint BP_Pickup with a mesh and a collision volume.
2. On Event ActorBeginOverlap, get the other actor's inventory and give it the item:

Event ActorBeginOverlap (Other Actor)
  └─▶ Get Inventory Manager  (Actor = Other Actor)      ← static, found by interface or component
        └─▶ Is Valid ?
              └─▶ Try Add Item  (Definition = DA_Apple, Count = 1)
                    └─▶ Branch (Return Value)
                          └─ True ▶ Destroy Actor

Try Add Item with no Preferred Container asks the item where it wants to go, then falls back to container priority. With the setup above, apples land in the hotbar until it is full, then in the main grid.

Run this on the server

Try Add Item is authority-only and returns false on a client. Overlap events already run on the server for a replicated actor, so the graph above is fine — but if you drive a pickup from input, route it through a Server event first.

5. Draw it

Create a Widget Blueprint whose parent class is EDInventoryGridWidget (for the grid) or EDInventoryBarWidget (for the hotbar). In the designer, set:

• Slot Widget Class → a widget deriving from EDInventorySlotWidget
• Cell Widget Class → a widget deriving from EDInventoryCellWidget

Then bind it to a container. In your HUD Blueprint:

Event Construct
  └─▶ Get Inventory Manager  (Actor = Get Player Character)
        └─▶ Set Source Inventory  (Target = MyGridWidget,
                                   Inventory = ↑,
                                   Container Tag = Inventory.Container.Main)

Bind by role, never by pointer

Set Source Inventory takes an inventory and a tag, meaning "this actor's main grid". On a client the container does not exist yet when the HUD is built, so a view bound to the pointer that exists at that moment binds to nothing and stays empty for the whole session. Bound by role, the view attaches itself the moment the container replicates in.

Use Set Source (which takes a container directly) only for a container you already hold — a chest you just opened.

6. Check it in multiplayer

Set Number of Players to 2 and play. In the client window:

• picking up should update both the count and the panel;
• the gameplay debugger (apostrophe → EDInventory) should list three containers.

If the panel is empty on the client but correct in the debugger, the view is bound by pointer rather than by role — see step 5. The debugger collects on the server, so it looking right does not prove the client has anything.

What you have

• Items and containers described entirely by assets.
• A character with a replicated, server-authoritative inventory.
• Data-driven placement: the hotbar fills first because of a number in an asset.
• A UI that survives replication timing.

Next

• Placement and routing — how Try Add Item really chooses.
• Nested containers — a backpack that brings its own grid.
• User interface — drag-and-drop, quick transfer, tooltips.
• Blueprint reference — every node, grouped by what it is for.