Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#6,028 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 4 días

@ab9rf ya está trabajando en esto.

Desde el 31/10/2026.

  • #6029 de @ab9rf — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
57/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
cpp
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
C++
Estrellas
2.1k
Forks
509
Merge medio
3 d 17 h
PR fusionados (30 d)
13

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de DFHack/dfhack

Todos los issues de DFHack/dfhack

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.