Project settings and tools
Project Settings → Plugins → EDInventory
| Setting | What it does |
|---|---|
| Item Definition Scan Paths | Folders registered as EDItemDefinition primary assets on startup. Without at least one, entries cannot be resolved back into definitions. |
| Default Container Class | The UEDContainer subclass used when a definition names none. |
| Logging verbosity | LogEDInventory — transactions log at Display, and views narrate what they bind to at Verbose. |
| Access Policy Class | Who may operate on which container when a client asks. Empty uses the default policy; see below. |
Access Policy Class
A transaction names the containers it operates on, and one that arrived from a client named them on a player's say-so. This setting is what turns that into a yes or a no.
| Value | Behaviour |
|---|---|
| (empty) | UEDDefaultInventoryAccessPolicy — a client may act on containers its own actor holds, on those belonging to the same net owner (its pawn, its player state), on any it has an open session with, and on any marked publicly accessible. |
| Your own subclass | Override CanAccessContainer for a different notion of ownership: guild banks, party loot, spectators who may look but not take. |
UEDPermissiveInventoryAccessPolicy | No checks at all. Reasonable for single-player, a serious decision for anything else. |
Server-side game code is never gated by this — a permission system that second-guesses your own scripted grants is one nobody keeps. It applies only to requests that arrived over the wire.
See Transactions for how a container becomes reachable.
Networking
There is nothing to configure. Relevancy and dormancy belong to your actors — see Replication.
Gameplay tags
The plugin ships only the roots. Concrete tags are your game's vocabulary:
| Root | For |
|---|---|
Inventory.Container | Container identities |
Inventory.Slot | Equipment slots |
Inventory.Category | Item categories |
Inventory.Rarity | Rarity tiers |
Inventory.State | Per-stack states — drawn, stolen, bound |
Declare yours in Project Settings or natively in C++. Pick one mechanism per tag: a tag declared in both works, but the comment shown in the editor comes from whichever loaded first, so documentation drifts silently.
Editor tools
Item Composer
A guided editor for a definition's fragments, instead of the raw array picker. Right-click an item definition → Compose.
Preload Item Definitions
On by default. Loads every item definition when a world starts, so an asset id resolves everywhere
without a synchronous load in the middle of gameplay. Turn it off and call
UEDItemStatics::PreloadAllItemDefinitions from your own loading screen.
Container Designer
A details-panel extension on container definitions: apply a grid or list layout, add and remove rules, and see the resulting capacity without hand-editing instanced structs.
Validation
Asset validation runs on save and flags:
- a container definition with no identity tag;
- a layout whose Capacity Source has no registered provider;
- duplicate fragments of one type on a definition;
- a recipe whose ingredients or output do not resolve.
EDValidateInventory is the commandlet form, for CI:
UnrealEditor-Cmd.exe YourProject.uproject -run=EDValidateInventory -unattended -nop4
Runtime inspector
The gameplay debugger category (apostrophe key → EDInventory) lists every container on the actor under the cursor and what is in it, labelled by container tag.
It searches the whole gameplay-framework chain, not just the actor you are pointing at: from a Pawn it also reads the Controller and the PlayerState, from a Controller the Pawn, and so on. Every line names the actor that owns the container, so an inventory living on the PlayerState is never reported as if the Pawn were carrying it. When nothing is found, the header lists the actors it searched.
The debugger gathers on the authority and sends the result to the client viewing it. Seeing correct data does not prove the client has that data. For client-side questions, look at what the client's own UI is bound to.
Automation tests
UnrealEditor-Cmd.exe YourProject.uproject -ExecCmds="Automation RunTests EDInventory" -unattended -nopause -nullrhi
Tests live under EDInventory.Core.*, EDInventory.UI.*, EDInventory.Equipment.* and so on.
They run in a single process, so replication is not exercised. What is asserted is the thing that makes it possible — that a container's identity, capacity, contents, rules and shape are all marked to replicate. The rest wants a real session with a client attached.