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 with snapshot rollback, so a failure halfway through leaves nothing half-applied, even across two containers on two different actors.
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, prediction, the GAS bridge. |
| 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. |
| Spatial | Rotation and shaped (non-rectangular) item footprints. |
| Weight | Per-item weight, an actor-wide total, and a weight-limit rule. |
| Durability | Wear, repair, and break behaviour. |
| Crafting | Recipe assets and one atomic craft request. |
| Trading | Vendors with currency, buy/sell pricing hooks. |
| Loot | Weighted, budgeted loot tables rolled from a seeded stream. |
| Usable | Consumables and use effects. |
| Networking | Relevancy and bandwidth policy. |
| Editor | Item Composer, Container Designer, validation commandlet, gameplay-debugger inspector. |
| 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.
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.