Print

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

[zorbathut]

I've found that when playing the game, the things that annoy me most is that I feel like I can't give my dwarves useful instructions. So here's a short list of things that I would absolutely love to be able to tell my dwarves to do:

* Prioritized jobs. I want to say "if there are stoneworking jobs, go do stoneworking, otherwise haul stuff around".
* "Repeat-but-don't-delete" jobs. some jobs seem to do this already (like preparing fish), but others (cooking, making stone blocks) don't support this. Why not just make it an option that the player can set per-job? If someone wants to make an infinite number of stone doors, let them.  
* Choosing dwarf colors. I've had all sorts of random dwarves decide they really want to be farmers just because they picked a few plants, or decide they're now an architect because I needed someone to go make a stone road. I'd like to be able to say "you are a purple dwarf, live with it" and have that stick.
* Choose jobs based on proximity. Right now the job queue is solely first-in first-out, as I understand it. Why not make it weighted, taking into account both "distance from this dwarf" and "age of job"? That way you still won't have never-completed jobs, since eventually they'll get old enough that someone will go pick it up, but dwarves won't run all over the fortress for one or two more jobs.

It might be that I play the game differently than others, but I see it as more of a construction/layout/economy simulator, not a micromanagement game, and right now it feels like I'm spending a lot of my time doing things that the computer could be easily doing for me. As well as not having the tools to manage dwarves effectively.

I must say that the whole game is spectacularly impressive though. Even though I'm not playing it right now due to the above issues I'm definitely keeping an eye on it.

And if there's some way to do what I want already, please let me know  

[Anticheese]

Indeed! I've been irked by the same problems when my fortress got larger.

The job prioritizing might be a little bit micromanagely but hey, stuff like this would help make the game easier to play.

I like this set of ideas..

[zorbathut]

I actually see job prioritization as anti-micromanagey   When I'm trying to make things work in my fortress I'm often turning "haul things" on and off constantly. If I've got stoneworking jobs to do, I tell my stoneworkers to stop hauling things. If I don't, I tell them to start hauling things so they're not standing around idle. I tell my farmers to start hauling during winter and tell them to stop during spring, I do the same thing with engravers and woodworkers and architects and brewers and cooks and all of this honestly is why I stopped playing last time.

I'd love to just describe what I want to the computer and have the computer carry that out. That would actually reduce micromanagement.  

[Anticheese]

Yeah, I just ment the lightly micromanagement thing meaning you have to remember to turn it on for each of your workers and trainees.

It would however be a great feature.

[Veroule]

There are definitely a few changes that need to be made to how dwarves go about accomplishing a job.  The current pattern is:
dwarf accepts job: the A flag is put on it in the building.

dwarf checks for first job item: if one is found that isn't TaSKed dwarf will assign it to the job and begin walking to it.  This is the first problem spot.

dwarf gets item to location, then checks for next item: this check and subsequent ones are done with the dwarf standing in the work space so the items are more controllable in terms of nearby stockpiles.

The problem that occurs most is when an object needed for the job has a store item at wherever task on it.  What we need is for those tasks to be aborted and new bring item to workshop tasks to be issued.  I would suggest this pattern to how dwarves would go about such jobs.

dwarf accepts job: set the A flag on it, then the dwarf walks all the way to the workshop.

dwarf checks all job items: issue bring to workspace orders for nearest items and task them as being used for that job.  These would be of appropiate hauling type so if I have a mason that does not haul stone then he will happily stand in the workshop and wait for a dwarf to bring him the stone.  The orders should include items both currently tasked with a bring to task and those that are being hauled.  This makes the method of check be
1: items all exist
2: items are not tasked above a bring to order
3: selected items then check for nearest appropaite dwarf to bring them

The main effect of this change is that dwarves will reassign things waiting to be put away, and multiple dwarves can be involved in getting a single job done.

Building a road is a great example of something being broken.  Currently a dwarf with architecture brings all the materials to the road.  It makes no sense what so ever.

-------
Another thing is that certain jobs just need to have a higher priority.  Putting food away and removing rotting items being the top jobs.  I have had huge stacks of meat just rot in a butchery because the dwarves felt like starting other build jobs.  I really shouldn't have to abort all the construction just to get them put the food away before it rots.

