Prioritize filling partial stockpiles vs empty stockpiles.

[kd7uiy]

It is clear in this gif that providing power is a higher priority than stockpiling, which is good. Filling a partially full stockpile should in my opinion be a higher priority than filling a completely empty. I've had many times with a lot of stockpiles where most of the stockpiles are mostly empty, which seems wrong to me.

Also, consolidating stockpiles as a very low priority job would also be a good thing.

[koosemose]

I think slightly different logic is needed than just prioritising partial stockpiles, that will just mean that if I, for example have Raw iron 3 away, then ice 6 away, and another Raw Iron 20 away, it will as expected get the iron first, but then it will prefer to fill the iron stockpile, meaning I leave the ice that's "right there" to go get the Raw Iron that's 20 away.

That seems clearly wrong.

What we really need is for the stockpiles to form essentially a whole object (or connect to a manager of some kind), so that the stockpiles as a group look for any inventory, and if it's something they already have a partial stack of, designate it to go there, if it's a new stack put it in an empty spot. As long as there are spots completely empty it will ask for anything (on its filter, once that's implemented), once all spots are filled it will ask for anything that it has a partial stack of.

[crafty-geek]

I'm currently working on retooling the InventoryManager and character tasks to fix this behavior. The approach I'm attempting:

(parentheticals can be ignored or cursorily skimmed - not all that pertinent to this particular case, but potentially doable in the same PR due to thematic similarity)

• Manager has both a list of the individual on-the-ground inventories (which include inventories sitting atop a stockpile), AND a list of the stockpiles.
• Stockpiling priorities are untouched - it'd still pick up closer ice over further iron, rather than going far away to fill a partial stockpile inventory

(future feature to consider: when picking up spawned piles of stuff, rather than picking up 3 iron, hauling it back, and then going to pick up the 5 more iron that was next to the first 3, do we implement a small-radius / along-the-path-to-dropoff search for other iron to collect before beelining for the stockpile? So you'd end up getting all 8 iron stocked in one trip?)

• Haul tasks are subdivided into "delivery" tasks and "dropoff" tasks.
  • Delivery: filling machines, supplying builds, etc - behavior unchanged by my work
  • Dropoff: "Find a stockpile to empty current inventory into" sums up the pseudocode

(The character-inventory-dumping function, which at present just sets the character inventory to null, deleting the inventory, will instead task the character with a dropoff. [Should I bother adding a boolean param so that the character can be told to just set their inventory on the closest free [floored?] tile, rather than stockpiling it?])

• Dropoff tasks search through stockpiles only to find N euclidian-closest (aka shortest straight-line path) candidate stockpiles with 1 or more of the held type.
  • If no stockpiles are found with 1 or more, the N euclidian-closest stockpiles with an empty tile (currently synonymous with empty stockpiles, per the paranthetical above) are made the candidates

(Ideally, stockpiles as a furniture could be revamped to be multi-tile entities and not just single-square furnitures with neighbor-aware texturing, so a 3x3 stockpile is represented as one stockpile, rather than 9 that happen to be adjacent. Will likely be critical once stockpile filtering comes along. But, I'm unsure of what files even manage the placement/potential aggregation of stockpiles, so don't know where to start.)

• Once the candidates are found, the shortest-path stockpile is navigated to.
• Upon arrival, as much of the carried load is put in the stockpile as possible; if insufficient room, the inventory on the stockpile is filled to max stack size, and the remainder is treated as a fresh dropoff task.

(Do I even bother trying to multithread-futureproof this for the case where 2 characters are trying to dropoff into the same tile at once? [The case where 2 characters head towards it, and one gets there significantly ahead of the other, is already handled by the "if insufficient room" case; it's the potential instantaneous arrival edge case which becomes hairy in the future - Alice adding 5 ice to a stockpile of 6 ice, at the same instant Bob tries to add 10 ice to the same pile, would customarily end up with either 11 or 16 ice on the pile, and 5 or 10 ice "evaporating"/deleted, rather than the desired 21 ice result.])

This is my first feature/change attempt, and my schedule's in flux, so I am completely uncertain as to how long this would take me; if someone else wants to take ownership of this rework, go ahead. (Letting me know that you're doing so would be appreciated but isn't required.)

(edit: fix bulleted list formatting)
(edit2: wording changes)

[crafty-geek]

(I'd assign this issue to myself if I had the access level / privileges (https://help.github.com/articles/assigning-issues-and-pull-requests-to-other-github-users/). If someone with those creds wants to assign it to me, go right ahead.)