Improve obtain_cost algorithm for pockets

[KorGgenT]

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

Right now the obtain cost is very simple: you add up all the base moves of the pockets and add the inventory handling multiplier on top.

Describe the solution you'd like

I would like to see the cost of grabbing an item from a pocket be based on the other items that are in that pocket, simulating rummaging through the pocket to find said item. The infrastructure is nominally in place in item_pocket::obtain_cost(), so that's where the algorithm would be for such a thing.

Describe alternatives you've considered

leave it as it is?

Additional context

my math skills are not strong enough to do something like this, and i could only do a "good enough for now" solution. As such, i thought i'd open up a feature request to hopefully let people know it's something that's desired, and for it not to get lost in my mind.

[RoyBerube]

My opinion is that this is a very low priority issue.

I don't think it affects game-play that much. Sure, it might reflect reality a little more. Large items such as tennis rackets are easier to find in a bag than tiny items like coins. But is the added complexity worth the trouble?

[KorGgenT]

it might not be high priority, but i wanted it listed because i wasn't planning on being the one to implement it, as i have other things to do. any complexity added by this will likely be relegated to a single function that calculates moves, rather than just being a flat number that's always the same.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not \'bump\' or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered.

[I-am-Erk]

OK so this is directly related to another issue I'd like to write, about furniture and vehicle container access time (rummaging), so I have been thinking about this a bit.

Initial thoughts:

• number of items is generally more important than volume of items
• what portion of the max volume of the pocket is full is important as well
• at low 'fullness' it should always be quick to pull the item you want
• at few number of items it should always be quick to pull the item you want
• trickier: If your pocket is full of nails with one bullet in there, (a) you're nuts and (b) pulling a nail out should be quick, pulling a bullet should be slow. I will think about that last one but I suspect it's still easy to work.

[I-am-Erk]

OK so let's create a few variables:

• total_count: total number of items in the pocket. Items in a container count as a single item.
• this_count: Number of items identical to the one you're getting in the pocket
• total_volume: Total volume of items in the pocket
• this_volume: Total volume of items identical to the one you're getting in the pocket
• pocket_size: Total capacity of the pocket
• base_cost: JSON defined base cost of getting things out of the pocket. Should be the minimum time needed to get items in an ideal situation.
• obtain_cost: The final cost of taking the item out.

First, go through a set of if statements to quickly catch common circumstances where the item would be easy to get.

1. If total_items <= 2, obtain_cost = base_cost
2. If total_items <= perception/2, obtain_cost = base_cost
3. If this_count >= total_count/2, obtain_cost = base_cost
4. If this_volume > pocket_volume/2, obtain_cost = base_cost
5. If this_volume >= total_volume/2, obtain_cost = base_cost

If all those are false, ie. this is not the largest item in the container, doesn't occupy half the container, and is not the most numerous item in the container, and there are more than a tiny number of things in the container, then we should calculate a cost to remove the item.

`obtain_cost` = `base_cost` * ( AVG ( 
    [ ( `total_count` - `this_count` ) / `this_count` ) ],
    [ ( `total_volume` - `this_volume` ) / `this_volume` ) ] ), 
    MAX [ `pocket_volume` / `this_volume` ] 
)

The max obtain cost should cap at the time it would take to just dump out and repack the container.

The second max would allow for the possibility that if you're trying to find a USB key in a 60L drum filled with crafting scraps, you might just dump the drum out, find the key, and repack it, because the multiplier for rummaging around for it is going to be impossibly high. However we could leave that out if it's going to be proc expensive, and just let players decide for themselves.

We may want dexterity and perception to play a role in the final speed, if they don't already. We may want a set of proficiencies like quick draw and organized pockets that shorten draw time, perhaps based on the container flags (holster for quickdraw eg)

[actual-nh]

Note the difference between finding something in places that you tried to organize, vs places you dumped stuff for later sorting (e.g., that 60L drum...). Admittedly, for someone with the Disorganized trait, it may not be very different... although I manage to be both good at packing things into limited spaces and disorganized in where I put things.