-------
Aborting of jobs in workshops needs to also be adjusted.  Sure abort if the materials don't exist.  If the dwarf gets interrupted don't abort the job.  Suspend it on an automatic timer and keep its current state.  That should include interuptions like creatures, eating, drinking, and even sleeping.  I am so sick of having to reinsert a whole stack of jobs into a workshop because the dwarf that got them was interrupted by a creature while walking to the site.

[Guy]

quote:Originally posted by zorbathut:
<STRONG>* Choose jobs based on proximity.</STRONG>

If DF could only have one more feature, this is the one I'd choose, over armies and z-level.

This may help out most with stone hauling.  The following always happens to me:

• I just dug out a room.  It is full of stone.
• I want the stone cleared out because I'm making this room my food stockpile.
• So I put a stone stockpile nearby.  Of course the dorfs ignore the stone in the nearby room in favour of the stone that was just mined five miles away.
• OK, I don't bother with stone stockpiles.  But over half of my new stockpile room is still filled with stone.  How am I supposed to clear it out?
• I could build a mason's workshop nearby to build some stone blocks.  But where are the stone blocks supposed to go now?  (No, I do not have enough bins yet.)

I think 90% of all hauling problems would be solved if the dwarves just used some proximity calculation: haul the closest stone to the closest stockpile.

[Toady One]

This last isn't exactly a trivial problem.  The "just haul the closest to the closest" implies a lot of calculation.  If you scatter haulers, items and stockpiles around randomly, and then ask what the most efficient hauling schedule is, there's a lot of processing to do.  You can't have just the dwarf, the item or the stockpile running the show, it has to balance them somehow.  Right now, the item runs the show, with the dwarf making adjustments afterward.  This is bad, as we've all noted, since

code:

o                   = o

the rock on the left might claim that pile spot.

However, if the stockpile runs the show then

code:

===                 o ===

is a bad situation because the stockpile on the left might claim the stone.  Any of these problems with one actor taking the principal role has a dual formulation that breaks it.  I think the case where the pile thinks is probably better in a lot of common cases, but the other case is also quite common.  I had mentioned before trying out some kind of bidding system for building jobs that balances the needs of all of the job participants, and something similar might work here, but it's hard.

Job priorities also raise some similar issues.  Jobs don't really open all that frequently compared to the time it takes to do them, so job priorities wouldn't be respected most of the time unless there's a long delay before the job is assigned while dwarves idle around for the job they want (something like this might happen on a smaller timescale during the aforementioned bidding).

Finally, as far as getting lots of dwarves to haul job items to a work place, it isn't necessarily going to help.  If the job items are in stockpiles that are close to the workshop, it doesn't take long for one worker to haul them all and then get to work, but if that worker has to wait for dwarves from all over the fortress to come and move those items, it will take a long time.  Again, this points to a more nuanced solution where it picks and chooses what to do based on all sorts of factors -- but that's hard to program efficiently.

[Guy]

quote:Originally posted by Toady One:
<STRONG>You can't have just the dwarf, the item or the stockpile running the
show, it has to balance them somehow.  Right now, the item runs the
show, with the dwarf making adjustments afterward.</STRONG>

If things can go both ways so much, why have either the dwarf, item, or
stockpile run things?  How about some kind of central job scheduler
that's outside the three, combined with some kind of bsp-tree for the
map to quickly sort trios of dwarves/items/stockpiles?

[Toady One]

My point was that you can't have them run things, and also that it's not a trivial change.  I imagine the bidding system I mentioned would be a "central job scheduler" of some kind.  Putting an abstract structure on top of the map takes a lot of storage space, and it's hard to maintain as the map changes, especially if flows cut areas off and then rejoin them frequently.

[Veroule]

Lets start wih a simple example of what likely could be an easy fix but will still make a large improvement.

