persistence: fall back to fortress_site when site_id is unassigned

docs/changelog.txt

@@ -69,6 +69,7 @@ Template for new versions:
 - `aquifer`: make ``--skip-top`` and top-relative ``--levels`` take effect for the ``drain``, ``convert``, and ``add`` actions instead of being silently ignored
 - `autodump`: ``destroy`` no longer leaves the contents of destroyed containers in limbo or crashes when destroying unit-held items
 - `timestream`: deal properly with units who have breathing difficulties
+- Fixed persistent site data API (``dfhack.persistent.saveSiteData``/``getSiteData``) failing on newly reclaimed fortresses until the first save
 
 ## Misc Improvements
 - Added ``Coord2d`` and ``Coord3d`` C++ templates, providing a standard set operations for 2-tuples and 3-tuples of any numeric type

library/modules/World.cpp

@@ -217,8 +217,15 @@ df::unit * World::getAdventurer() {
 int32_t World::GetCurrentSiteId() {
     if (!plotinfo)
         return -1;
-    if (isFortressMode())
-        return plotinfo->site_id;
+    if (isFortressMode()) {
+        // on a reclaimed fortress, site_id isn't assigned until the first
+        // save; fortress_site is set at embark, so use it as a fallback
+        if (plotinfo->site_id >= 0)
+            return plotinfo->site_id;
+        if (auto site = plotinfo->main.fortress_site)
+            return site->id;
+        return -1;
+    }
     if (auto adv = getAdventurer(); adv && world->world_data) {
         DEBUG(world).print("searching for adventure site\n");
         auto & world_map = world->map;