Revert nested container priority over parent container

[oosyrag]

Is your feature request related to a problem? Please describe.

Prioritizing nested containers over parent containers seems to be causing some grief, with strange things being placed in strange places against player inclinations.

Making an issue to add to my to-do list, as well as to open discussion and check to confirm if this behavior is still explicitly wanted, especially by @bombasticSlacks,, who I believe asked for it in the first place in #53807 (I do note the bit about being optional, but that's not a thing yet), and @robkuijper who implemented #54941. Also noting rob's comment https://github.com/CleverRaven/Cataclysm-DDA/issues/55270#issuecomment-1037399417, which I'm taking as being open to reverting the default priority to parent container.

Solution you would like.

Parent containers should be prioritized over nested containers for auto pickup.

Nested containers should be automatically filled after parent container has no volume remaining.

Describe alternatives you have considered.

No response

Additional context

No response

[bombasticSlacks]

Honestly some other people had very strong opinions about the pickup code and pockets so I just kinda moved on to other stuff. I appreciate the ping but not my rodeo. I made that issue because I was annoyed rigid containers contributed volume in the "x mL out of y mL of space" thing in the inventory UI even though nothing auto went in them which is confusing to new players "why can't I fit this thing in my inventory it says I have space". So I just wanted the UI consistent with reality 😆

I do plan to add some UI to support organizing pockets in the future but not touching the pocket priority stuff.

[PlutusPleion]

I think a lot of people are split over this. Maybe a good solution is to make it an option in the settings? Including nested pickup as well, I've seen some people not wanting it.

[oosyrag]

Sounds like an option is the way to go, but I'm curious what the rational is for having random(?) nested containers filled first is.

I totally understand the frustration of the pickup function not utilizing the space at all, but this is more a matter of using the larger parent space first by default before shoving things in nested pockets.

I'd put the priorities at: Defined pocket priority > Largest to smallest pockets > Largest to smallest nested pocket, starting from largest to smallest parent pocket that has a subpocket > Recurse until no pocket can fit item.

So I guess the option would be "Default pickup pocket priority": "Parent pockets first ", "Nested pockets first"?

Or is it an issue of utilizing nested pockets at all? That would entail a second option "Allow pickup into nested pockets": "Yes", "No"

Edit: Smallest to largest sounds good, for the reason stated below. My first inclination was that I usually want to put things in my backpack before pants, or cardboard box before the tin cans, but the reasoning for the other way around is sound. I'll have to manually set all backpack priorities high every time, but that's no worse than before I guess.

[ProjectileWaterfowl]

Sounds like an option is the way to go, but I'm curious what the rational is for having random(?) nested containers filled first is.

One thing I can think of is that items small enough to fit into nested containers may take space in the larger container that will later block items too large to fit inside those containers. Fitting items into nested containers by default allows for maximum capacity without user interaction, though I personally find it annoying because I haven't looked into setting up pocket/container priorities yet and my empty water bottles keep getting filled with random junk.

For the priorities, correct me if I'm wrong, wouldn't it be better to go from smallest pockets to largest to hold that space as long as possible for larger/longer items?

[robkuijper]

I agree with the fact that nested pockets being filled first was just a bad decision. The motivation at the time was like @ProjectileWaterfowl mentioned: trying to optimally use inventory space. There was a short conversation about this on Discord, and at the time it seemed like the way to go, but looking at it now it'll convolute your inventory way too much (at least until there is better UI?).

I wanted to fix nested-pocket-related-issues along with this annoyance, but I think I'll just make a separate PR to fix this first.

Priorities after fix should be from smallest to largest pocket, but will just fill 'parent' items/pockets first, and then 'child' pockets.

Question then becomes if the want for an "Allow pickup into nested pockets" configuration is large enough. The fix for the pickup priority from child-first to parent-first is really small/easy, the configuration option will take more time/effort.

[Shibimon]

