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

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