Inventory & Items

Canonical GDD content

Model — [CONFIRMED] SCUM-style worn containers + weight

Carry space is not a single fixed backpack grid. It is the sum of storage provided by worn clothing/equipment (SCUM-like), plus a small body/pockets baseline so a stripped character can still hold a few items.

• Weight still drives encumbrance (move speed, stamina). See 04-Survival-System.md.
• Slot count and weight cap both come from equipped containers (pockets, pants, jacket, vest, backpack, etc.). Removing a container that still holds items is refused until those items are moved or dropped (v1). Nested “items live inside the backpack item when unequipped” is the long-term SCUM target — [TBD] implementation after clothing-as-container instances exist.
• Not a Tetris/grid-shape inventory. Each container is a list of stack slots.
• Backpack (when worn) is the largest typical container and is dropped on death as part of the loot bag.

Equipment slots — [CONFIRMED]

Body armor vs vest layering is [TBD]. Clothing that provides storage declares ProvidedStorageSlots + ProvidedWeightCapacity on the item definition.

Player inventory UI — [CONFIRMED]

Widget: WBP_Inventory (/Game/Lambeer/UI/Inventory/). Open/close does not pause the world (multiplayer).

Open: Enhanced Input action IA_Inventory (/Game/Lambeer/Core/Input/Actions/IA_Inventory). Default mapping Tab — [RECOMMENDATION] until a settings screen exists.

Close: IA_Inventory again, or Escape.

Back weapon slots 1–2: only firearms and melee that allow back holster. Assigning them equips the item to that slot (removed from a container). They are not a second copy of the item.

Use quick slots: player-assigned references to items already in inventory (consumables, medical, tools, building hammer, etc.). Using a quick slot consumes/uses that inventory stack; it does not create a separate stash. Count: 8 — [RECOMMENDATION]. Keyboard binds for use (e.g. 3–0) are [TBD]; combat draw of back weapons 1–2 is [TBD] in 03-Combat-System.md.

v1 interaction: click a use-quick or back slot, then click an inventory cell (or the reverse) to assign. Drag-and-drop is [TBD].

Character-creation UI, if open, takes priority (inventory toggle is ignored).

Item definition (data-driven)

Every item is a UDataAsset (or DataTable row) — never a bespoke class per item. Base fields:

Subtypes extend the base with type-specific data (e.g., weapons reference their combat stats — see 03-Combat-System.md).

Magazines are inventory items with per-instance loaded ammo (not a stack of empty mags). Load/unload ammo from inventory anywhere. Weapon attachments (including a mounted mag) persist on that weapon instance when dropped or looted. See 09-Weapon-Customization.md.

Containers

• World containers: storage boxes, lootable corpses, vehicle storage, environmental loot (crates, cabinets).
• All container contents are server-authoritative and, for player-placed storage, persisted.

Looting & dropping

• Death: all carried items + backpack drop into a lootable bag at the death location (full-loot, hardcore — [CONFIRMED]). The bag persists for a despawn timer.
• Drop-trade: the only player-to-player trade mechanism is dropping items for another player to pick up (no trade window). See ../04-Multiplayer/04-PvP-Raiding-and-Trading.md.

Loot economy

• Loot sources: zombies (especially bosses), environmental containers at POIs, other players' corpses/bases.
• Loot tables are data-driven and tied to region/difficulty and zombie/boss tier.
• Drop-rate ownership — [CONFIRMED]: drop chance belongs to the loot source/location/container/enemy/boss reward table, not to the item definition itself. Item definitions may carry rarity/tier metadata, but the source decides whether and how often that item appears.
• This rule applies globally across environmental containers, zombie loot, boss rewards, resource nodes, fishing/cooking/medical reward sources, and any future event or quest-style reward table.
• Scarcity is intentional — it powers the gun↔melee balance and the value of every excursion.

Networking & persistence

• The owning player's inventory replicates to that client only (privacy + bandwidth); the server validates every add/remove/use.
• Player inventory and equipped state are part of persisted player data. Placed-container contents are part of persisted world/base data. See ../04-Multiplayer/01-Network-Architecture.md.

Implementation guidance

• UInventoryComponent + UEquipmentComponent on the character (C++).
• Item stacks stored as lightweight structs (item ID + quantity + per-instance state like durability, BloodAmount, WetAmount on worn/held items, attached parts, mag contents, chambered round), not full UObjects per stack, for replication/persistence efficiency. There is no dirt field. Unequipped backpack contents do not take rain wetness in v1.
• Inventory UI is UMG (Widget Blueprint child of C++ ULambeerInventoryWidget) bound to replicated C++ state. Toggle lives on ALambeerPlayerController via IA_Inventory. See ../06-Art-Audio and ../05-Technical/02-CPP-and-Blueprint-Guidelines.md.
• Player UInventoryComponent slot/weight limits are derived from UEquipmentComponent worn storage. World loot crates keep their own MaxSlots / MaxWeight.
• UI assets: /Game/Lambeer/UI/Inventory/WBP_Inventory, WBP_InventorySlot, WBP_InventoryContainer. Toggle: IA_Inventory (default Tab on IMC_Default) plus Escape to close.