Currently:
I order the brewing of a drink.
My brewer starts the job.
He grabs the last brewable plant from the stockpile and brings it to the still.
He sets off for a barrel.
On the way to grab the barrel, he decides he needs a drink. This releases the brewing job, and the plant is immediately tasked to be returned to the stockpile.
My brewer, now happy from his drink looks to get back to work. However he cancels the brewing job because there is no brewable plant. This is what we don't want to have happen.

The simple fix is to recognize that the item exists with lower order task on it.  In simplest terms the store item task should be the one that gets cancelled.  Probably it would only take a few lines of code to do that little fix, but it would make a huge gain in dwarf efficiency.

[Bas Cost Budde]

quote:Originally posted by Toady One:
<STRONG>My point was that you can't have them run things, and also that it's not a trivial change.  I imagine the bidding system I mentioned would be a "central job scheduler" of some kind.  Putting an abstract structure on top of the map takes a lot of storage space, and it's hard to maintain as the map changes, especially if flows cut areas off and then rejoin them frequently.</STRONG>

I have done a similar, albeit simpler, problem recently, trying to assign a starting point for mail delivery agents who live in their own delivery town. This is a highly static problem, as opposed to the hauling, but nevertheles not quite straightforward to solve.

Toady, would it help to reverse the order of pile hauling tasks? As it is now, you do have some sort of individual starvation, or 'stack rot' as we said in class; maybe a queue is more fair to the hauled items than a stack.

[CharonX]

quote:Originally posted by Bas Cost Budde:
<STRONG>

I have done a similar, albeit simpler, problem recently, trying to assign a starting point for mail delivery agents who live in their own delivery town. This is a highly static problem, as opposed to the hauling, but nevertheles not quite straightforward to solve.

Toady, would it help to reverse the order of pile hauling tasks? As it is now, you do have some sort of individual starvation, or 'stack rot' as we said in class; maybe a queue is more fair to the hauled items than a stack.</STRONG>

Queue comes with similar problems I think because with queues you can end up with countless unimportant jobs blocking the important ones.

---

A possibility I think which could help things a bit is a job-"pending" system. Items etc. would designate where they want to go (provided there is free space in the target stockpile), the stockpile is informed of the intention but not actual allocations are made yet. This could partially solve the "starvation problem" as pending jobs could be overridden by other pending jobs (food is waiting to be stored, hungry dwarf creates "eat food" job, once he arrives at the food and proceeds to eat it the "store me" job is cancelled)
Only when a job changes from "pending" to "accepted/claimed" by being worked on by a dwarf actual capacy in stockpiles is reserved.

Of course this could lead to several odd interactions, like horde of hungry dwarfes racing to a single foodstuff, ignoring those that are only slightly further away, but this also could be dealt with the "intent" notifications. If a job is seeking for a destination (eat food, store me) it checks the nearest destinations for the number of intent declarations vs free capacy and decides based upon a mixture of distance and "overcrowding".

Finally regarding the "doing" of jobs, I think we can leave it in the hands of capable dwarfs to actually select the next job to do, by a mixture of skill level (I'm a legendary weaponsmith and dabbling engraver, so I'll ignore that engraving job and do that slightly father away weaponmaking job instead), distance (how far do I have to run to get there), personal preference (RUBIES? I LOVE Rubies!!!), estimated length of job (to encourage the completion of short jobs first) , elapsed waiting time (so all jobs have a chance for completion, may be merged with job priority instead) and job priority (the ability to give jobs the "do this NOW, maximum priority" marker - i.e. your fortress is flooding and you dwarfs are rather hauling stones than pulling the lever to close the floodgate)

If the "free capacy" of an destination decreases all those that intend to go there are informed and might recalculate their destinations.

The intent-sending of course also works with job themselves, so if a dwarf goes to a certain job they do not "claim" it until they actually start doing it - so if another dwarf much closer than the first one becomes jobless and looks for something to do they might also select the job (they are deterred by the "overcrowding" - there is space for 1 dwarf and 1 dwarf already announced his intent, but perhaps they are highly skilled in the job and extremely close and there are no other good jobs nearby) and - naturally - arrive much earlier, claim it, the first dwarf gets informed of a capacy change (0 dwarf can do this job now) and goes looking for a new one.

