Scan numbered candidate table run families
This commit is contained in:
parent
87a5667c9e
commit
dd973ad44b
3 changed files with 264 additions and 1 deletions
|
|
@ -1244,6 +1244,17 @@
|
|||
problem is no longer whether those names exist as stable scenario rows; it is how that fixed
|
||||
candidate-table cluster is projected into the later aux-record bank and then into the live clone
|
||||
families.
|
||||
The root scan narrows the real corpus for that question too. `runtime scan-candidate-table-headers
|
||||
rt3_wineprefix/drive_c/rt3/maps` shows `37` probe-bearing shipped maps and `4` skips, while the
|
||||
narrower `runtime scan-candidate-table-named-runs` command confirms that `Louisiana.gmp` and
|
||||
`Dutchlantis.gmp` share the same split shape:
|
||||
isolated `Port00` at row `35`, contiguous `Port01..11` at rows `45..55`, isolated
|
||||
`Warehouse00` at row `43`, and contiguous `Warehouse01..11` at rows `56..66`. Raw string
|
||||
presence is broader than that actual fixed-candidate-table seam too: `Port00` appears in all
|
||||
`41` shipped `.gmp` files, but `Central Pacific.gmp`, `Italy.gmp`, `Tex-Mex.gmp`, and
|
||||
`Texas Tea.gmp` do not expose the fixed candidate-table header at all. So the next Tier-2
|
||||
source pass should target the `37` probe-bearing maps rather than the noisier full
|
||||
string-bearing map corpus.
|
||||
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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue