Print

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

[falcn]

Update:
This is known issue, there is a proposed fix
https://github.com/DFHack/dfhack/issues/487


----------------------------------------------------------------------------------
I'm not a DF guru, but I had a dozen of successful playthroughs with 0.34.

I came back for 0.40.24, but can't make it past first year.
The game is basically unplayable, as all workshops randomly get stuck, and eventually production of everything drops to zero.
The only way to make them "unstuck" that I found is to deconstruct workshop and place it again.

Here is my save file (Phoebus tileset).

Screenshots:

Spoiler (click to show/hide)

I have "Brew drink" job queued in the Brewery, I have tons of empty barrels and raw materials, but my dedicated brewer (and my second part-time brewer) both sit with "No job" status.
Brewery is reachable, it worked before.

Same result with or without DFhack.

Is this some stupid mistake that I did?
Is this a known bug?
Is there a workaround?

[utunnels]

What if you build another still, in another place?

[ArKFallen]

Have you tried the 'n' "Do task now" modifier to your brewing?

[NW_Kohaku]

DFFD exists for a reason, use it instead of some shifty download site like sendspace. 

[falcn]

What if you build another still, in another place?

Second still works as expected. Brewer starts brewing when I add task.
Removing second Still doesn't make first one unstuck.

Have you tried the 'n' "Do task now" modifier to your brewing?

Yes, it did nothing.
Workshop profile is "allow all".

DFFD exists for a reason, use it instead of some shifty download site like sendspace. 

Also, pay attention to impassible tiles on a workshop. You're nearly walling off your kitchen.

This still worked for 10 months before it became glitched.
Since I embarked, same glitch happened to Mason's Workshop and Carpenter's Workshop. I demolish/rebuilt them. Seems like it happens randomly.

[NW_Kohaku]

Dwarves have no bedrooms, and only 8 beds for 24 dwarves in an open area that is also your trade depot and your dining room (only three tables) and no traps or even doors to keep anything out, with no military either.  (Oh boy if sieges and ambushes still existed, would THIS fort be Fun...)   

You have no bookkeeper, so I can't trace the stocks.  (No, wait, there is a bookkeeper, but there hasn't been any room or desk assigned, so no work is being done...)

Meanwhile, instead of doing anything vital to your survival, you're excavating the entire mountain to produce a hundred times more ore than you can actually use.   You don't even appear to have a smelter. 

You DO, however, have time to make a craftdwarf workshop that only makes things from horn or making bone crafts.

In general, you have hauleritis.  Common among new players. You're playing around with unnecessary things "because you want your dwarves to be busy" instead of assigning them more useful jobs.  This is creating a logistical nightmare, and leaving your fortress utterly exposed and undefended. 

Anyway, going to the relatively more immediate problem, as soon as I punched in a new order to brew from fruit, it immediately did so.  Then it declared in an announcement that it could not produce drink.  I'm not sure why, you have 15 barrels looking at the furniture stockpile (no stocks menu, so I can't be sure, but nothing seems to be in the carpentery workshops) and there are cranberries and such sitting in barrels. 

I'm going to guess this is one of those bugs with DFHack and workflow, where I've heard that if you have too much crap lying around, it will cause hiccups where jobs are ignored. 

I'd suggest not using the repeat button, and either using the manager, or else using the more advanced workflow features that let you set it to "make more booze when below 100".

[falcn]

Anyway, going to the relatively more immediate problem, as soon as I punched in a new order to brew from fruit, it immediately did so.  Then it declared in an announcement that it could not produce drink.  I'm not sure why, you have 15 barrels looking at the furniture stockpile (no stocks menu, so I can't be sure, but nothing seems to be in the carpentery workshops) and there are cranberries and such sitting in barrels. 

I'm going to guess this is one of those bugs with DFHack and workflow, where I've heard that if you have too much crap lying around, it will cause hiccups where jobs are ignored. 

I'd suggest not using the repeat button, and either using the manager, or else using the more advanced workflow features that let you set it to "make more booze when below 100".

Yeah, just noticed that deleting Brew drink [R] and recreating same task again fixes the workshop, there is no need to rebuild it.

But this is of little consolation, because I use workflow manager to keep my stocks at reasonable level, and tasks get stuck on autoresume/low stock.
Manual [R] tasks stuck too after a few months of production.

I'll try to create new world/embark and see if it helps.

[NW_Kohaku]

I would suggest not using repeat at all. 

Use manager (u -> m, and requires manager noble with a desk) or use workflow in DFHack.

You need to build a room for a bookkeeper or the manager to do the work (these can be the same dwarf), which requires only that you build a lone table and chair away from everything else (preferably in a 2x1 room with a door) where the chair is designated a room and assigned to the bookkeeper. (q->point at chair-> r -> enter -> a -> select your bookkeeper/manager)

You should also seriously think about defenses.  At least throw out traps.  Preferably, have more than one entrance spaced far apart, with drawbridges linked to levers that you can use to seal off the entrances, and put traps in the intervening space.  Do not put your trade depot in your dining room.  You can leave it at the entrance early on, and build a more fortified area later, but it's just a giant security liability at the start.  Do not make giant hallways that require your dwarves to walk 50 tiles to get from the beds to the workshops, and another 50 tiles to go from the workshop to the stockpile. 

Also, build individual rooms for each dwarf and let them have their own bed, and preferably a door, so they can get happy thoughts admiring their door. 

