labormanager (modern mode): mismatch probe enables unmanaged stoneworking labors on idle dwarves, bypassing work details
維護者通常 4 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
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, plusHuntersfor 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] = trueon 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 dumpoutput: link- Screenshot: Engravers work detail (cropped out, but 'only selected do this' is enabled)
- 主要語言
- C++
- 星號
- 2.1k
- 分支
- 509
- 平均合併
- 3 天 17 小時
- 30 天內合併 PR
- 13
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
DFHack/dfhack 的其他 Issue
-
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 4 天內回覆
-
難度 2/5 1-3 小時 新手友好度 66/100
維護者通常 4 天內回覆
-
難度 5/5 一週以上 新手友好度 35/100
維護者通常 4 天內回覆
-
難度 5/5 一週以上 新手友好度 25/100
維護者通常 4 天內回覆
-
難度 4/5 3-5 天 新手友好度 48/100
維護者通常 4 天內回覆
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 78/100
godotengine/godot#125004 ·
維護者通常 1 天內回覆
-
44-x-y bug :beetle:
難度 1/5 1 小時以內 新手友好度 82/100
electron/electron#55528 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 70/100
維護者通常 5 天內回覆
-
ai_p2 bug comp-datalake
難度 2/5 1-3 小時 新手友好度 85/100
ClickHouse/ClickHouse#128306 · 1 則留言 ·
維護者通常 1 天內回覆
-
70 Instance - Raid - Outland
難度 1/5 1 小時以內 新手友好度 85/100
azerothcore/azerothcore-wotlk#28328 ·
維護者通常 1 天內回覆