Nested containers
Give an item a Nested Container fragment and its owner gains a container while the item is somewhere the fragment accepts. Equip a backpack and its grid appears. Take it off and the grid leaves with it.
This replaces the component every project writes otherwise: one that watches a slot and resizes a fixed container by hand, and never generalises past the one bag it was written for.
Whose things are they: the content policy
When the item leaves the place that opens its container, that container cannot survive — there is nobody left for it to belong to. What happens to the contents is the one thing the framework cannot infer, so the item says which it is:
| Policy | What happens when the bag closes | Use it for |
|---|---|---|
| Travel With Item (default) | The contents stay inside the item and go wherever it goes | A bag that is a box: fill it, drop it, trade it, put it in a chest |
| Move To Owner | The contents go into the carrier's other containers; anything that will not fit goes to the stranded-item handlers | A backpack that is simply extra capacity while worn |
The default is the box, for two reasons: it is what a player assumes a bag does, and the other way round can destroy things — contents with nowhere to go in the carrier's pockets are lost, loudly but lost. Choose Move To Owner deliberately, knowing a bag handed to another player arrives empty.
With Travel With Item, the contents are carried on the item's own entry, which is what replicates, what saves, and what moves between inventories and out into the world. So a full backpack dropped on the ground is still full when somebody else picks it up, and a chest holding a packed bag is holding its contents too — with nothing keeping a side table of what belongs to what.
// A closed bag re-opens with everything still in it, on whoever is now carrying it.
Alice->GetContainer(WornTag)->TryTransferItem(BagHandle, Bob->GetContainer(WornTag));
An item handed to another player has already left the first inventory by the time anything notices the bag closing, so there would be no entry left to write into. A travelling bag keeps its contents on its entry at all times instead.
The fragment
| Field | What it decides |
|---|---|
| Container Definition | The container the item brings with it. |
| Container Filter | Which container the item must be in for its own to be open. Empty means anywhere its owner carries it. |
| Slot Filter | Same question for the equipment slot, when a container alone cannot tell one place from another. |
A quiver — open whenever carried
Container Definition: DA_Container_Quiver
Container Filter: (empty)
Slot Filter: (empty)
Pick the quiver up and the arrows are reachable. That is the default because it is the simplest thing that is useful.
A backpack — open only when worn
Container Definition: DA_Container_Bag_Medium
Container Filter: any tags match → Inventory.Container.Equipment
Slot Filter: any tags match → Inventory.Slot.Back
Carrying a spare backpack in your pack does not give you two inventories. Wearing it does.
Several bags at once
Two bags of the same kind are two containers, not a conflict. Each has its own container id and belongs to the item that opened it.
UEDContainer* First = Inventory->GetContainer(BagTag); // the first one
Inventory->GetContainersByTag(BagTag, AllBags); // all of them
Inventory->GetContainersByItem(QuiverHandle, ThisOne); // the one this item brought
A UI drawing "the bag" wants GetContainer(Tag). A UI drawing tabs wants GetContainersByTag.
Removing one
A nested container cannot be removed on its own:
Inventory->RemoveContainer(BagContainer);
// Warning: container 'Inventory.Container.Bag' belongs to an item and must be removed through it.
Remove or move the item and its container follows. Removing the container directly would leave the item convinced it still had storage, and nothing would ever reopen it.
What happens to what is inside
Under Move To Owner. A Travel With Item bag keeps its contents and none of the following applies — nothing is stranded, because nothing was left behind.
Taking a bag off does not destroy its contents. Each item goes to the inventory's stranded-item handlers; by default they are moved into the owner's other containers, using the same placement rules a pickup would.
Anything no handler accepts is destroyed and logged as a warning — a design gap being reported, not an event.
If you want a different answer — dropping the overflow at the player's feet, mailing it, refusing to unequip a full bag — add a handler:
UCLASS()
class UMyDropHandler : public UEDStrandedItemHandler
{
GENERATED_BODY()
public:
virtual bool HandleStrandedItem_Implementation(UEDInventoryManagerComponent* Manager,
UEDContainer* Container,
FEDItemHandle Handle) const override
{
// Spawn a world pickup, then take the item out of the dying container.
return SpawnPickupFor(Container, Handle) && Container->TryRemoveItem(Handle);
}
};
Then list it in Stranded Item Handler Classes after the rehome handler, so it only sees what would not fit.
UEDStrandedItemHandler is Blueprintable, so this can be a Blueprint class instead.
Swapping bags
Swapping a small backpack for a large one is two events: the old item leaves the slot and its container closes, then the new one arrives and its container opens. Contents from the first are re-homed before the second exists, so they land in your other containers rather than in the new bag.
That ordering is not configurable, and it is the safe one: no item is ever held by a container that is being torn down.
One container per identity, per inventory
Two items whose containers share a tag cannot both be open — every lookup by tag would be ambiguous. The second stays shut, and the inventory says so in the log.
In practice that means bag definitions of different sizes should share one tag (only one is worn at a time) while genuinely different storage — a quiver and a pouch — should have different tags.