Opinionated Cleanup

[simplyWiri]

This is a series of changes ontop of my base changes - which are a bit more opinionated and try to make the code simpler & easier to reason about (for newcomers).

[simplyWiri]

I completely deleted this code, because it didn't make much sense to me. TargetB is not where anything is guaranteed to be dropped off at - the Unload job driver owns that responsibility - maintaining reservations seems moot, if that was a desired feature - wouldn't you do this in the Unload JobDriver?

[simplyWiri]

I think this was load-bearing, I've noticed a few edge cases where pawns are over-hauling when there is not enough space.

[simplyWiri]

Mm. I think this is a more general issue:

When we use a storage building, we store a (StoreTarget, CellAllocation) pair. Where CellAllocation is presumed to be for a particular item. This means we store a int capacity. This capacity is only correct for a particular item, not any item.

This means, for example - if we haul leather, to a cell with 225 capacity (3x free cells) - and we only have, i.e. 10 leather. We would then see 215 free slots.

If we then went to haul a bunch of single-slot items, i.e. apparel. We could attempt to haul ~215 individual apparel items into this slot - when we should only be able to store 2. Because fundamentally we are storing things by cell.

[simplyWiri]

I feel like JobOnThing can be refactored into something which looks like this:

public Job JobOnThing(Pawn pawn, Thing thing, bool forced = false)
{
    if (InvalidHaulTarget(pawn, thing, forced))
    {
        return null; // Return a default job in this case
    }

    var job = ...;
    var haulables = new List<Thing>(ThingsPotentiallyNeedingHauling()).SortedBy(pred: DistanceTo(thing.Cell));
    Dict<StorageLocation, StoredThings> storageLocations; // Map of existing targets for hauling things to

    // Checks encumberance & pawn inventory weight - truncates the `stackCount` of `thing` if it won't fit in
    // the pawns inventory.
    while ((thing = CouldHaul(pawn, thing) != null)
    {
        var haulDestination = FindHaulDestination(pawn, thing, storageLocations);
        if (haulDestination is not null)
        {
            // Does a few things:
            //  1. Adds to `job.TargetQueueA, job.TargetQueueB, job.targetCount`
            //  2. Tracks the added encumberance to the pawn
            //  3. Adds tracking information to `storageLocations`
            // if the destination can't handle all of `thing` - the un-hauled remainder is set - otherwise it is null
            thing = HaulToDestination(pawn, thing, haulDestination, storageLocations);
        }

        if (thing is null) {
            thing = PopNextClosest(pawn, haulables);
        }
    }

    return job;
}

Some notes:

• Minor improvement could be re-sorting haulables for each consecutive thing
• Maybe better structured data for pawn encumberance to avoid some Stat calls for mass. Because its mostly memoized I'm not sure its a huge concern - but its a point of improvemnet
• Types are vague in this sketch, some things should be a ThingCount vs a Thing.

However - a few reservations:

• I don't understand bits like:

				if (HaulToHopperJob(thing, targetCell, map))
				{
					return HaulAIUtility.HaulToStorageJob(pawn, thing, forced);
				}

given this is inconsistently applied when we first look for a thing to haul - but not the consecutive things we pick up (is this mixed requirements for the first hauled item, vs the next ones we gather?).

[simplyWiri]

Fake news on the performance - it also broke things :(