For that matter make doors.  Make doors forever.  Put doors in every conceivable spot.  Make a drawbridge to block off traffic, then put lockable doors in front and behind the drawbridge to make sure nobody is standing on the bridge when it rises.  Put doors between sections of the fortress to make sure tantruming dwarves can't reach peaceful dwarves.  Put hatches on stairwells, they're just vertical doors.  If a werebeast comes rampaging, they'll probably turn back into a normal human by the time they've torn down your third door, so make sure you have FOUR doors.  (Plus a cage trap.)

You should also have either an elaborate engineering solution to anything like an FB coming to attack or else a solid military.  A military might be easier.  Start training from at least the second or third migrant waves in your first year.  Military takes time to train, especially the first batch, so train early. 

[infrequentLurker]

"This looks like a known about but vaguely understood bug with workflow when there are lots of things.  As a proposed solution, use workflow more."
 

If this is the same bug (and the symptoms make is seem like it would be), periodically canceling and re giving tasks helps.  If it gets too bogged down, try forbidding large chunks (or even all for a step or two) of the clutter, then reclaiming it as you're ready to deal with it.  Less clutter that dorfs can think about, smaller chance of workflow error.

[NW_Kohaku]

"This looks like a known about but vaguely understood bug with workflow when there are lots of things.  As a proposed solution, use workflow more."
 

If this is the same bug (and the symptoms make is seem like it would be), periodically canceling and re giving tasks helps.  If it gets too bogged down, try forbidding large chunks (or even all for a step or two) of the clutter, then reclaiming it as you're ready to deal with it.  Less clutter that dorfs can think about, smaller chance of workflow error.

Well, the suggestion is either not use workflow, or use it more. 

Using workflow more would help, because it should be periodical, rather than having an order linger forever, such that it falls completely to the bottom of the heap. 

Turning workflow off, if you're not using it, obviates this bug entirely. 

[Danetta]

What if you build another still, in another place?

Man, answer me please via pm. Please.

[infrequentLurker]

Ok, ok - no offense meant, and I apologise for any I might've caused.  On a less snarky note, this is the third or fourth thread I've seen about dwarves refusing a task until it is cancelled and re given.   From what I have gathered, when there are many ongoing tasks in the game (usually mass hauling, little else makes enough jobs), workflow tries to add tasks as usual, and does tack them on to the workshop successfully, but somehow fails to make dwarf job hunting notice the new job.  This locks up the workshop when the bad task hits the top, as it can't be cleared.

From the thread where the player couldn't get dwarves to move eggs, we can see that this behavior can sometimes extend out to hauling somehow, causing any new hauling task to get bound up under the bad one.  He forbid everything on the map, canceling all haul jobs including the bad one(s), and his dwarvws moved the eggs on reclaim.

I am completely unsure how workflow works under the hood, but it seems to me like too many tasks across the fort = workflow issues.  If you have workflow issues, cancel any bound up orders you can identify, re-place those orders because you obviously need them done, and forbid a majority of your clutter, reclaiming to move it in chunks instead of as a single mass of haul orders.  If it hits hauling somehow, or workshops get stuck even after re-ordering, try forbidding your entire map for 1 step, as there may be a bad haul order locking up other haul jobs up to and including haul to the workshop (see: egg thread stuff.  May edit a link in here later).  After at least 1 step (so all jobs including items get cancelled) reclaim anything of value/use (or just reclaim the whole map and then re-forbid clutter) and keep an eye on how much hauling you cause afterwords.

[falcn]

I would suggest not using repeat at all. 
...
use workflow in DFHack.

Unfortunately, workflow requires task to be set to [R] to work.

As for the design, all your points are valid. I lost 3 hours of planning and designating to crash on save, and just brute-forced industry after that to see what's new in 0.40.

[falcn]

"This looks like a known about but vaguely understood bug with workflow when there are lots of things.  As a proposed solution, use workflow more."
 

If this is the same bug (and the symptoms make is seem like it would be), periodically canceling and re giving tasks helps.  If it gets too bogged down, try forbidding large chunks (or even all for a step or two) of the clutter, then reclaiming it as you're ready to deal with it.  Less clutter that dorfs can think about, smaller chance of workflow error.

Well, the suggestion is either not use workflow, or use it more. 

Using workflow more would help, because it should be periodical, rather than having an order linger forever, such that it falls completely to the bottom of the heap. 

Turning workflow off, if you're not using it, obviates this bug entirely.

This might be not dfhack/workflow bug, but DF bug.
Workflow, if I understand correctly, doesn't give any orders itself, it just sets and removes [ S ] flag for controlled tasks using dfhack API.
In that regard it is working absolutely fine.

The problem is that sometimes unpaused task don't get dwarves assigned for it.
Running my save without dfhack didn't fix the problem - what seems like an active task still considered inactive by the game engine.

Looks like a DF problem to me, not dfhack (unless dfhack damaged ingame array for this task by writing stuff to incorrect address. which it might be doing. Yep, this might be the case)

My gut feeling tells me that workflow is not guilty, it's either DF or DFhack, and probably DFhack.

And I don't think it's connected to hauling or amount of stuff laying around.
The workaround is to erase all in-memory data for the stuck task and re-create it from scratch.

[milo christiansen]

I use workflow (or at least I did) to prevent (R) jobs from being removed. In 40.x I have has this problem consistently whenever workflow is enabled anytime workflow readds a canceled job. Disabling workflow solved the problem completely.