Print

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

[BNDR]

For a long time I've played 40.19 on my notebook, and I finally had enough of lagging so I installed DF version 40.24 on my main machine. Because DF was or is not yet fully compatible to the newest DF version innit.

Ever since then I noticed weird behaviour.

Dwarves don't keep working as fluidly. If I set a job on REPEAT, they go to the meeting hall, rest there for 5-20 seconds and then start the job again, rinse and repeat. needless to say, esp. brewing is very very slow.

Workshops get hung up. Sometimes I add a work order, and Ctrl+D duplicate until its full. Chances are, the dwarves dont ever touch the workshop, until i CLEAR the list and re-add all the jobs.

Sometimes dwarves stop working on a full 10 Job list after 3-4 Jobs, resulting in the Shop being jammed as well.

I'm using the latest DF Hack for 40.24.

Now, people were yapping about workflow and such messing the jobs up, but workflow is disabled in the onloadworld.init, and shows so in the console after starting to play. No workflow commands are enabled.

Any ideas?

[PatrikLundell]

0.40.22 (?) or thereabout changed the jobs handling quite a bit.
- One change is that wall (etc.) construction is now an unskilled labor rather than a carpenter/mason job.
- Another change is that DF goes to think on what job to take next, so e.g. pulling a lever on repeat gives a very uneven rate.
- Job selection is now partially based on proximity, so the stack based build order of walls is no longer a thing.
- Job priorities have been introduced for a number of jobs, so you can e.g. designate digging with different priorities to control the order they're performed in (that does not stop a second dorf from taking the next lower priority job after the first one, but getting it done faster, however).

I can't say I've had any great problems with the "thinking about what to do next" delay. Usually the dorfs move some 10 tiles before returning (or taking another job), not trek all the way to the meeting hall. However, the jobs rewrite made the idle count basically useless, since it includes "between jobs".

I did have great problems with workflow screwing up all kinds of jobs, so I've completely stopped using it, while still using DFHack. However, you say that's not it.
One major cause of problems for me has been bins. Anything that interrupts one repeat job cancels the job rather than just that particular job instance (trying to use items pushed around by the surf is great fun...). When a bin or barrel is accessed to put something in it or remove something from it the bin is blocked for all other access for a substantial amount of time, causing the items in it to be inaccessible, and thus cancel the jobs. That issue existed in 0.40.19 as well, though.

[BNDR]

Thx for the reply and indepth explanations of your observations, appreciate

Yeah I'm not good with version numbers

I also should have noted that I'm using quantum minecart stockpiles. The problems started before I used them so that must no be the cause, I was using standard stocks and still the same behaviour.

I do notice, the better the dwarves get, the faster they seem to "re-pick" the job, and they dont wander off that far. Also it SEEMS that the game distributes workers more evenly, sort of. So everbody who's a Clothesmaker for example gets an assignment more often.

So you basically explained it all, it seems reasonable and ofc acceptable. No need to go back to XX.19

Thx again

[PatrikLundell]

I use Mine cart QS' quite a lot. I've got two problems with them:
- They tend to stall because the feeder stockpile fills up and hauling into the cart seems to be a lower priority job than hauling to a stockpile, My early fortresses risk getting crops withering in the fields because the feeder stockpile is full (fixed with an extra, large, plant/fruit only feeder stockpile). Thus, the dorfs haul to other stockpiles instead. I've had the annoying case with a magma sea QS whose feeder stockpile stalled, so the buggers hauled the bars 100 levels up to the downwards route minecart feeder stockpile (hauling served more often since it was closer to most of the dorfs).
- You get a lag between production and usage of produced items as they have to be hauled from the workshop to the feeder, and then into the cart.

Neither of the problems is worse than the QS benefit, though.

[BNDR]

X
X
X T Y
X
X

Is my setup, takes a while longer but it doesnt jam at all.
X is the Stockpile giving to the Minecart on Stop T
Y is the "Take from links only" stockpile (QS)

For my clothes I'm using a 4 "X" version which also works nicely.

Never make a
X T Y
version, one "give to" stockpile is too little.

But I suppose you know that

Take care and don't let the clowns in

[PatrikLundell]

Your setup is FAR too small to work for me... I currently use 4*7 feeder stockpiles for my two starting QS' and, as stated, my Farmer's QS feeder stockpile stalls. One reason for that is that I blanket gather all herbs on the embark to get seeds for those that are brewable to get my own above ground farming going.

I did let the clown in once... They weren't funny at all (probably mimes, all of them ).
Nowadays I greet them with menacing glass spikes on repeat, cave-ins if they won't path to my spikes, and ballista bolts if they camp in the air in the circus. I also use candy spikes as a backup if some of them happen not to be dented by glass.

It'll probably be 50 years before I get to deal with the circus in my current fortress, because I play a dead civ and have found huge amounts of candy, so I'm short of dorf power and have things to deal with for a long time (16:th year and I've only secured the 3:rd cavern yet). All this provided I keep at it for 50 years... The focus is my toughest challenge yet, though: get the buggers to reproduce. I'll probably end up draining the magma sea on the way as well, since it's so deep that's probably easier than the normal method.

[kingu]

Yeah something is up with my siege operators as well. Ballistas on reperat changes siegeoperator between every shot making them alot less effective. I dot know if it is that the siegeoperators want breaks or maybe its about ther job-distribution. In any cas something is very different nowdays.

[Chevaleresse]

I use Mine cart QS' quite a lot. I've got two problems with them:
- They tend to stall because the feeder stockpile fills up and hauling into the cart seems to be a lower priority job than hauling to a stockpile, My early fortresses risk getting crops withering in the fields because the feeder stockpile is full (fixed with an extra, large, plant/fruit only feeder stockpile). Thus, the dorfs haul to other stockpiles instead. I've had the annoying case with a magma sea QS whose feeder stockpile stalled, so the buggers hauled the bars 100 levels up to the downwards route minecart feeder stockpile (hauling served more often since it was closer to most of the dorfs).
- You get a lag between production and usage of produced items as they have to be hauled from the workshop to the feeder, and then into the cart.

Neither of the problems is worse than the QS benefit, though.

I usually throw several different food stockpiles to prevent this. One near the farm, one in the tavern, and (later) one in the citizen-exclusive dining room/tavern. I've noticed that you'll need feeder stone stockpiles  if you ever want all that magnetite to get into the fort.

[BNDR]

Further investigations have revealed:

The issue is with using the "Duplicate job" shortcut (on my dfhack.init setup it is Ctrl+D) used on ACTIVE jobs.

As soon as the job has an "A" beside it, and it gets duplicated, all of the duplicated jobs break, at least that's what I found out.

Lets say:
Fill in 10 Jobs "Melt Tetrahedrite"
Wait until theres only 3 Jobs left
Duplicate the topmost Job saying "A"
All duplicated jobs become stuck and are never started.
So 3 jobs are finished (the 'old ones'), and 7 Jobs stay stuck (the duplicated ones).

ever since I started waiting until ALL jobs are done, or MANUALLY add a NEW job and THEN duplicating it, works like a charm havent seen a stuck job EVER SINCE.

I can only imagine it is due to the fact that when you duplicate a job and the way jobs are handled has been changed as Patrik stated, it seems to hiccup when the old jobs are finished and the new duplicated ones are queued, maybe there is a sort of invisible flag copied with the old job (the one used to duplicate) and it can't assign a dorf to start the job due to some flag being present.

ALL of that is just guesswork, but duplicating jobs only when they aren't already assigned solved it, as stated.