Mantis Bug Tracker
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005818Dwarf FortressDwarf Mode -- Jobs, Generalpublic2012-04-17 13:452014-07-23 13:10
ReporterQuietust 
Assigned ToToady One 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version0.34.07 
Target VersionFixed in Version0.40.05 
Summary0005818: Jobs using casts, tools, slabs, or food storage containers look too hard for items
DescriptionAnalysis 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).
Additional InformationThe 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).
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0022292)
Footkerchief (manager)
2012-04-17 14:59

 Edited the report to remove accidental report/note links.
(0022302)
kwieland (reporter)
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 (reporter)
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 (reporter)
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).

- Issue History
Date Modified Username Field Change
2012-04-17 13:45 Quietust New Issue
2012-04-17 14:59 Footkerchief Description Updated View Revisions
2012-04-17 14:59 Footkerchief Additional Information Updated View Revisions
2012-04-17 14:59 Footkerchief Note Added: 0022292
2012-04-18 08:07 kwieland Note Added: 0022302
2012-04-18 08:12 cephalo Note Added: 0022304
2012-04-18 12:10 Quietust Note Added: 0022306
2012-04-18 12:11 Quietust Note Edited: 0022306 View Revisions
2012-04-18 12:11 Quietust Note Edited: 0022306 View Revisions
2014-07-23 13:10 Toady One Status new => resolved
2014-07-23 13:10 Toady One Fixed in Version => Next Version
2014-07-23 13:10 Toady One Resolution open => fixed
2014-07-23 13:10 Toady One Assigned To => Toady One

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker