Print

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

[Aykavil]

Current problem:
Dwarves go the long trip from the fortress to the battlefield, pick up a single damn sock, and come back. Battle aftermaths become more daunting than the battles themselves.

(as of version 38c, flame me if this problem is no more)

Fix: make dwarves smarter haulers.
Say Urist Mc Dwarf has chosen to haul an item to a stockpile.
1. has claimed item
2. has claimed stockpile slot

3. Does item fit into a bag/barrel/bin ?
4. No -> haul normally.
5. Yes: is there empty corresponding bag/barrel/bin ?
6. No -> haul normally.
7. Yes: is there 2 more unclaimed unstockpiled items that would fit into the bag/barrel/bin ?
8. No -> haul normally.
9. Yes: claim bag/barrel/bin
10. Go fetch bag/barrel/bin
11. Go fetch item
12. Put said item in bag/barrel/bin
13. Is there an unclaimed unstockpiled item that would fit into the bag/barrel/bin ?
14. No -> go put bag/barrel/bin in stockpile slot
15. Yes: claim said item
16. go to 11.

Extension:
Do the same when dumping items, except don't dump the bag/barrel/bin.


Dubious extension
Dwarves needing an item for a construction could check if it goes into a bag/barrel/bin. If so, and if container available, and if 2 more needed items would fit into said container, claim container, put items in container, carry items to construction site and discard container.

• Building 10-weapon traps would be easier
• Incentive to use blocks instead of rough blocks/logs for constructions.
• Big constructions would maybe become too much faster

Would probably require:
Compacting stockpile job (counts as hauling). If the contents of the emptiest container in a stockpile would fit into another container of the same stockpile, put the contents of the emptiest container into the other container.

[Dame de la Licorne]

And this would also tie in with better stack handling.  I like.

[Tylui]

I thiiiink that the problem with this(I might be wrong; maybe I dreamed it) is that right now dwarves don't pick jobs.  Jobs pick dwarves.  So when they run for that sock on the other side of the fortress, what really happened is the song was calling out in a pathetic psychic voice "help meeee" as a Dwarf was just setting down something.  He heard this cry for help and went for the sock.

But seriously, the jobs pick the Dwarves right now.  That's why constructions are built from last to first designated, instead of proximity to Dwarf, or to building material, or both.

[Puzzlemaker]

I thiiiink that the problem with this(I might be wrong; maybe I dreamed it) is that right now dwarves don't pick jobs.  Jobs pick dwarves.  So when they run for that sock on the other side of the fortress, what really happened is the song was calling out in a pathetic psychic voice "help meeee" as a Dwarf was just setting down something.  He heard this cry for help and went for the sock.

But seriously, the jobs pick the Dwarves right now.  That's why constructions are built from last to first designated, instead of proximity to Dwarf, or to building material, or both.

That should really change at some point...

[Tylui]

Yeah it should.  Every time I play, I see something that would be improved by a Dwarf-centric job system.

It would definitely stop the "No Job" jobs just chilling while there is very obviously something I'd like that dwarf to do.   Not that that happens often, but still.

[korora]

I agree that hauling should get more efficient.  Instead of searching for a corresponding container (by which I assume you mean a container in the proper stockpile), you should just search for any empty container and, if necessary, dump the objects into the proper container when you reach the stockpile.  Better yet, you could have haulers always carry a container, so you can skip steps 9 and 10.

The scenario that motivates you to this idea isn't a problem for me, though; the battlefield tends to be at my fortress gate.

[Granite26]

Yeah it should.  Every time I play, I see something that would be improved by a Dwarf-centric job system.

It would definitely stop the "No Job" jobs just chilling while there is very obviously something I'd like that dwarf to do.   Not that that happens often, but still.

I'm torn between agreeing with you and pointing out that it was a design decision that obviously made sense at the time.  Looking at the complexity of the pathfinding system and AI tracking for all of it, I can't honestly say that I understand all the variables to be accounted for with which system you use.  There's a distinct possibility that there would be a major framerate hit if dwarves actually started thinking about what they were going to do next.

Edit->  By which I mean that there could be huge speed optimizations by letting each job pick the dwarf best suited to do it from those available.

[korora]

Yeah it should.  Every time I play, I see something that would be improved by a Dwarf-centric job system.

It would definitely stop the "No Job" jobs just chilling while there is very obviously something I'd like that dwarf to do.   Not that that happens often, but still.

I'm torn between agreeing with you and pointing out that it was a design decision that obviously made sense at the time.  Looking at the complexity of the pathfinding system and AI tracking for all of it, I can't honestly say that I understand all the variables to be accounted for with which system you use.  There's a distinct possibility that there would be a major framerate hit if dwarves actually started thinking about what they were going to do next.