Maybe fill nested at pickup and parent with managing inventory or unloading containers? Most annoying thing is i unload a random box or container and it fills other random containers of the same type ad infinitum and led to this as the only way i found arround it: Manually unloading single container > Dropping empty container > Repeat for every box you managed to gather.

[robkuijper]

That might also work, but I think reversing the child > parent to parent > child will also solve a large part of this issue.

Sure, unloading the first container might still fill others, but dropping the (now empty) container will free up the space it used initially, so you should be able to unload into the 'parent' instead of other random containers. Until the 'parent' is stuffed again of course...

Lets keep it in mind as a possible/better solution. Seeing how it's more work to implement though, I won't work on it right now.

[bombasticSlacks]

A couple of things worth keeping in mind before people reinvent the wheel.

Unload into tile (which I think might be unbound by default) is a much more robust unload than basic unload. It never dumps stuff into your other pockets.

Pockets already have a configuration for "don't fill unless I manually insert" and "never unload". It might be worth using those since if I'm used to having a pot in my bag I probably want it's space auto used which again is why I wanted this off by default and togglable.

[mqrause]

I still think filling nested open containers is a bad thing. The solution should be they only use up their net volume (total volume minus volume of open rigid pockets) in the parent container. That solves all problems related to open containers at least.

[LeahLuong]

Is there some characteristic of, for example, buckets & pots that could be exploited here?? These are the sort of items that can't be carried in a pocket if they have a fluid in them; I assume this is governed by flags. Could you ref those flags as a way to insert items into these sorts of containers if they're nested?? Like, if you have a backpack w/ a bucket in it, that bucket is naturally going to use its volume to contribute to the backpack's in a way that a plastic bottle won't & shouldn't w/out considerable time investment.

[pcdms-rygonia]

hi im new to this github (only just made 2 suggestions today) :) so if this is not where i should post this, sorry in advance :)

is it possible for any container fix/future fix you are mentioning, to also take into consideration if a player is using the debug mode?

for example, i have been using 0.F-3 this month, to try and learn the game, so to get a feel for things i just wanted to play with the debug infinite pocket dimension option, (to basically ignore weight, length, and volume limits), just to focus on learning the base game mechanics. (possibly slightly cheaty i know but it was for science) :o)

however, after having an issue with my local test game (after about 50 days worth of picking up pretty much everything i could carry), i found a problem where even just picking up 2 or more planks/shards, or clothing with pockets, causes something like 3million to 3billion cpu cycles (maxed out).... and maybe it is due to the game, trying to iterate over and over, which nested item or which pocket to put 1 shard in and is related to this?

(i had also tweaked the pocket universe debug to the following)

{ "id": "debug_backpack", "type": "ARMOR", "name": { "str": "debug pocket universe" }, "description": "A pocket universe. Can store approximately 384 * 10^6 bugs.", "weight": "1 g", "volume": "1 L", "price": 0, "price_postapoc": 0, "material": [ "cotton" ], "symbol": "[", "looks_like": "backpack", "color": "yellow", "encumbrance": 0, "max_encumbrance": 0, "pocket_data": [ { "rigid": true, "pocket_type": "CONTAINER", "max_contains_volume": "100000 L", "max_contains_weight": "100000 kg", "moves": 1, "max_item_length": "1 km" } ], "warmth": 0, "material_thickness": 0, "flags": [ "BELTED", "WATER_FRIENDLY", "TARDIS" ] }

and the mutations file i had edited to this for last line in weight capacity modifier:

{ "type": "mutation", "id": "STRONGBACK", "name": { "str": "Strong Back" }, "points": 2, "description": "You are capable of carrying far more than someone with similar strength could. Your maximum weight carried is increased by 35%.", "starting_trait": true, "valid": false, "cancels": [ "BADBACK" ], "weight_capacity_modifier": 100.35 },

[pcdms-rygonia]

for example, IF using debug mode, for the game to try to just pickup the items into the quickest (realtime) amount of time, instead of starting any more complex calculations about which place is more efficient?

