jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Align Tier2 source tables with stock assets

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 14:56:06 -07:00
commit 86fd2321e3
3 changed files with 35 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

11
docs/control-loop-atlas/map-and-scenario-content-load.md
View file

@ -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

11
docs/control-loop-atlas/runtime-roots-camera-and-support-families.md
View file

@ -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

13
docs/rehost-queue.md
View file

@ -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