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

Đang mở
  • Có gì không ổn?
#6,028 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 4 ngày

@ab9rf đang làm issue này rồi.

Từ ngày 31/10/2026.

  • #6029 của @ab9rf — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
57/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
cpp
Lĩnh vực
backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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
Ngôn ngữ chính
C++
Star
2.1k
Fork
509
Merge trung bình
3 ngày 17 giờ
Pull request đã merge (30 ngày)
13

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của DFHack/dfhack

Tất cả issue của DFHack/dfhack

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.