prioritize taken jobs to prevent churn #3245

Activity

1. myk002

   self-assigned this

   on Apr 16, 2023
2. myk002

   added this to 50.08-r1on Apr 16, 2023
3. github-project-automation

   moved this to Todo in 50.08-r1on Apr 16, 2023
4. myk002

   moved this from Todo to Being worked on in 50.08-r1on Apr 16, 2023
5. myk002

   removed this from 50.08-r1on Apr 17, 2023
6. wsfsbvchr commented on Apr 25, 2023

   

   wsfsbvchr

   on Apr 25, 2023

   More actions

   But isn't this bad if all your dwarves are doing pointless jobs that have been given high priority, and you'd, for example, desperately need a lever to be pulled? Or when something else that's kind of urgent shows up?

   Mining jobs and some others have those numbered priority designations one through seven, so maybe that should be taken into account when prioritizing taken jobs?
7. myk002 commented on Apr 25, 2023

   

   myk002

   on Apr 25, 2023

   MemberAuthor

   More actions

   I tried what I proposed here and it wasn't very effective.

   The problem is that we don't have any granularity to set priority. It's either default (mostly ineffective) priority, or it's super high priority that beats everything else out and can interrupt other jobs. there's nothing in between.
8. wsfsbvchr commented on Apr 25, 2023

   

   wsfsbvchr

   on Apr 25, 2023

   More actions

   What if you were to prioritize all taken jobs conditionally? Like pick a default stance (prioritize/skip prioritization) and then a way to specify exceptions to that rule. Then it'd have to do a check for every job, to see if you want it priorized or not. You could pick mining for high priority when it's imperative you get your digging done uninterrupted. If all other jobs are left on normal priority, it wouldn't be a miner who abandons their job.
9. myk002 commented on Apr 25, 2023

   

   myk002

   on Apr 25, 2023

   MemberAuthor

   More actions

   We can prioritize our prioritization, so to speak, but I don't think that would solve the job interruption problem. I think the fundamental issue is that prioritize depends on there being only an appropriate number of dwarves that can do each type of job (so the "blast radius" of setting the do_now flag is reduced). The "everyone does this" approach of the work details system is very much at odds with this requirement.

   I think ideally we would be adjusting the algorithm DF uses to prioritize jobs internally, using small increments, instead of using the sledgehammer-style do_now flag. Of course, if we knew how to be more subtle, I probably would have written prioritize to take that approach in the first place.

   I know the overall job selection algorithm is on @Putnam3145 's radar. It could be that prioritize will just become obsolete before we come up with a good fix.
10. Alistair-Afton commented on Sep 18, 2026

    

    Alistair-Afton

    on Sep 18, 2026

    Contributor

    More actions

    Mechanism data that may help here (verified on 53.16, details in DFHack/df_misc#90 and field docs in DFHack/df-structures#908):

    Job assignment is a per-tick auction. Each pass, DF pushes a job_applicationst{unit, posting_index, value} per candidate into a 2000-node binary heap in job_handler and the highest value wins the posting. The pass completes inside the tick (~0.1-0.5 ms), which is why the heap always looks empty from Lua.

    Observed value bands (additive score):

    ~value	meaning
    9.5k-15k	baseline bid (not labor-eligible / distant)
    30k-170k	distance/labor-tuned bid
    ~1.05M	continuation bonus when a unit re-bids its current job type — the existing "stay on task" weight
    ~20M	do_now flag on the job, or unit-sourced needs jobs (Sleep etc.)

    So the granularity problem myk002 described is real: do_now is a flat +20,000,000 for every bidder on the posting — it beats the ~1M continuation bonus but has no per-unit targeting, and unit-sourced need jobs live in the same band, which is why prioritized jobs still lose to food/drink/sleep. Separately, much of the visible "interruption" isn't preemption at all but claim races (a unit en route loses the posting to a faster claimer and re-evaluates) and needs thresholds.

    On granularity: since value is additive, a bounded bonus term is mechanically possible in principle — but the heap is populated and drained entirely inside the pass, so scripts can't touch individual applications. A fix would need a hook/interpose point in the scorer (worldst::handle_job_applications per maintainer knowledge) — e.g. a small per-job bonus field consulted during application construction, sitting between baseline and the continuation bonus. Happy to dig further if that direction is wanted.

    Related: #5954 adds a do_now toggle at building designation time, which covers the "make this one building urgent" case without churning the rest of the queue.