Saner Inventory through Unified, Nestable Containers [$255]

[jjs2]

Change backpacks, duffel bags, etc. such that they're

1. actual "containers" (i.e. each with its own internal invlet) [even if you can still "wear" them for a slight encumbrance reduction],
2. nestable inside any container with a larger volume. [Less important than (1)!]

This will fix the gross absurdities of the inventory-letter-based item limit, and will make e.g. duffel bags useful for melee characters.

(For example, Joe the Swordsman sees zeds approaching; he drops his duffel bags full of crafting gear and skill books, and proceeds to hack and slash unencumbered. If Joe has to retreat, then retrieving his bags makes for an interesting tactical challenge [cf. the duffel bag Rick drops in downtown Atlanta in Season 1 of "The Walking Dead"].... especially if an NPC tries to grab the gear first!)

This will also be useful if you want to sort your gear by intended purpose, for quick mission-specific load-outs.

(Currently the closest thing to this goodness is the humble shopping cart, but those don't fit into trunks very well... ;)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[VampyreLord]

wondered why this isn't a feature yet. It's more convenient to "let go" of the bag when you need to and retrieve later without having to drop any items aswell. They should act like shopping carts basically with their own respective volume limit.

[kevingranade]

This is something we've planned for a loooong time. The reason it hasn't happened is the inventory system is a horrifying mess, so doing anything to it takes forever, with frequent breaks to regain lost sanity.

[ianestrachan]

Sounds like the way inventory management works on your average MUD. A good idea, and it would make #2846 easy. But to fully support this, you'd need to add commands to put an item into a container, take an item out of a container, move an item from one container to another, empty a container into another container, empty a container on the ground...

Some of them can be done with current commands (emptying containers is already done with 'U'nload) but others need more commands, and we're starting to run out of letters.

[kevingranade]

A naive ui would be disastrous. (See df adventure mode inventory) What the ui needs to do is present a flattened view of the aggregate inventory, which the player can drill down into as needed, to e.g. put certain items in quick access (pockets, belt rig) or into a specific container for easy dropping. There's a LOT of words on this subject in the forums.

[Zireael07]

@ianestrachan, @kevingranade : I could see some dialogs added to existing commands for example. On pressing 'g' (aka. get item from ground): Which container do you want to store it in? a b c (an invlet)

On pressing 'd' (aka. drop item) empty to ground by default if we have other containers, display an invlet

We could put 'moving items from a container to a container' under 'T' (take off).

This way, we wouldn't run out of letters.

[i2amroy]

Yeah definitely planned, it's just that what's currently there is such a horrifying mess that it would almost be easier to rewrite it instead of trying to fix it. Combine that with the fact that inventory code touches on almost every part of the game, and you can see why it hasn't happened yet. :P

[jjs2]

There are a couple ways to handle this....

In NetHack, 'a' (apply) on a sack gives you the option to put items in or take items out....

It would be nice if, say you have a bag with inventory letter 'b', putting an item inside would give it a compound letter, like bc.... recursively, so a duffel 'a' with a bagab that contains a wrench `abc.... Then you could move items about simply by relettering them....

[ianestrachan]

Actually, it'd be really nice to have something like the Advanced Inventory screen for shuffling stuff between containers. But instead of the 9-square grid, have a column with a list of all containers in your inventory. Instead of pressing 0-9 to change the square for the active panel, use a-z to select a container from the list for the active panel.

Add one special entry to that list for the ground, and another for stuff not in containers (your weapon, the +2 grace volume, and 0-vol items) and you're set.

[jjs2]

I really like how much thought everyone is putting into this. At their essence, Survival games and Roguelikes are games about inventory management, so inventory code and UI deserves to be the most polished part of Cataclysm, not the most feared!

[narc0tiq]

I've arrived at this issue again, semi-randomly, and I'm struck by how much I like this idea:

It would be nice if, say you have a bag with inventory letter 'b', putting an item inside would give it a compound letter, like bc.... recursively, so a duffel 'a' with a bagab that contains a wrench `abc.... Then you could move items about simply by relettering them....

The one part that bothers me, however, is turning single-key selections into at least three keys (and that's the minimum, and only if you're referencing something directly worn): backtick, item letter, Enter (to signify the end of input).

But there's no reason you couldn't still have both. Use the shortkeys as they are right now -- player-assignable and everything -- and add the backtick addressing scheme as the item's "full address" within your inventory. The only limitation then is what happens when there are too many items in a container to address with a single character, to which I can see two possible solutions:

• force item indices to be a single character. We can use up to 92 characters for these, but then we'd have to limit all containers to no more than that. Addresses look like abc for the "c" item in the "b" container in the "a" container.
• add a path separator to disambiguate. Item indices can be any number of letters long, since we use the path separator (let's say, /) to separate the container from its contents. Addresses look like a/bc/de for the "de" item in the "bc" container in the "a" container.

Both of these are feasible, though the one interface problem of showing the long addresses remains. But we'd have to redo the inventory screen to display a (flatten-able) tree of items anyway.

[kevingranade]

So a path-based key sequence, I agree that sounds good for moving items around between containers, and that might make sense for some people with a 'container view' of their inventory.

[narc0tiq]

Yeah, it seems like a decent implementation for AIM-less inventory management. AIM would just work as a Norton Commander-alike.

[DavidKeaton]

Was pondering this exact issue.

[rtizzy]

• Player opens inventory
• Player accesses a container
• Player stores item in container
• Player drops container
• Items remain in dropped container

How does player know a dropped container has items in them?

How are containers with items and without differentiated when dropped?

[Night-Pryanik]

Color differentiation.

[rtizzy]

@Night-Pryanik

How would the Player (Not the player character) know that by looking at it with the "x" command or by looking at the V items men?

Additionally what happens if multiple containers of the same type (say a leather backpack) are on the same tile?

This would need to be managed as well.

[cainiaowu]

What about a Dwarf Fortress trading screen style?

When selecting containers you select them all, or you can select item in the containers individually.

[Shoes01]

I have been out of the loop regarding item storage discussion, but I think creating a Project for how containers should work would be practical. Gathering established ideas, putting them in a central place, and chunking them would allow small-time contributors to chip away at the project without losing their motivation and leaving it unfinished.

[AndrewMcKinney]

Perhaps the player should not micro-manage everything that is in a bag. Instead the player could designate different bags for different purposes which would not require a complex UI.

In a way, every storage container could be treated like the zones that where added recently, not a perfect solution but I think it preforms better than nothing.

[TheRealGunShy]

Perhaps the player should not micro-manage everything that is in a bag. Instead the player could designate different bags for different purposes which would not require a complex UI.

In a way, every storage container could be treated like the zones that where added recently, not a perfect solution but I think it preforms better than nothing.

I second this suggestion. Container flagging for quick sorting sounds rad. Your character already auto-deposits arrows into a corresponding quiver when you pick them up. Could that be extended to an overhauled inventory structure?

[kevingranade]

To be clear, especially since this issue has such a large bounty attached, a candidate feature to enable this must have the following features:

• Picking up or otherwise placing items in the inventory must automatically select a target container by default.
• The capacities of individual containers must be respected, i.e. if there is no single container with sufficient capacity for a new item, the inventory is considered full.
• The default placement algorithm must include a reasonable system for approaching efficient packing of items in containers.
• There must be a UI comparable to the current inventory menu that allows players to manage their inventory contents without interacting with individual containers.
• There must be a UI that allows examining and interacting with containers, i.e. to shift items between containers in the inventory.
• Items must move along with their container, so wielding or dropping a container must move the associated items along with it. The system must also handle container destruction.
• Examining containers on the ground must allow interacting with the contained items.

Some nice-to-haves:

• Commands can prompt the player to target a particular container, or "retroactively" correct which container the item is placed in.
• A single item may contain several sub-containers (i.e. several pockets).
• Containers or sub-containers may have different access times.
• Explicit or implicit tagging to associate items and/or item types with containers.

[Dansiman]

• The default placement algorithm must include a reasonable system for approaching efficient packing of items in containers.

An extremely simple algorithm that is about as efficient as possible is this:

• From all containers with enough room to hold the item picked up, choose the one with the least available space.

As far as code efficiency, I speculate that a fairly good approach might be to quicksort the list of containers by their remaining unused space, from least to greatest, then iterate through the list until you reach the first one with enough space to hold the item in question. (Whether it'd be more efficient to calculate each container's free space on the fly whenever an item is picked up up (more calculation), or for each container to have a persistent "free space" property that is updated every time something is added to or removed from that container (more memory usage), is a question I'll leave to those with more experience here.)

[BBlankie]

How about an option to switch into both container catagory and item type catagory, item type catagory is your average catagory that groups what kind of item and the container catagory is where items grouped by container that stores them.

And/or a collapsible list to hide and show (sub-)catagorys

Also a filter where picked up items automatically placed on targeted container, based on item kind or multiple list of names.

And volume should be replaced with total volume and volume from container.

[Dansiman]

Just had an idea for the interface to move items between containers:

1. Display the inventory as a tree view, with items displayed immediately below the container they're in, and indented.
2. Plus and minus keys can be used to expand/collapse a container.
3. Like the Sort Armor screen, press Enter to "grab" an item and move it up/down the list. If the container into which you would be moving the item doesn't have enough room for it, color the item red.

This could also be used to unload/reload items.

A quick mock-up:

                                           Volume          Storage
- B [ || backpack                            2.00       4.50/10.00
  - w / || copper spear                      1.50
  -   ) 3 plastic bottles                    1.50        1.50/1.50*
    -   ~ clean water (6)                    1.50
  -   ) 2 plastic bottles                    1.00        0.00/1.00*
  + b [ canvas bag                           0.25*       0.00/1.00
  -   ) tin can                              0.25        0.25/0.25*
    -   % mashed pumpkin (fresh) (cold) (1)  0.25
+ j [ |\ jeans                               2.00        0.25/0.50
- f [ || army jacket                         3.00        1.50/3.50
  - s , hobo stove (35)                      1.50        0.18/0.25*
    -   = tinder (35)                        0.18

Here, the asterisk indicates a container that can only hold certain types of things - liquids in the bottles, tinder in the stove, etc., or for the canvas bag, that its volume will increase when things are added to it.

[ThomasLinkin]

2 years and this one is still staying out of the Project tab. The inventory system must be really messed up

[KorGgenT]

there was a project for it on this repo at some point, but it didn't go anywhere. i've got a personal project for it, and plan to pick this up once 0.E is in sight or released

[FeepingCreature]

Alternate proposed implementation approach, moved here to deduplicate:

Proposed solution: Volume Assignment

Items gain a new internal field indicating the parent container that contains them. When the parent container is moved, all nested items are also moved with it, for free, without losing their parent. (Their encumbrance is accounted for by the parent container's encumbrance.) When picking up an item that has child items in the same inventory, the child items are likewise moved for free.

Additional notes

I'm calling this "volume assignment" because items are assigned to the item which provides the volume that contains them.

It would be logically cleaner to represent contained items as a list of children in the surrounding container, as has been proposed here. However, this would require all code that handles inventories to be changed. Using a parent field allows for a gradual introduction.

The ability to assign items to containers would be handy, but is not necessary for the usecase of divesting yourself of encumbrance before combat.

There is no need to represent this in the inventory UI in the initial implementation, though it could be done by a gray right-aligned text in the inventory stating the container. Indentation is less useful in the player inventory, because the containing inventories will usually be [W]orn.

When picking up items, the default sort mode should show contained items indented under their parent container, similar to Dwarf Fortress.

Proposed implementation tasks

Each of those tasks could be handled in a separate PR.

• add a parent container reference to items
• assign items to a parent container on pickup, respecting that container's volume limitation
• when item is dropped, drop child items as well, keeping parent assignment
• when item is picked up, pick up child items as well
• when item is destroyed, spill contained items into the surrounding inventory or the ground
• show volume assignment in the player inventory
• show volume assignment in the pickup inventory
• add menu entries to [take out]/[put into] items.

Don't forget to assert that parent items are in the same inventory as the child item!

[kevingranade]

This issue has been mentioned on Cataclysm: Dark Days Ahead. There might be relevant details there:

https://discourse.cataclysmdda.org/t/mr-roboto-a-diy-robot-idea/22446/12

[kevingranade]

This issue has been mentioned on Cataclysm: Dark Days Ahead. There might be relevant details there:

https://discourse.cataclysmdda.org/t/new-things-ive-noticed/23541/15