Edit->  By which I mean that there could be huge speed optimizations by letting each job pick the dwarf best suited to do it from those available.

I'm not convinced this is the case. Where you supposedly gain speed is by letting the jobs that happen to search first take priority over all other jobs, so that you only have to search until you run out of dwarves (rather than until you run out of jobs).  However, I'm pretty sure based on my experiences that the dwarf selection process just takes the first eligible dwarf, rather than the closest one.  If this is true, then no pathfinding is being done, and it really wouldn't be noticeable to the user either way.

If you had a queue for each job category listed in v-p-l, it would be very fast for dwarves to choose jobs (with priorities!).  An idle dwarf would simply take the first job from its highest-priority job category.  New job? Append it to the proper queue (very fast operation).  Memory-wise, I don't know for sure how jobs are currently stored, but there's not a whole lot of overhead for having something on the order of 30-50 queues rather than one.  There's a little more work to be done if you actually want dwarves to choose the closest job, though.

I guess one issue I can see with dwarves picking jobs is how to decide which dwarf picks first. Not that this isn't an issue now.  But if you have two miners and only one accessible mining square designated, you'd have to break ties somehow.  In my dream version of DF the winner is whichever one is willing to do the job for less pay.

[Tylui]

Yeah, I'm sure it made more sense then; otherwise it wouldn't have been done that way, right?

I think there'd be better performance with the dwarves picking.  Instead of 3000 jobs looking for an open dwarf, there'd be (usually)less than 200 dwarves looking for an open job that fits their labor list.  And, like Granite said, if the v-p-l list were prioritzed, it'd be even better.

Plus, the game wouldn't have search through all 3000 jobs, really.  Each job is obviously associated with a skill, so it would only have to search through the jobs with that skill associated with it.

[Nukeitall]

I'd settle for the ability to burn the mounds of crap like in adventure mode.

[Granite26]

Yeah it should.  Every time I play, I see something that would be improved by a Dwarf-centric job system.

It would definitely stop the "No Job" jobs just chilling while there is very obviously something I'd like that dwarf to do.   Not that that happens often, but still.

I'm torn between agreeing with you and pointing out that it was a design decision that obviously made sense at the time.  Looking at the complexity of the pathfinding system and AI tracking for all of it, I can't honestly say that I understand all the variables to be accounted for with which system you use.  There's a distinct possibility that there would be a major framerate hit if dwarves actually started thinking about what they were going to do next.

Edit->  By which I mean that there could be huge speed optimizations by letting each job pick the dwarf best suited to do it from those available.

I'm not convinced this is the case.

I'm not either, but I've learned to be careful when second guessing other peoples decisions without full knowlege.

[Aykavil]

Anyway. I've found that using a few well-placed stockpiles dramatically improves the situation. I'll put a word in the wiki.

[Keldor]

Actually, having the dwarves pick the closest job would actually INCREASE performance, DESPITE the additional overhead of job selection.  Why?  Pathfinding.  A typical 100 distance pathfind will involve about 5000 squares covered before the path is found.  A 200 distance path needs about 20000 squares scanned!  However, a path of length 25 only needs about 150 squares to be scanned.  Since there is typically a large difference in the distance to the nearest job as opposed to the distance to a job at random, the savings in pathfinding costs more than compensate for the added costs of scanning through 1000 some jobs.

[Align]

(Except when the items are far away or don't exist/are inaccessible)

[korora]

Actually, having the dwarves pick the closest job would actually INCREASE performance, DESPITE the additional overhead of job selection.  Why?  Pathfinding.  A typical 100 distance pathfind will involve about 5000 squares covered before the path is found.  A 200 distance path needs about 20000 squares scanned!  However, a path of length 25 only needs about 150 squares to be scanned.  Since there is typically a large difference in the distance to the nearest job as opposed to the distance to a job at random, the savings in pathfinding costs more than compensate for the added costs of scanning through 1000 some jobs.

This is a pretty flawed analysis.  First off, "typical" is generally ignored in computer science.  The proper way to look at the problem is the worst-case scenario.  Second, even assuming your numbers are right, you can't solve this problem by saying you'll just path to the closest job.  You're assuming you already know which job is closest.  You say that pathfinding cost savings compensates for "scanning through 1000 some jobs", so I think what you're missing is that in order to find the distance to a job, you must pathfind to it.  And as long as you're pathfinding to every job, you might as well save the shortest path at no additional cost.  There's no way this will boost performance, though.

(Yes, you could search outward from a dwarf until you find a job, but that will be more expensive than A* and again, in the worst case will not give you a performance boost.  I think the right way to do this is to use Dijkstra's to find the single-source shortest path tree and then use that to path to the job).