Of course there are lots of ways to further expand that system (at the cost of processing power) by having dwarfs on the way to a job periodically check if there any jobs they would rather do, having new jobs created inform nearby dwarf, triggering a re-check of  what they are wanting to do, allowing dwarfs to abandon jobs they are doing also for non-interrupt everything jobs (eat, drink, being startled, dangerous terrain) but at a high penealty (dwarfs prefer to finish whatever they are doing) modelling current "interrupt" jobs (drink/eat/sleep) to work similarily (if the dwarf is slightly tired he might work on, he he is tired he probably will go to bed if he does not have a job already, but he won't just drop everything and go to be, only if he can hardly stay upright the "sleep" job will be imporant enough to overcome the "wants to finish current job" penealty)

[ April 17, 2007: Message edited by: CharonX ]

[zorbathut]

I'm well aware that trying to schedule things "perfectly" is not only difficult but nigh-unto impossible. But it seems like there are ways to improve matters. I think the way I'd design it is to make dwarf-position the important part, and make all jobs "predicted" one step ahead.

For example, you have rocks all over the fortress, and no space in the rock stockpile. Nothing happens. A dwarf picks something out of the rock stockpile, and the rock stockpile pings a "hey now there's room for rocks" trigger. All the rocks that are listening on that trigger (which would be rocks that aren't busy) add themselves to a job queue for "I can be hauled somewhere". (They're already in a queue for "I can be used somewhere".)

Next time a dwarf is idle and is willing to take on a rock-hauling job, it goes and looks for the closest rock available. It picks that job and activates it. The rock finds the closest way to satisfy that job (in this case, the closest rock stockpile with space) and reserves that space.

If that's the last space available, the rock-hauling jobs are disabled again. If not, they're left available for more dwarves to handle them, including presumably the first dwarf once he's done hauling his current rock.

It's still not ideal because in theory we could wait for a closer dwarf to be done, but I think it would be better. Prioritize based on dwarf movements and dwarf availability, and dwarf priorities on top of that.

The important thing here, I think, is the idea that a rock sitting in a hallway shouldn't generate a "move this rock to here job", which is how it currently works (as far I know). It should generate a "I am ready to be moved" job, which is disabled if there is no possible location to move it to, and where it's being moved to should only be claimed once someone's actually decided to move it.

[Veroule]

I mostly got a whole method for doing this worked up.  I am not really sure how hefty the memory requirements would be as you get more items floating around, but what I am thinking of would definitely be a hog.  

What I worked up so far uses relative perspectives from buildings, stockpiles, dwarves, and items.  Essentially no specific 1 is in charge all the time.  I should have it about done within a week.  I am just having too much fun playing right now.

[hactar1]

quote:Originally posted by Toady One:
<STRONG>This last isn't exactly a trivial problem.  The "just haul the closest to the closest" implies a lot of calculation.  If you scatter haulers, items and stockpiles around randomly, and then ask what the most efficient hauling schedule is, there's a lot of processing to do.  You can't have just the dwarf, the item or the stockpile running the show, it has to balance them somehow.  Right now, the item runs the show, with the dwarf making adjustments afterward.</STRONG>

What if the dwarf chose the item ("Hm, I need something to haul... that doesn't belong there!"), then it chose the stockpile as soon as he/she picked it up? ("Hm, what should I do with this?  I know, that looks like a good place to put it!")

That solves these three problems:

code:

 @ ==  O        == 

code:

 @ O ==        O 

code:

   == O        @ O == 

As far as I can see, this method behaves better in every situation, unless I'm missing some options.  It is, however, nonstandard in DF for dwarves to assign their own jobs like this.

On a similar note, I would also like hauling priority designations.  For example, "Yes, Edem, I know I just mined out a huge tunnel, but I don't really care about those rocks and I need you to clear the farmland now."  Or, "Sigun, the goods in the wrecked caravan aren't going anywhere, but the goblin corpses by the river have lots of loot, and they'll be washed away by the flood very soon!  Go move those instead!"  The only way to do that now is to designate all the spots you don't want them hauling from as stockpiles, which can potentially be all over the fortress.  I suppose this is sort of similar to the "Burrows" work being done.