Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001519Dwarf FortressDwarf Mode -- Jobs, Haulingpublic2010-04-25 06:192011-03-23 13:01
Assigned ToToady One 
PrioritylowSeverityminorReproducibilityunable to reproduce
PlatformwindowsOSxpOS Versionpro sp3
Product Version0.31.03 
Target VersionFixed in Version0.31.22 
Summary0001519: Bars not being stockpiled because haulers are waiting to haul inaccessible items outside the fortress
DescriptionI was hesitant about posting this because issues like this seem to always be due to user error. I have tested everything I can think of however and I apologise in advance if I missed something.

The bars in my smelter are not getting moved to the bar stockpile. I created a new stockpile, making a total of 3 all with space on them, all of them unmodified bar/block piles. I destroyed one of the smelters but the bars on the floor dont move. I made a stockpile right next to them. I have eliminated burrows as best I can as a culprit. The store item job is not on the jobs list. I have plenty of idle dwarves. Other stockpiling in the same area occurs without issue.
Steps To ReproduceLoad up the save. It seems like if this is a bug it is very rare and random. No repeatability.
Additional InformationSave file: [^]
Tagsidle, item hauling, pathing
Attached Files

- Relationships
related to 0002407resolvedFootkerchief Dwarves don't haul metal ore to stockpile anymore 
child of 0001173resolvedToady One Dwarves refuse to haul accessible items until they've hauled ones that are currently inaccessible 

-  Notes
drunken (reporter)
2010-04-25 06:26

i rebuilt the smelter and the bars were moved out of the way without a problem
Footkerchief (manager)
2010-04-25 09:32

What types of bars? Do you have any burrows set up?
drunken (reporter)
2010-04-25 21:09

several types of metal bars, bismithunite, iron, nickel, gold etc. I have one burrow set up, both the bars and the stockpile are within it. No dwarf is assigned to the burrow and my civ isnt activated to it either.
derigo (reporter)
2010-04-25 22:00

Almost certainly user error. ;p

I'll take a look at your save when it finishes downloading.
derigo (reporter)
2010-04-25 23:49
edited on: 2010-04-26 01:16

Theres something here thats a bug. While I'm figuring out whats going on(this will involve me defeating your siege, so itll take a lil while lol), are you certain you're playing with the most recent version? This is behaving like some sort of pathing issue.


Oooook this is kind of hard to explain and wierd, but its definitely a bug. My only caveat is that if the OP was not playing this fort in the current version, this problem may simply be 0000018. I have no idea how old version saves with existing pathing problems might behave if loaded into a current version engine. But this seems like it could be that. In that case, I've wasted a bunch of time. ;p If that is not the case, then this is a new, significant pathing bug of some kind.

First of all, current fort status is complicated. There's a bunch going on:
-This is a fairly far along fort, population is 132
-very good fps for such a mature fort, no major waterworks or lavaworks slowing things down
-there's a mass grave just outside containing about 50 dwarf corpses, indicating an even larger population although many of those corpses may be traders because:
-There's what looks like the remains of one or more caravans near the ambushers just outside.
-There are corpses and their belongings strewn all over the place outside, lots and lots of stuff that needs hauling
-There's 3 or 4 ambush gob squad outside, only 1 of which is revealed, the rest are sneaking. Every attempt by me to brute force kill this invasion(recruit entire population and charge) was shrugged off by the gobs.
-There's a small resus macaque invasion running around stealing bits of armor and weapons from the dead on the field.
-All of this FUN stuff is scary but shouldn't be an issue because the entrance is blocked by a retracting bridge over a pit, which is retracted

That being said 90% of the population is idle, have all hauling labors enabled, orders menu orders are not unusual, no wierd access restrictions with doors or paths or anything like that, burrows are unrelated(I double checked by deleting the one burrow he has), and stockpiles are set up properly. And yet no one is hauling any bars. What a little fiddling around showed me is that in fact, no one is hauling anything that uses the 'Item Hauling' job. Foods, refuse, corpses, animals, stone, wood, and furniture all haul correctly, but bars won't get hauled. Nor clothes, weapons, or any finished goods.

The first thing I figured out was that unblocking the entrance fixes the issue. This made me suspect the OP is not using the current version of the game, as it sounds like a crappy pathing issue.

However, the next thing I figured out was that area forbidding everything on the ground level outside also fixes the issue. My game bogs down as all the haulers reacquire jobs for a second.

Furthermore, simply unblocking the entrance only sort of fixes the problem. Initially every single dwarf available runs outside and grabs stuff to bring back in. Not one of them goes inside to do any hauling there until they've made a few trips outside first, despite there being plenty of hauling jobs available there. With 100+ dwarves in play, this is very unlikely to be random chance. They NEED to do a hauling job outside before they can contemplate the inside jobs.

My conclusion is that either
-the OP is using an old version of the game and this is just 0000018 made even wonkier by playing the save on the new engine.


-This is entirely new pathing bug having to do with item hauling prioritization getting messed up by items being unpathable. The dwarves have decided that they MUST haul the items outside, and will do no other item hauling jobs until they do. Whats weird is that they're not job cancel spamming, or refusing to do other jobs, they just won't haul items.

