ED Inventory
A multiplayer-first inventory framework for Unreal Engine 5.8. Items are data, containers are data, and the server is the only thing that decides. Everything below is reachable from Blueprint and from C++ — neither is a second-class citizen.
The model in one page
Three things, and nothing else is mandatory.
An item definition (UEDItemDefinition) is an asset describing a kind of item. It carries a
category, some tags, and a list of fragments — one per orthogonal question about the item. A rock
has one fragment. A sword has eight. There is no base class to inherit from and no interface to
implement.
A container definition (UEDContainerDefinition) is an asset describing a kind of container: a
hotbar, a paperdoll, a chest. Its shape, its capacity, what it accepts, how eagerly it claims things.
The inventory (UEDInventoryManagerComponent) is one component on an actor. You list the
containers it should build; it builds them, replicates them, and answers for all of them at once.
UEDItemDefinition ──fragments──▶ what an item IS
UEDContainerDefinition ────────▶ what a container IS
UEDInventoryManagerComponent ──▶ what an ACTOR has
A game can ship every item and every container as assets and never write a line of C++.
What that buys you
Placement is data. Ask the inventory for an item with no destination and the item's own preferences decide where it lands — belt first, then backpack, then whatever will take it. A potion reaching the quick bar before the pack is authored, not coded.
Storage can travel. A backpack is not a container the character has; it is a container the backpack has. Equip it and its grid appears; take it off and the grid leaves with it, contents handed back rather than destroyed.
Every change is a transaction. Add, move, split, craft, buy — all of it goes through one pipeline
that journals each mutation and can undo them in reverse, so a failure halfway through leaves nothing
half-applied, even across two containers on two different actors. FEDBatchTransaction extends that
across several transactions at once: give five items or give none.
Clients ask, the server answers. A request made on a chest the client does not own is routed through something it does, because the alternative — Unreal silently dropping the RPC — is a bug you find in playtest and not before.
What ships
| Module | What it adds |
|---|---|
| Core | Items, fragments, containers, the inventory manager, transactions, rules, layouts, save/load, the GAS bridge, spatial footprints, and the networking relevancy policy. |
| Equipment | Worn gear on the body: attach finders, per-state visuals, equip slots. |
| UI | An MVVM view model plus grid, list, bar and slot widgets with drag-and-drop. |
| Weight | Per-item weight, an actor-wide total, and a weight-limit rule. |
| Durability | Wear, repair, and break behaviour. |
| Crafting | Crafting in three shapes: shapeless recipes, shaped patterns matched on a grid, and fuel-burning processing over time. |
| Trading | Vendors with currency, buy/sell pricing hooks. |
| Loot | Weighted, budgeted loot tables rolled from a seeded stream. |
| Usable | Consumables and use effects. |
| GAS | Ability, effect and attribute-set grants that follow an item's equipment state; capacity from an attribute. |
| World | Items as things in the world: dropped loot, display cases, weapon racks. |
| Editor | Item Composer, Container Designer, validation commandlet. |
| Equipment · Mutable | Optional: armour that changes the character's mesh instead of attaching to it. |
Core has no dependency on GAS, UMG or CommonUI. The feature modules are additive — each one is built on Core's extension points and changes no Core signature.
Spatial footprints and relevancy each used to be a module and now live in Core: neither was a feature
built on an extension point, which is the thing that earns a module. The GAS bridge went the other
way, out of Core into EDInventoryGAS, so a game that never grants an ability does not link the
ability system. What Core keeps is the seam — capacity from an attribute is a source resolved through
a registry, and the GAS module registers the implementation that reads one.
The Runtime Inspector (the Gameplay Debugger category showing an actor's live containers) is in Core rather than the editor module, because a packaged development build has no editor modules and that is exactly where a live inventory is hardest to inspect.
Where to go next
- Installation — enable the plugin and point the Asset Manager at your items.
- Quick start — Blueprint — a working inventory without writing code.
- Quick start — C++ — the same result from a character class.
- Core concepts — the model in depth, once the quick start makes sense.
Replication explains what is server-authoritative, what a client is allowed to believe, and the two mistakes that only ever show up with a real client attached.