(the debug backpack has about 5475 items currently)

[mqrause]

hi im new to this github (only just made 2 suggestions today) :) so if this is not where i should post this, sorry in advance :)

It would be better to make a separate bug report for this.

[pcdms-rygonia]

ah ok thanks, i will get files together and make a new one with the info from above.

ok i made it here for you: https://github.com/CleverRaven/Cataclysm-DDA/issues/55654

[KurzedMetal]

I'm not 100% sure if these issues were introduced by this feature too, but I found 2 things that are a bit annoying:

1. if you have 2 filled containers (example two medkits) and you want to unload their contents in your inventory. The first will unload, but the second with unload directly INTO FIRST CONTAINER (now empty). So basically you can unload only one container, the other one will always have contents no matter how many times you unload. That's an unexpected behavior that IMO is a bug as it breaks unloading.
2. if stuff gets assigned immediately a container when they are picked up, they don't show in advanced inv management, because AIM doesn't show content in containers. Normal inv ("i" hotkey) does show container items, but this a pain for players (like me) that heavily use AIM and rarely use "i" inventory.

[oosyrag]

Both of these issues should be resolved by prioritizing parent containers, at least until the parent containers have no more room.

[KurzedMetal]

I agree that prioritizing parent is better, but I disagree for "until parent containers have no more room".

Or at least I'd like that as an option, because TBH I like how it was before where I have to explicitly put things into containers. I don't want random items to go into containers without my consent.

Otherwise I'd have to go through all my "> x items" containers to see which one got some random loot in them or I actually put them in there.

Also, @robkuijper suggested to use the per container setting to control this, but the problem is the default assigned to picked up containers. I don't to go changing the settings for every container I pickup.

[martosss]

I think pockets should be filled based on 1) Minimum action points required first, not based on pocket volume. ( I think that's the current behavior?) 2) When (1) is equal, use the most parent container(i.e. take depth 1 backpack instead of bottle inside bottle, if they have the same cost) 3) When (1,2) are equal, use the smallest free container available - minimum of % full weight and % full volume( and of max length? somehow? Not sure how/if this can/should be compared to weight & volume; Ideally it should, but ... I think volume is a biger concern in general)

This reasoning should achieve:

• order - force the character to use parent pockets first as they require less action points to be used, ALWAYS, right? That also means less nested items in general.
• gameplay efficiency (1) - use minimum amount of in-game time to store items;
• gameplay efficiency (2) - still use nested rigid containers, but only when everything else is full.

Using nested pocket first seems like a bad idea to me since it will take more time to insert items in the nested container and then take them out.

Quick thought experiment - you pick up 50 plastic bags and then you pick up a bunch of other items. Result - A chaos of 50 nested bags? Do you really want that? In addition, you'd take 50*400 action points to store each item in the inner-most bag .. that's awful.

You should always store in the easiest place first. Real life probably works similarly - you fill up your suitcase with clothes first and only when it's full you start optimizing and putting socks inside shoes and filling empty bottles with pencils.

Personally I tried using a "drugs" bag, but ultimately unloaded it and now I'm not using more than the minimum necessary amount. Instead I use favorites to label which items are equipment vs simple loot

[Shibimon]

Valid points, but i still think that will need to edit most containers use time to be more than almost all parent containers to avoid the issue this PR is trying to adress. Basing priority on speed after parent first and then nested sounds well, as at this moment i have to deal with this while playing and is infuriating and i guess other players share the feeling. I utterly hate the small carboard boxes and how now we have to unload a single one, and drop that single box, to unload and drop the next and then the next to drop ad nauseam as it is the only way to prevent items being unloaded from one box into another infinitely. I learned to never ever again grab the pile of boxes in my inventory to prevent hell and if i need to move that accursed pile of cardboard just drag it arround the floor losing 6+ minutes of player life per tile to do so is the better way to do it.