Rule out alternate Tier2 BCA import callers

This commit is contained in:
Jan Petykiewicz 2026-04-19 14:05:27 -07:00
commit 7769abd618
2 changed files with 18 additions and 0 deletions

View file

@ -723,6 +723,15 @@ Working rule:
`0x00437737 -> 0x00434f20 -> 0x00412c10` strip. So even the visible startup preseed still
consumes already-materialized bank/template bytes rather than explaining how they became
nonzero in the first place.
The constructor/import seam is fixed in the same negative way now too: `0x00438c70` allocates
the live candidate pool through `0x004131f0`, calls `0x004411d90` (currently a no-op stub),
and only then allocates the aux/source pool through `0x0041aa50`, so there is no hidden branch
between those two constructors. The only checked caller of source-record importer `0x00414490`
is `0x00419788`, and the surrounding `.rdata` proves that strip is the stock
`"%1*.bca"` / `".\\Data\\BuildingTypes\\"` scan rather than a map-specific alternate
package path. So the remaining Tier-2 mystery is not “which hidden caller invokes the BCA
parser?”; it is “which later non-stock writer or projection seam makes live
`[candidate+0xba/+0xbb]` diverge after the fixed stock BCA import has already run?”
So the honest next queue head is now one step earlier again:
recover the non-stock writer or restore-time projection owner that makes some live candidates
reach those later consumer strips with nonzero `[candidate+0xba/+0xbb]` despite the observed