Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

add-recipe single inserts a duplicate when the civ already knows the recipe

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#6,022 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 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
78/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ệ
lua
Lĩnh vực
tooling

Hướng nghiên cứu

Bắt đầu với add-recipe.lua và so sánh vòng lặp chèn single với bước kiểm tra addItems bảo vệ các lần chèn hàng loạt. Báo cáo xác định các mục trùng lặp trong historical_entity.resources là lỗi đã được xác nhận; hãy kiểm tra hành vi và bảo đảm rằng hoàn thành có nghĩa là các lệnh single lặp lại không thêm bản sao nào nữa. Định tuyến digger và các kiểm tra nil là những phát hiện bổ sung trong cùng tệp, có thể cần phạm vi riêng.

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

Mô tả

add-recipe single <TYPE>:<ID> appends to the civ's resource vector without checking whether the subtype is already in there. Run it twice for the same item and you get two copies in historical_entity.resources.<x>_type.

Confirmed in game (DF + DFHack, fortress mode). Running

add-recipe single SHOES:ITEM_SHOES_BOOTS

twice on an item the civ already knew gave me a visible duplicate entry.

The single path in add-recipe.lua is upfront about skipping the check:

local addedItem = nil
--assume the user knows what they're doing, so no need for sanity checks
for _, item in ipairs(all) do
  if (item.id == itemId) then
    known:insert('#', item.subtype)
    addedItem = item
    break
  end
end

The bulk paths are fine. addItems guards with not checkKnown(known, subtype) before inserting, so this is specific to single.

The duplicates are mostly cosmetic, but they stick around in the save and there's no in-game way to see them or get rid of them.

Adding a checkKnown(known, item.subtype) call in that loop would make it behave like all/native.

Two smaller things in the same file, from reading it rather than playing. Happy to split either out into its own issue.

1. single doesn't route diggers. It looks the category up in the categories table, and there's no digger entry there, so WEAPON:ITEM_WEAPON_PICK ends up in resources.weapon_type. addItems deliberately sends mining weapons to resources.digger_type instead, with the comment "prevents picks from being duplicated, and puts great picks in correct category". Something does read that field: internal/quickfort/stockflow.lua:306 uses resources.digger_type to build MakeWeapon orders for diggers. So the two vectors aren't interchangeable.

Partial in-game note: add-recipe single WEAPON:ITEM_WEAPON_PICK on a civ that already knew picks did not produce a duplicate among the known diggers, which is what you'd expect if the subtype went into weapon_type instead. I did not separately confirm that it appeared under weapons, so treat that half as unverified.

2. Two nil checks that can't fire. Lines 4-12:

local resources = df.historical_entity.find(df.global.plotinfo.civ_id).resources
local civ = df.historical_entity.find(df.global.plotinfo.civ_id).entity_raw
...
if (resources == nil) then
  qerror("Could not find entity resources")
elseif (civ == nil) then

If find returns nil, line 4 has already thrown attempt to index a nil value. So running add-recipe with no fortress loaded gets you a Lua traceback instead of either of the qerror messages that were meant to come out.

I checked whether this is a general pattern before bringing it up: of the 439 scripts in DFHack/scripts, 70 sites dereference a find() result in the same expression, and add-recipe.lua is the only one that then nil-tests the result. The rest either guard first or have an argument that can't be nil. So it's one file, not a sweep.

Context: this came out of review on DFHack/scripts#1603, where @chdoc asked for it to be filed rather than worked around in the GUI.

Disclosure: I used AI assistance (Claude) for the code reading and for drafting this write-up. I verified the main bug in game myself, and I'm the one filing it.

Ngôn ngữ chính
C++
Star
2.1k
Fork
509
Merge trung bình
2 ngày 13 giờ
Pull request đã merge (30 ngày)
28

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.