Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta Adatta ai principianti
  • Qualcosa non va?
#6,022 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
78/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
lua
Ambito
tooling

Direzione di ricerca

Inizia con add-recipe.lua e confronta il ciclo di inserimento single con il controllo addItems che protegge gli inserimenti in blocco. Il report identifica le voci duplicate in historical_entity.resources come il bug confermato; verifica il comportamento e fai sì che il completamento significhi che comandi single ripetuti non aggiungano un’altra copia. Il routing di digger e i controlli nil sono risultati aggiuntivi nello stesso file che potrebbero richiedere un ambito separato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C++
Stelle
2.1k
Fork
509
Merge medio
2g 13h
PR unite (30g)
28

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DFHack/dfhack

Tutte le issue di DFHack/dfhack

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.