Probe stock building header families

This commit is contained in:
Jan Petykiewicz 2026-04-19 15:05:48 -07:00
commit 6c7ebb75b5
4 changed files with 131 additions and 0 deletions

View file

@ -75,6 +75,15 @@
`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 new `.bty` header probes now tighten that stock source split too: `Port.bty` and
`Warehouse.bty` both probe as ordinary `type_id = 0x000003ec` rows with direct bare-name
headers and shared `dword_0xbb = 0x000001f4`, while the style-station families such as
`VictorianStationSml/Med/Lrg.bty` stay on the same `0x000003ec` family but keep
`name_0x7c = VictorianStations` and zero `dword_0xbb`. `Maintenance.bty` and
`ServiceTower.bty` likewise stay in the same stock family, but expose display names
`Maintenance Facility` and `Service Tower` with zero `dword_0xbb`. So the later numbered
`Port%02d` / `Warehouse%02d` clone seam is now bounded above the bare `Port` / `Warehouse`
family itself rather than under a hidden station-style alias family in `BuildingTypes`.
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

View file

@ -1307,6 +1307,17 @@
`0x005f3c6c/0x005f3c80` pair is no longer an anonymous bank-byte helper; it is the stock
style-family-to-combined-name resolver immediately below the remaining Tier-2 source-selection
frontier.
The recovered `.bty` header probes now sharpen that frontier too. `Port.bty` and
`Warehouse.bty` probe as ordinary `type_id = 0x000003ec` rows with direct bare-name headers
(`name_0x22` / `name_0x7c` = `Port` or `Warehouse`) and shared `dword_0xbb = 0x000001f4`,
while `VictorianStationSml/Med/Lrg.bty` stay on the same `0x000003ec` family but keep
`name_0x7c = VictorianStations` and `dword_0xbb = 0x00000000`. The standalone
`Maintenance.bty` / `ServiceTower.bty` rows also stay in that stock family, but their display
names are `Maintenance Facility` and `Service Tower` and their `dword_0xbb` lane remains zero.
So the numbered `Port%02d` / `Warehouse%02d` seam is no longer plausibly a hidden station-style
alias family under the stock assets; the remaining open question is why the later clone chooser
favors the bare `Port` / `Warehouse` family over those zero-valued station and maintenance /
service rows.
The direct `+0xba/+0xbb` writer census now rules out a broad false lead too. The obvious new
stores at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side
portrait/string refresh helpers over a different id-keyed collection rooted through

View file

@ -843,6 +843,18 @@ Working rule:
`0x005f3c6c/0x005f3c80` pair is no longer an anonymous bank byte table; it is the stock
style-family-to-combined-name resolver that sits immediately below the remaining Tier-2 source
selection frontier.
The recovered `.bty` header probes tighten that source split further too. The checked-in
`inspect-building-type-sources` report now shows `Port.bty` and `Warehouse.bty` are ordinary
`type_id = 0x000003ec` rows with direct bare-name headers (`name_0x22` / `name_0x7c` =
`Port` or `Warehouse`) and shared `dword_0xbb = 0x000001f4`, while the style-station rows such
as `VictorianStationSml/Med/Lrg.bty` stay on the same `0x000003ec` family but keep
`name_0x7c = VictorianStations` and `dword_0xbb = 0x00000000`. The standalone
`Maintenance.bty` / `ServiceTower.bty` rows also stay in the same stock family, but expose
display names `Maintenance Facility` and `Service Tower` with zero `dword_0xbb`. So the
remaining Tier-2 source question is no longer whether the numbered `Port%02d` /
`Warehouse%02d` banks are hidden station-style aliases; it is why the later clone path prefers
the bare `Port` / `Warehouse` family over the zero-valued station and maintenance/service
families when it seeds those numbered banks.
The direct `+0xba/+0xbb` writer census is narrower now too. The obvious newly surfaced stores
at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side portrait/string
refresh helpers: they walk a separate id-keyed collection through `0x0053f830`, free and