Print

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

[Exasperation]

quote:Originally posted by Veroule:
<STRONG>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.</STRONG>

Somewhat related to this, it would be nice if the items were collected in the other order for a brewing job.  That way, if you're out of barrels, you won't have your dwarves drag something brewable out to the still, realize there's nothing to put it in, and leave it to rot while they go loot a corpse or some such.  In any case where there are both perishable and non-perishable items needed for a task (brewing, extract plant to x, etc...), it makes sense to gather all the non-perishable items first.

[Rutherford]

Combining a lot of the ideas above, here's what I would try.

Job creators register the fact that they have jobs available and the labor necessary.  These postings are separated by type:

1. Health / Animal Care
2. Construction  
3. Designations
4. Building Jobs (Seed Planting, Harvest, Workshop tasks, Lever, etc)
5. Hauling
6. Hunting / Fishing / Trapping

Similarly, Idle dwarves register their availability and the labors they have turned on.  If at any point there are no Idle dwarves, stop processing.

Each category of jobs is processed in ascending order.  If there are jobs and available dwarves of appropriate labors, then the details of each job is determined and a job priority assigned.  

First, jobs select materials.  Materials selected should be the closest available of the appropriate type.      

Next, jobs select from the available dwarves.  This selection should be made based on the total distance to be traveled modified by walking speed, the appropriateness of the dwarf (strong dwarves for hauling, highly skilled dwarves for workshop tasks, etc), and the dwarf's preferences (RUBIES? I LOVE Rubies! - thanks, CharonX).

Distance, both for materials and dwarves, should be based on actual path.  To reduce the cost of this calculation, perhaps the available entities should be sorted by straight-line distance.  Then, in ascending order calculate the actual paths until the shortest known path is less than the next object's straight-line distance.

Finally, the jobs which have selected materials and a dwarf are sorted by job length minus a factor of the amount of time the job has waited.  The lowest number is chosen and the job is started.

Each job always selects the best of the available dwarves and materials.  If another job is successfully assigned one of the selected items, the job which was unsuccessful is marked for recalculation.  However, that recalculation only occurs if there are available dwarves and there are no jobs waiting ahead of it in the list. If its best choice wasn't good enough, don't even worry about 2nd best.

Stockpiles, Farming Plots, and other objects which might create multiple job requests only register a single job available.  If that job is selected, a second job request is created  with a new waiting time.  If there are still available dwarves, this second request may jump to the head of the list and be started immediately.  

Also, the time a job has waited should be stockpile neutral.  Otherwise, you'll end up with stockpiles which get more greedy as they age.  

As an extension, the selection of materials might include materials currently tasked with a non-destructive job.  If a plump helmet is just being returned to the stockpile, the brewer might take off after that plant.  If he catches the dwarf hauling it, he'll take it from him and go back to the brewery.  If he doesn't, he'll still have started walking towards the stockpile earlier than he would have before.

I would stop the majority of job canceling.  If a job does not have the available materials, it should just be highlighted in the job list and elsewhere.

[Toady One]

A few issues:  if dwarves choose to haul items as they walk around, you'd have to fuss a lot with how often or how well they check, since there might be many, many items to look over.

In the latest posted model, the only thing I'd add is that if you process the jobs at one instant in time, job priorities might not work very well.  Haul jobs will still pick up skilled artisans that could be doing better jobs.  It might be best to let things sit for a little while to give the jobs and dwarves a chance to make better matches (what you posted is about what I had in mind for my 'bidding system', with this addition).  It'd all need to be balanced in practice, but some kind of delay is probably necessary to get priorities working to satisfaction.  I'm not sure just how crucial it will be, since that'll all depend on how frequently minor jobs steal dwarves that have those jobs on low priority (assuming job priorities alleviates some of the need to turn off hauling in VPL).

[Rutherford]

quote:A few issues: if dwarves choose to haul items as they walk around, you'd have to fuss a lot with how often or how well they check, since there might be many, many items to look over.

If a dwarf already has a path chosen and you want to check if there's a hauling job to easily add, then the only items to check are those whose location and destination are both within a certain distance of the path.  Furthermore, the vector of travel has to be in roughly the same direction as well.

You don't have to assign jobs every time through the game loop.  And I wouldn't be surprised if the best delay is related to the number of idle dwarves.

Highly skilled dwarves are always going to be attractive to hauling jobs because of their increased attributes.

[ April 27, 2007: Message edited by: Rutherford ]

[Funkadelic Jive Turkey]

Toady's comments make it seem like a real solution for job prioritization is a difficult matter. I'm not sure of how the current code works, so pardon me if the suggestion I'm about to make is off.

Perhaps as a temporary solution, which seems to me like it might be pretty easy and space conservative, seperate assigning tasks into a system similar to military on \ off duty. I mean rather then telling a dwarf only to brew  (job: on) or not to brew (job: off), split the system into an off, stand-by, on. So you can tell a dwarf essentially "never do this job" (off), "do this job" (on), or "do this when there's nothing else to do". So for example you can have a black \ grey \ white coding for these, and if you set a dwarf to mining (white) and the hauling jobs (grey) he\she would mine when their are mining jobs pending, and failing that begin hauling.

Now I know this doesn't address pathfinding and dwarves selecting jobs across the fortress, but it would help with not having to constantly toggle job status to get your dwarves to do the job you want.

Hope this may be helpful.

[ April 28, 2007: Message edited by: Funkadelic Jive Turkey ]

[Toady One]

"Items that are within a certain distance of the path" is a tricky thing to check quickly.  For instance there could be a stone hauler whose path goes within 2 tiles of a cluster of stone, but there's a wall in between.

FJT, there are some issues with this approach since the dwarves don't select the jobs they do (so the jobs would have to check against each other, leading to some complications).  The current idea is that everything needs to be collected together and handled properly, and there aren't really any temporary solutions I'm going to try -- I'd rather just address this problem once, when I get there.  Things rarely work that way, of course.

[Funkadelic Jive Turkey]

I understand, or at least I think so. Anyways my idea on the matter was geared more towards quick-fix than solution. I still think being able to assign a job priority like that would be helpful but it's ultimately a bottom of the list interface quirk than an issue demanding of your attention.

[Rutherford]

quote:Originally posted by Toady One:
"Items that are within a certain distance of the path" is a tricky thing to check quickly.  For instance there could be a stone hauler whose path goes within 2 tiles of a cluster of stone, but there's a wall in between.

I envisioned it as two steps.  The first step limits the number of objects to those which might be hauled.  The second is more intensive, and checks for things like walls.

But, picking up the extra jobs on route to a primary job seems to have less of a benefit to the whole fortress' efficiency than the basic overhaul to the job system.