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