0011912: Cancellation of hauling job may leave hauled item(s) in inventory in a bugged state - Dwarf Fortress Bug Tracker

ID	Project	Category	View Status	Date Submitted	Last Update

0011912	Dwarf Fortress	Dwarf Mode -- Jobs, Hauling	public	2022-09-07 12:03	2022-09-07 12:13

Reporter	Alex321	Assigned To
Priority	normal	Severity	minor	Reproducibility	sometimes
Status	new	Resolution	open
Platform	Windows	OS	Windows 10	OS Version	64 bit
Product Version	0.47.05

Summary	0011912: Cancellation of hauling job may leave hauled item(s) in inventory in a bugged state
Description	The item(s) continue to stay in the unit's inventory in Hauled mode, although the unit's job has changed to another job/activity or to no job. Leads to several variants of unwanted behavior and problems: stuck in place for long time, massive cancellation spam, needlessly carrying heavy items (details in additional information)
Steps To Reproduce	Cause cancellation of active hauling jobs with hauled items in inventory, easiest to do by burrows that make dropoff inaccessible.
Additional Information	From some dfhack scripting, I've found that the affected items will no longer have in_job flag, which sets them apart from hauled items that belong to valid hauling jobs. So this becomes a useful criteria for finding such bugged units. The easiest trigger for this can be burrows. But there are more ways: for example, if the hauling job consists of storing items into a specific bin, I've seen at least once that setting Forbid on the involved bin can (but not always will) trigger this. There are multiple variants of unwanted/buggy behavior that follow, like Subcase 1: The unit cancels the hauling job, then gets stuck in place with no job, holding the items in inventory as Hauled. The unit can stay stuck for multiple days, constantly spamming job cancellation message. Apparently, in this case, the items stuck in inventory force the unit to needlessly retry/cancel the job, over and over again. It seems that eventually units may get unstuck, drop the items and go on to some other activities. For some this happens faster, others stay like this for days and I don't have the patience to wait and see if every one eventually gets unstuck. At least, in this subcase they will finally get rid of the item and move on if set Forbid on all affected inventory item(s). Subcase 2: the unit cancels the hauling job and switches to some other non-hauling activity, while still holding these items as Hauled. In my tests, this was often moving to an individual drill. Once in this state, they appear to ignore if Forbid is set on any of the items they are stuck with. It seems they usually drop the items after they are done with the next activity, thus fixing themselves, but it may take a long time as they may be super slow and heavy, and cannot be forced to drop it by Forbid. Subcase 3: I've also seen a unit cancel a multiple item hauling job (to bin) then switch to a valid-looking single item hauling job with a different destination instead, while the rest of the items from the previous job still stayed in its inventory as Hauled. When doing so, one of the items had in_job flag, others did not - setting Forbid on those other items is ignored, unless it's also set on the single valid item with in_job. There are differences in these scenarios, but lingering inventory items in Hauled mode and without in_job flag are the common thread in all of this wonky behavior. Also should be noted, that this does not reproduce 100%: in a lot of cases the unit drops the items instantly and moves on to some valid activity. So there must be some other triggers involved. However, it is still reproducible easily enough, just not every single time for every hauler. To illustrate the frequency and scope of it, here are some tests from the fortress I am currently playing, with about 150 adult dwarves. I'm setting up a burrow called "test" which will be used to restrict dwarves carrying Hauled items (selection via the lua script). The burrow includes bedrooms, temples, drill area (barracks), dining area, and a small area in which I've set up two Stone stockpiles as Give To/Take From (all this is supposed to give dwarves valid activities to do, so that they are not just stuck in place because they've got nothing they could potentially do). Most of the stockpiles are excluded from the burrow, so as to induce mass cancellations. Iteration 1 (DFHack console dump with full details in bugtest_console_dump_1.txt) In this one, I targeted dwarves in the middle of Hauling jobs with multiple Hauled items (i.e. To Bin etc). Dwarves fitting criteria added to a restrictive 'test' burrow - at the moment of starting test there were 7. 7 of 7 briefly entered the state characteristic of bugged units (inventory items in Hauled mode, no in_job flag), but within some few ticks 3 of 7 were able to fix themselves and move on. The remaining 4 are the ones that I would consider seriously affected by the bug. 3 of them went to practice Individual Drills while still weighted down by all the items (subcase 2 above). 1 got stuck in place (subcase 1) and would keep standing for days, while, theoretically, there is a reachable stone stockpile to haul and probably other activities to do. Only after manually forbidding all the Hauled items was he able to drop them, get moving and finally go haul those stones stockpiles in the 'test' burrow. Iteration 2 (DFHack console dump with full details in bugtest_console_dump_2.txt) In this one, I restart DF to the same state before Iteration 1. All dwarves with Hauled items are selected for 'test' burrow. Of 42 active haulers with Hauled items in inventory, 32 initially get affected. Again, some fix themselves relatively quickly, some go to drills and what not with all the items in tow, some remain stuck in place and spam cancellations. As can be seen in detailed dump, at least one eventually (maybe a thousand ticks later) went the relatively rare Subcase 3 scenario. Even about 2 days of ticks later, there were still 7 of them affected, several of them stuck in place and spamming cancellations (the most annoying scenario). console log from Iteration 2 ends with a big dump of all potentially relevant data of the 7 dwarves that I knew how to extract in lua (bugtest -dumpall) Hopefully it all shows how common this is. It's not only in some kind of contrived test scenario either: in normal playthrough, I was running into this problem all the time, particularly during caravan trading, when I like to use burrows and reorganize stockpiles to micromanage all the hauling and stuff. If I am able to, I will attach these files: 2 screenshots - just a typical affected dwarf, going to the combat drill with all the items from his cancelled Store In Bin job bugtest.lua : DFHack script used for my tests, in hope that it might be useful for testing/reproducing bugtest_console_dump_1.txt: outputs from iteration 1 bugtest_console_dump_2.txt: outputs from iteration 2, with info dump for the 7 longest affected dwarves in the end Game package used: PyLNP 0.14a (DF 0.47.05). FWIW, seems to work the same in vanilla (transferring the save).
Tags	hauling, inventory, job cancellation

Date Modified	Username	Field	Change
2022-09-07 12:03	Alex321	New Issue
2022-09-07 12:04	Alex321	Tag Attached: hauling
2022-09-07 12:04	Alex321	Tag Attached: inventory
2022-09-07 12:04	Alex321	Tag Attached: job cancellation
2022-09-07 12:13	Alex321	Note Added: 0041317