Fix comment for job->item_subtype

[myk002]

While implementing the --hauler-type param for the prioritize script, I noticed that the job->item_subtype field, which is tagged as being a hauler_type enum, did not match up with the type of item being hauled. I fixed this enum based on observation of which enum values resulted in which types of items were hauled.

I was unabled to verify the "Bin" enum. I could not get any hauling jobs of this type to be generated in my fort, even when explicitly building bins and enabling bins for stockpiles.

[lethosor]

This is an interesting one.

• The only place (supposedly) where hauler_type is used as a value is here (edit: this is what you identified in your PR description above). This is used by labormanager here as a unit_labor, and your change would cause unit_labors 1-8 to line up with hauler_types 1-8. Bin (9 with your change) does not correspond to a HAUL_ unit_labor (where 9 = CLEAN).
• hauler_type is also used as an index-enum in stockpile, but @ab9rf reports that this enum was inaccurate at the time labormanager was written, so indices were hardcoded here. Note that "bin" corresponded to 4 at the time.

My guess is that Toady might have changed hauler_type at some point to be consistent with unit_labor, but I don't know for sure, or when.

[ab9rf]

This would break the indexing of world.stockpiles.num_jobs and world.stockpiles.num_haulers. The current enum is correct; I tested this extensively over the course of years developing labormanager, and just spot-checked it in a mature fort.

hauler_type is also used as an index-enum in stockpile, but @ab9rf reports that this enum was inaccurate at the time labormanager was written, so indices were hardcoded here. Note that "bin" corresponded to 4 at the time.

No, the existing enum is correct. I originally thought it was wrong, but it was more because I didn't understand how it was being used when I initially wrote that, and haven't gone back to update the code to reflect lessons learned since.

There is no direct correspondence between hauling type and labors. The labor for a hauling job is determined in a fairly complicated way: see labormanager job mapping source for more info.

[ab9rf]

This is wrong, at least with respect to world.stockpiles.num_haulers, and I must recommend against this PR without more evidence.

I just tested on a mature fort by clearing all hauling labors on everyone. This resulted in world.stockpiles.num_haulers going to all zero. Then, reenabling food hauling on everyone resulted in world.stockpiles.num_haulers[Food] going to 194 while the others remained zero.

If the enum were wrong, some other field would have gone up. Therefore, the existing enum is correct, at least for food, but this change would change the value of the Food enum.

I must therefore object.

[lethosor]

Thinking over it a bit, I suspect the comment for job.item_subtype is wrong, and this field is actually a unit_labor when type == StoreItemInStockpile. I'm not sure yet what implications this would have for DFHack/scripts#327, though.

[myk002]

ack. I'll fix the comment and update DFHack/scripts#327 to interpret the field as a unit_labor. Thanks!

[myk002]

changes reverted; misleading comment made less misleading

[ab9rf]

My research suggests that we should rename Bin to something else. Specifically, StoreItemInHospital jobs increment world.stockpile.num_jobs[Bin], even though a "store in hospital" job never result in anything being actually stored in a bin.

        pjVar38 = job::create();
        piVar42 = local_440;
        pjVar38->job_type = StoreItemInHospital;
...
        world.stockpile.num_jobs.Any = world.stockpile.num_jobs.Any + 1;
        world.stockpile.num_jobs.Bin = world.stockpile.num_jobs.Bin + 1;