View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005818 | Dwarf Fortress | Dwarf Mode -- Jobs, General | public | 2012-04-17 13:45 | 2014-07-23 13:10 |
| Reporter | Quietust | Assigned To | Toady One | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 0.34.07 | ||||
| Fixed in Version | 0.40.05 | ||||
| Summary | 0005818: Jobs using casts, tools, slabs, or food storage containers look too hard for items | ||||
| Description | 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). | ||||
| Additional Information | 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). | ||||
| Tags | No tags attached. | ||||
|
|
Edited the report to remove accidental report/note links. |
|
|
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)? |
|
|
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. |
|
|
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). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-04-17 13:45 | Quietust | New Issue | |
| 2012-04-17 14:59 |
|
Description Updated | |
| 2012-04-17 14:59 |
|
Additional Information Updated | |
| 2012-04-17 14:59 |
|
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 | |
| 2012-04-18 12:11 | Quietust | Note Edited: 0022306 | |
| 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 |
