labormanager (modern mode): mismatch probe enables unmanaged stoneworking labors on idle dwarves, bypassing work details

Ouverte
  • Quelque chose ne va pas ?
#6,028 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 4 jours

@ab9rf y travaille déjà.

Depuis le 31/10/2026.

  • #6029 par @ab9rf — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
57/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
cpp
Domaine
backend

Piste de recherche

Read plugins/autolabor/modernengine.cpp around the probe candidate selection and write logic, then check how managed_labor_cache is populated and how disputed_labors is defined in plugins/autolabor/laborcommon.cpp. The report suggests skipping unmanaged candidates; verify this against the existing escalation behavior. Done means the probe never enables an unmanaged labor, with a regression test covering the case.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Summary

In modern mode, labormanager's labor-mapping-mismatch probe can enable labors that have been set to unmanaged. Its candidate list always includes the five stoneworking labors (ENGRAVER among them), and it writes each candidate straight into an idle unit's status.labors, so work details and specialization don't apply. In my fort, after labormanager labor ENGRAVER unmanaged, five specialized dwarves who are not in the Engravers work detail were working "Detail floor" jobs.

Versions
  • DFHack [53.16-r3] (Steam)
  • Dwarf Fortress [v53.16] (Steam)
  • Mods: [Audible Alerts 1.7, clinodev's dry mines ]
Setup (all visible in the attached save and dump)
  • labormanager in modern mode (enabled=1 mode=1).
  • Engravers work detail set to "Only selected do this" with one member ('Engravers' mode=3 members=[16830]).
  • labormanager labor ENGRAVER unmanaged (ENGRAVER: ... managed=0).
  • A large floor area designated for engraving (16 DetailFloor jobs).
  • A managed skilled posting that never gets claimed: job 6495, ConstructBuilding at a millstone, mapped to MILLER (age=12417, MILLER: streak=202, managed=1), while five idle citizens hold MILLER (state=0: 10687, 11250, 17028, 17055, 17059).
Observed
  • At the time of the dump, 17025, 17026, 17027, 17056 and 17060 have DetailFloor as their current job. All five are specialized, none is in Engravers, and none of their work details covers ENGRAVER (auto:Care, auto:Skill:Miller, plus Hunters for 17025).
  • None of those five has ENGRAVER enabled at dump time; only the Engravers member (16830) does. That fits a temporary probe write reverted after they claimed the job, but I didn't catch ENGRAVER while it was set, and I can't rule out that some of these jobs were claimed before I changed the settings above.
  • 11250 is idle and specialized but has STONECUTTER enabled, although none of his work details covers it (Stonecutters has no members) and the other idle specialized citizens don't have it. STONECUTTER is the probe's second candidate after MILLER, so this looks like the probe mid-round.
  • The five idle citizens aren't taking any of the 10 unclaimed DetailFloor postings.
Expected

The docs for labormanager labor <labor> managed|unmanaged say: "Unmanaged labors are entirely governed by the player's own work detail configuration." With ENGRAVER unmanaged, only the Engravers work detail should decide who engraves, and labormanager shouldn't enable ENGRAVER on anyone.

Cause (from reading the 53.16-r3 source)
  • An escalation only starts for a managed labor (modernengine.cpp L1740-1790).
  • Its candidates are that labor plus every entry of disputed_labors (laborcommon.cpp L350-356: STONECUTTER, STONE_CARVER, MASON, ENGRAVER, STONE_CRAFT), with no managed check on the candidates (L1779-1781).
  • Each cycle the next candidate is set with status.labors[m] = true on the first idle, non-excluded unit, and earlier writes are re-asserted while the posting stays unclaimed (L1817-1856). Specialization and work-detail membership aren't checked.
  • After every candidate has been tried, the writes are reverted (L1859-1869), but nothing stops a new escalation for the same labor, so a posting that can never be claimed keeps the probe cycling.
  • Job 6495 appears to meet all the start conditions (managed, skilled, starved well past five cycles, idle units holding the labor), so ENGRAVER should be set on an idle unit once per round.
Suggested fix

Skip candidates where !managed_labor_cache[m].

Workaround

labormanager mode monitor. Disabling the modern engine reverts any probe writes and removes the auto: details.

Related

Probably not a duplicate of #2408 or #2868: those concern the pre-v50 labormanager and the legacy autolabor engine respectively. The modern engine, including this probe, was added in 53.16-r2.

Attachments
  • Save: link
  • Mods folder: link
  • labormanager dump output: link
  • Screenshot: Engravers work detail (cropped out, but 'only selected do this' is enabled)
Image
Langage dominant
C++
Étoiles
2.1k
Forks
509
Merge moyen
3 j 17 h
PR mergées (30 j)
13

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de DFHack/dfhack

Toutes les issues de DFHack/dfhack

Issues similaires

Plus d'issues C++

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.