Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
0005818Dwarf FortressDwarf Mode -- Jobs, Generalpublic2012-04-17 13:452014-07-23 13:10
Quietust 
Toady One 
normalminorhave not tried
resolvedfixed 
0.34.07 
0.40.05 
0005818: Jobs using casts, tools, slabs, or food storage containers look too hard for items
Analysis of Dwarf Fortress's data structures for handling jobs and the items they request seems to suggest that jobs which request items of type ORTHOPEDIC_CAST (none?), TOOL (possibly custom reactions), SLAB (engraving memorials?), or the category tag FOOD_STORAGE (brewing drinks) are searching for those items within the global list of all items in the entire fortress instead of the approx. 129 other filtered item lists, potentially adding a significant delay if there are a lot of items in the fortress (and the earliest matching items are near the end of that list).
The very last field in the "job" structure is a vector of "job item" descriptor structures, and within that "job item" structure is a numeric field (immediately between the quantity and the 2nd set of flags) which indicates the item group to search. When the job actually searches for matching items, a separate function translates that numeric field into an offset into the list of item vectors, and that function is missing cases for ORTHOPEDIC_CAST (14), TOOL (124), SLAB (125), and FOOD_STORAGE (127), causing them to default to the first entry (which contains all items).

This was first observed in version 0.31.25 by one of the DFHack developers, and I've confirmed that it still appears to be the case in version 0.34.07 (though the case for BOOK is correctly present).
No tags attached.
Issue History
2012-04-17 13:45QuietustNew Issue
2012-04-17 14:59FootkerchiefDescription Updatedbug_revision_view_page.php?rev_id=8306#r8306
2012-04-17 14:59FootkerchiefAdditional Information Updatedbug_revision_view_page.php?rev_id=8308#r8308
2012-04-17 14:59FootkerchiefNote Added: 0022292
2012-04-18 08:07kwielandNote Added: 0022302
2012-04-18 08:12cephaloNote Added: 0022304
2012-04-18 12:10QuietustNote Added: 0022306
2012-04-18 12:11QuietustNote Edited: 0022306bug_revision_view_page.php?bugnote_id=0022306#r8313
2012-04-18 12:11QuietustNote Edited: 0022306bug_revision_view_page.php?bugnote_id=0022306#r8314
2014-07-23 13:10Toady OneStatusnew => resolved
2014-07-23 13:10Toady OneFixed in Version => Next Version
2014-07-23 13:10Toady OneResolutionopen => fixed
2014-07-23 13:10Toady OneAssigned To => Toady One

Notes
(0022292)
Footkerchief   
2012-04-17 14:59   
Edited the report to remove accidental report/note links.
(0022302)
kwieland   
2012-04-18 08:07   
Q, just so I understand, this leads to a lot of cpu overhead if you have tasks that are utilizing these things (tools, food_storage, etc)?
(0022304)
cephalo   
2012-04-18 08:12   
It sounds like the kind of thing you do when you don't have time research all the special cases that might come up using the filtered lists.
(0022306)
Quietust   
2012-04-18 12:10   
(edited on: 2012-04-18 12:11)
angavrilov deserves most of the credit for finding this one - he's the one who determined the layout of the "job item" structure and located the function that mapped its "group ID" to the master item table offsets, while I just noticed that the "holes" in said mapping function weren't supposed to be there (which I discovered when examining the "setup job items" function while figuring out how to fix bug 0000130 - it made frequent calls to another function to map item types to group IDs, and the Brewing job was choosing a group ID that corresponded to the FOOD_STORAGE hole).