drunken (reporter)
2010-04-26 20:51

Thanks for putting in so much time on this. There may be a way i can test when I made the world and the save. Are there any files that are created at worldgen or fort start that are read but not written to? This would mean the last modified date could be compared to the release dates. I didn't make a map on worldgen and I don't think this is the first fort in this world.
Footkerchief (manager)
2010-04-26 20:59
edited on: 2010-04-26 23:51

derigo: 0000018 was characterized by the problem (briefly) disappearing after a save/load, so it's not that.

Based on your description, it sounds like 0001173, which we're still trying to conceptualize. Thanks for investigating -- if it is 0001137, that's the most thorough report we've gotten on it so far.

drunken (reporter)
2010-04-26 21:26

I just went ahead and investigated all the modified/created times. It seems the world was generated on the 3rd, which means 31.01. It is harder to tell when the fort was created. Some of the raw files were created on the 8th (6 am though so before the release) most of save/region 2/objects/ files were created on the 9th so I think that is a good indicator that the fort was created just after the release.
derigo (reporter)
2010-04-26 23:32

Unf. The fact that this world was generated under a different engine makes this a very ambiguous situation. Saves should theoretically be cross version compatible, but Toady is still trying to stabilize some extremely basic things about this release, so that may or may not be true at all at the moment. And only Toady can really tell, and only by looking very closely at what's going on. I would throw this bug report out if I were him because of the ambiguousness.

Footkerchief, I looked around later and saw 0001173, which I hadn't seen before. That is very very much what it seemed like to me, only with items instead of refuse or dump designated objects. I agree it didn't feel like 0000018.
drunken (reporter)
2010-04-27 01:05

Thanks for the workaround, forbidding the dead caravans fixed the problem. My guess is that both bugs are caused by a job buffer of some kind. This is already set to low priority so please don't mark it resolved even though there is no real reason to bother toady with it in the near future when he could be doing *cool* stuff. Is there a status that denotes that the bug is closed but not solved?
Footkerchief (manager)
2010-04-27 02:02

I'm not planning to close it at all -- I'm going to leave it open so that Toady sees the additional info here.
Quietust (reporter)
2010-04-30 08:16

This sounds disturbingly similar to a problem that existed back in 40d (which I encountered by placing a stone stockpile in my quarry after locking it off, then observing that nobody was hauling ore to my stockpiles).
thranguy (reporter)
2010-05-03 10:37

I recently had a similar problem with dwarfs not hauling furniture. Looking at this bug, I think that it might have to do with my missing anvil (I had a wagon-wrecking mountainside embark (despite there being plenty of flat ground elsewhere in the map) and didn't see the anvil anywhere in the wreckage...guess the dwarves couldn't find it either.
(Abandoned the fort so can't provide save)

- Issue History
Date Modified Username Field Change
2010-04-25 06:19 drunken New Issue
2010-04-25 06:26 drunken Note Added: 0004979
2010-04-25 09:32 Footkerchief Note Added: 0004999
2010-04-25 09:32 Footkerchief Issue Monitored: Footkerchief
2010-04-25 21:09 drunken Note Added: 0005074
2010-04-25 22:00 derigo Note Added: 0005081
2010-04-25 23:49 derigo Note Added: 0005096
2010-04-25 23:50 derigo Note Edited: 0005096 View Revisions
2010-04-26 00:05 derigo Issue Monitored: derigo
2010-04-26 01:14 derigo Note Edited: 0005096 View Revisions
2010-04-26 01:16 derigo Note Edited: 0005096 View Revisions
2010-04-26 02:26 derigo Tag Attached: pathing
2010-04-26 02:26 derigo Tag Attached: item hauling
2010-04-26 02:26 derigo Tag Attached: idle
2010-04-26 20:51 drunken Note Added: 0005267
2010-04-26 20:59 Footkerchief Note Added: 0005272
2010-04-26 20:59 Footkerchief Relationship added child of 0001267
2010-04-26 21:00 Footkerchief Summary Bars not being stockpiled => Bars not being stockpiled because haulers are waiting to haul inaccessible items outside the fortress
2010-04-26 21:06 Footkerchief Relationship deleted child of 0001267
2010-04-26 21:06 Footkerchief Relationship added child of 0001173
2010-04-26 21:06 Footkerchief Note Edited: 0005272 View Revisions
2010-04-26 21:26 drunken Note Added: 0005277
2010-04-26 23:32 derigo Note Added: 0005291
2010-04-26 23:51 Footkerchief Note Edited: 0005272 View Revisions
2010-04-27 01:05 drunken Note Added: 0005303
2010-04-27 02:02 Footkerchief Note Added: 0005311
2010-04-30 08:16 Quietust Note Added: 0005748
2010-05-03 10:37 thranguy Note Added: 0006010
2010-07-04 10:29 Footkerchief Relationship added related to 0002407
2011-03-09 04:03 Toady One Status new => resolved
2011-03-09 04:03 Toady One Fixed in Version => 0.31.22
2011-03-09 04:03 Toady One Resolution open => fixed
2011-03-09 04:03 Toady One Assigned To => Toady One
2011-03-23 13:01 Footkerchief Resolution fixed => duplicate

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker