Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ashsaber]

Having this issue for:

Hauling Quires to Libraries in need of writing material.
*The library in question does have chests within its area range.

Corpses/Refuse.

In both the above cases, the items are marked with TSK but after two months in-game nothing happens to them. The Quires keep themselves in the workshop and don't go anywhere. After deconstructing the workshop, the quires stay on the ground and don't go anywhere.

Is the priority for hauling items just really low now, or is there a bigger issue that I need to find a way to work around?

[Iliithid]

Bug reports belong on the tracker

[PatrikLundell]

Bug reports belong on the tracker

Yes, if it is a bug. Most causes of failures to haul stuff are not bugs, however, but caused by something the player has done, in which case the appropriate action is to ask in the forum, rather than making a bug report, typically with too little detail to make it useful.

- The priority of hauling tasks is at the bottom of the priority list (except for old bones from the caverns, which are REALLY urgent).
- Absence of available haulers with the right hauling job type enabled will keep the jobs hanging.
- Burrows restricting the haulers from accessing the destination block them from taking up those jobs.
- Physical access has to be available, so locked doors and channeled away ramps are possible culprits.
- Note that corpses of sapients go into the corpse stockpile ('y'), while other corpses and refuse go into the refuse stockpile, 'r' (with the corpses going into the sub category of corpses).

[Bumber]

There are standing orders settings that can mess with hauling. Not sure if that causes the items to become TSK'd or not.

Try forbidding the items, then unforbidding.

[PatrikLundell]

The standard orders should block the jobs from being generated at all, which means no items should be TSK'd, but yes, it's a common source of issues.

[Ashsaber]

Things I've noticed.
1) If a stockpile takes quires, then all quires will eventually be tasked with pickup orders within seconds, but none of the orders will be executed.
2) Despite not having any quires in its storage, the Library nevertheless registered itself as having quires in its storage.
3) If a stockpile is generated beneath the quires (and is the only one to take Tools, the quire's category) then the quires are left alone.
4) If 3 happens but there is another stockpile that takes quires, then all the quires will again be tasked with pickup orders and none will actually be picked up.
5) Overlapping areas (chair-based areas + managed areas) causes storage devices in libraries to be counted twice.

Attempted Resolution Conditions:
1) No storage areas take Tools, duplicated storage designation.
1Result) All quires TSKed, no quires moved, but all quires are considered to be correctly stored in the library.
2) No storage areas take Tools, no duplicate storage designation.
2Result) All quires TSKed, no quires moved, but all quires are considered to be correctly stored in the library.
3) Storage area drawn underneath Quires, duplicated storage designation.
3Result) Same as 1 and 2.
4) Storage area drawn underneath Quires, no duplicated storage designation.
4Result) Same as 1, 2, and 3, Though this did work once.
Ex) Take quires to trade post.
5Result) Works fine.

My Inferences
Uh...too many moving parts. It's entirely possible that the reason why this is happening is because my fort has visitors, and they're being allowed to take hauling jobs for those quires (but not actually do them), since for my earlier fortresses in 47.01 to 47.03 did not have visitors to cause this problem.
Reason: I've seen bards move cups and I'm extrapolating rather hard from there.

[anewaname]

Similar bug that was closed.

Do you have a save with the items TSK'ed?

[Ashsaber]

I do. What do I do with it?

[anewaname]

I think the right series of steps are to:
 - load the save and get the view centered on the location where the TSK'd item is, then save it. So when the tester loads it, they do not need to search for it.
 - post the save to DFFD
 - post a new bug report on mantis, including a comment on the issue, the http link to the old bug, the http link to the dffd save, and the http link to this forum thread.

But, it would be good to get more feedback from others who posted in this thread.

[Ashsaber]

Thank you, I will do that.

It's not as if this is a crippling issue, and I'm pretty sure I can play around it if I told my dudes to, y'know, do less things at once, but it'd be nice to have it addressed at some point.