Repository navigation
building-plan material filters broken in reclaimed fort - probably persistence api #5716
Description
Something goes wrong in building plan (and possibly other tools) when loading a reclaimed fort for the first time. The material filter options on the "Global settings" tab of the building plan filter dialogs are inoperative immediately after reclaiming a site. Clicking any of these buttons results in no change on the screen and the message "all contruction materials disabled; resetting config" is printed to the console each time a button is pressed.
Furthermore, during initial fortress load, the following errors are logged to the console, during or immediately after running onLoad.init
<path>\hack\lua\dfhack.lua:804: unable to save data in key 'autotraining'
stack traceback:
[C]: in field '?'
<path>\hack\lua\dfhack.lua:804: in upvalue 'persistent_saveData'
<path>\hack\lua\dfhack.lua:818: in field 'saveSiteData'
<path>/hack/scripts/autotraining.lua:51: in global 'persist_state'
<path>/scripts/autotraining.lua:90: in function <E:/Kelly/DF/df_53_10_steam/hack/scripts/autotraining.lua:72>
true
<path>\hack\lua\dfhack.lua:804: unable to save data in key 'buildingplan/quick-filters'
stack traceback:
[C]: in field '?'
<path>\hack\lua\dfhack.lua:804: in upvalue 'persistent_saveData'
<path>\hack\lua\dfhack.lua:818: in field 'saveSiteData'
<path>\hack\lua\plugins\buildingplan\planneroverlay.lua:490: in function <<path>\hack\lua\plugins\buildingplan\planneroverlay.lua:477>
I don't know where that "true" came from. That itself is kinda weird. The fact that autotraining is also generating an error suggests that the problem is with the common API both use rather than with either tool itself.
Best guess this is an issue with the persistence API not working correctly in a newly reclaimed fort. The problem resolves when the fortress is saved and reloaded, so this is likely due to something along the lines of that a reclaimed procedurally generated fortress doesn't have a cosave yet, but the API is expecting there to be be one.
Activity
Alistair-Afton commentedon Sep 16, 2026
Confirmed and fixed in #5923.
The problem isn't a missing cosave — it's that
plotinfo->site_id(yoursiteid) stays-1on a newly reclaimed fortress until the first save.World::GetCurrentSiteId()returns that -1 verbatim in fortress mode, sois_good_entity_idrejects it and everysaveSiteData/getSiteDatacall errors out — which is exactly theunable to save datatracebacks fromautotrainingandbuildingplan. And sinceIsSiteLoaded()is false atSC_MAP_LOADED, the site-scoped persistence data is never loaded at all, which is why the buildingplan filter config stays empty (all material categories read as disabled → "resetting config" on every click).The fix:
plotinfo->main.fortress_siteis already set at embark time on a reclaim and points at the reclaimed site record — the sameworld_sitethatsite_idresolves to after the first save.GetCurrentSiteIdnow falls back tofortress_site->idwhensite_idis negative, so site persistence works for the whole initial session.Verified live: with
site_idforced to -1 on a loaded fort,saveSiteDataproduced the reported error before the fix and round-trips correctly through the site entity after it.persistence: fall back to fortress_site when site_id is unassigned
persistence: fall back to fortress_site when site_id is unassigned