diff --git a/docs/control-loop-atlas/map-and-scenario-content-load.md b/docs/control-loop-atlas/map-and-scenario-content-load.md index b01dd1e..fa780ec 100644 --- a/docs/control-loop-atlas/map-and-scenario-content-load.md +++ b/docs/control-loop-atlas/map-and-scenario-content-load.md @@ -64,6 +64,17 @@ `StationLrg`, `ServiceTower`, `Maintenance`, `ClpBrd`, `Kyoto`, `Persian`, `SoWest`, `Tudor`, and `Victorian`, so the remaining Tier-2 load-side question is the style-family row-selection path into that later bank pass rather than another hidden naming stage. + The shipped asset directory makes the bare-name remap boundary explicit too: + `Data/BuildingTypes` contains bare `Port.bty/.bca` and `Warehouse.bty/.bca`, but no stock + `Port00` or `Warehouse00` assets on disk, so the loader-side `port -> Port00` and + `warehouse -> Warehouse00` rewrite is the real stock bridge. + The stock asset corpus agrees with that table directly too: `Data/BuildingTypes` contains + `VictorianStationSml/Med/Lrg.bty`, `TudorStationSml/Med/Lrg.bty`, + `SoWestStationSml/Med/Lrg.bty`, `PersianStationSml/Med/Lrg.bty`, + `KyotoStationSml/Med/Lrg.bty`, `ClpBrdStationSml/Med/Lrg.bty`, plus standalone + `Maintenance.bty` and `ServiceTower.bty`, alongside the style-specific house families. So the + recovered `0x005f3c6c/0x005f3c80` naming strip is now backed by the shipped on-disk + `BuildingTypes` filename families, not only by the loader-side disassembly. The fixed tail is explicit now too: `0x00444dd0` writes one direct dword from `[world+0x19]`, one zeroed `0x1f4`-byte slab under `0x32cf`, closes the package, derives the diff --git a/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md b/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md index d2124d9..a7b7500 100644 --- a/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md +++ b/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md @@ -1282,6 +1282,10 @@ stay in `named_binding_comparison.binding_only_canonical_stems`. So the numbered Tier-2 families no longer belong under stock `BuildingTypes/*.bty` discovery either; they belong under the scenario/live candidate-table projection seam above the now-grounded bare-name remap. + The shipped asset directory makes that remap boundary explicit too: `Data/BuildingTypes` + contains bare `Port.bty/.bca` and `Warehouse.bty/.bca`, but no stock `Port00` or + `Warehouse00` assets on disk. So the loader-side `port -> Port00` and `warehouse -> Warehouse00` + rewrite is the actual stock bridge, not a hidden numbered asset family. The stock source-family loader above that remap is bounded now too. `0x004196c0` walks the `%1*.bty` file set, routes each match through `0x00414490`, calls the stock load callback `0x00416ce0`, and only then tails into `0x00419230`. The currently recovered source-name set is @@ -1289,6 +1293,13 @@ `Persian`, `SoWest`, `Tudor`, and `Victorian`, so the remaining Tier-2 source frontier is the style-family row-selection path into the later banked clone pass, not another hidden name generator. + The shipped asset corpus agrees with that table directly too: `Data/BuildingTypes` contains + `VictorianStationSml/Med/Lrg.bty`, `TudorStationSml/Med/Lrg.bty`, + `SoWestStationSml/Med/Lrg.bty`, `PersianStationSml/Med/Lrg.bty`, + `KyotoStationSml/Med/Lrg.bty`, `ClpBrdStationSml/Med/Lrg.bty`, plus standalone + `Maintenance.bty` and `ServiceTower.bty`, alongside the style-specific house families. So the + `0x005f3c6c/0x005f3c80` pair now lines up with real stock filename families on disk rather than + only a disassembly-side naming hypothesis. The exact-match helper under that family is bounded now too. `0x00419590` copies one source-kind name from `0x005f3c6c`, combines it with one style/theme entry from the smaller subset table `0x005f3c80` through format `"%1%2"` at `0x005c8730`, and then scans the live diff --git a/docs/rehost-queue.md b/docs/rehost-queue.md index 2dabe13..f1ba5f2 100644 --- a/docs/rehost-queue.md +++ b/docs/rehost-queue.md @@ -816,6 +816,11 @@ Working rule: stock `BuildingTypes/*.bty` discovery for the numbered families either; the remaining `01..11` source work belongs under scenario/live candidate-table projection and row-family choice above the already-grounded bare-name remap. + The shipped asset directory makes that remap boundary explicit too: `Data/BuildingTypes` + contains bare `Port.bty/.bca` and `Warehouse.bty/.bca`, but no stock `Port00` or + `Warehouse00` assets on disk. So the checked-in queue no longer needs to speculate about a + hidden on-disk `00` family; the loader-side `port -> Port00` and `warehouse -> Warehouse00` + rewrite is the actual stock bridge. The stock source-family strip above that remap is grounded now too. `0x004196c0` walks the `%1*.bty` file set, routes each match through `0x00414490`, calls the stock load callback `0x00416ce0`, and only then tails into `0x00419230`. The recovered source-name table is @@ -823,6 +828,14 @@ Working rule: `Persian`, `SoWest`, `Tudor`, and `Victorian`, so the next Tier-2 source question is no longer “where do numbered names come from?” but “which style-family rows first survive into the later two-bank, twelve-ordinal clone pass?” + The stock asset corpus now agrees with that table directly too. The shipped + `Data/BuildingTypes` directory contains `VictorianStationSml/Med/Lrg.bty`, + `TudorStationSml/Med/Lrg.bty`, `SoWestStationSml/Med/Lrg.bty`, + `PersianStationSml/Med/Lrg.bty`, `KyotoStationSml/Med/Lrg.bty`, + `ClpBrdStationSml/Med/Lrg.bty`, plus standalone `Maintenance.bty` and + `ServiceTower.bty`, alongside the style-specific house families. So the + `0x005f3c6c/0x005f3c80` tables are no longer just a recovered naming hypothesis; they line up + with real stock filename families on disk. The exact-match resolver beneath that style-family strip is grounded now too. `0x00419590` copies one source-kind name from `0x005f3c6c`, combines it with one style/theme entry from the smaller subset table `0x005f3c80` through format `"%1%2"` at `0x005c8730`, and then scans the