Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

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

未關閉
#6,028 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 4 天內回覆

還沒有人認領這個 Issue。

評估

難度
3/5
預估耗時
1-2 天
新手友好度
57/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
cpp
領域
backend

研究方向

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.

由索引模型根據 Issue 內容生成。

描述

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
主要語言
C++
星號
2.1k
分支
509
平均合併
3 天 17 小時
30 天內合併 PR
13

環境準備

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

DFHack/dfhack 的其他 Issue

查看 DFHack/dfhack 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。