Narrow tier2 runtime split to template bank state
This commit is contained in:
parent
5470cda6a6
commit
03fdcdf998
2 changed files with 115 additions and 0 deletions
|
|
@ -87,3 +87,94 @@ So the next Tier 2 recovery question is now tighter still:
|
|||
or cargo-membership/runtime-record reconstruction under
|
||||
`0x00437737 / 0x00412c10 / 0x00412bd0 / 0x00412d70 / 0x00412fb0`,
|
||||
rather than in the direct named availability bit for `Warehouse05` itself.
|
||||
|
||||
## Nearest Single-Import Peer Check
|
||||
|
||||
The same boundary now holds against the nearest single-import recipe peer too:
|
||||
|
||||
- `Louisiana.gmp`
|
||||
- `South East USA.gmp`
|
||||
|
||||
Direct `inspect-candidate-table` checks still keep the key port/warehouse rows aligned:
|
||||
|
||||
- `Warehouse05`
|
||||
- `Louisiana.gmp = 1`
|
||||
- `South East USA.gmp = 1`
|
||||
- `Port01`
|
||||
- `Louisiana.gmp = 1`
|
||||
- `South East USA.gmp = 1`
|
||||
|
||||
So even after the recipe-side frontier moved from “same coarse mode shape” to “same single-import
|
||||
family,” the direct named-availability table still does not provide the missing Tier 2 split for
|
||||
the shipped `5200 :: [7:0]` `Add Building Warehouse05` row.
|
||||
|
||||
That leaves the same later owners as the honest next focus:
|
||||
|
||||
- `0x00412d70` template-bank and runtime-record rebuild
|
||||
- `0x00411ce0 / 0x00411ee0` dependent mode-flag and cargo-summary refresh
|
||||
- `0x00412c10` latch refresh after those runtime records already exist
|
||||
|
||||
## Port Versus Warehouse Runtime Roots
|
||||
|
||||
One broader binary pass now closes the fixed-root ambiguity inside `0x00412d70`.
|
||||
|
||||
Direct `objdump` over `RT3.exe` shows the two built-in format roots are:
|
||||
|
||||
- `0x005c93d8 = "Warehouse%02d"`
|
||||
- `0x005c93e8 = "Port%02d"`
|
||||
|
||||
And the candidate rebuild chooses between them exactly as:
|
||||
|
||||
- if `[candidate+0xba] != 0`
|
||||
- use `Port%02d`
|
||||
- else
|
||||
- use `Warehouse%02d`
|
||||
|
||||
So the later Tier 2 runtime-record frontier is no longer an abstract “two built-in roots” question.
|
||||
It is specifically:
|
||||
|
||||
- how `0x00412d70` bank or template selection and the live availability bytes
|
||||
`[candidate+0xba/+0xbb]` determine which rebuilt candidates land on the `Warehouse%02d` side
|
||||
versus the `Port%02d` side
|
||||
- and why the `Warehouse%02d` side in `Louisiana.gmp` is the one that later lines up with the
|
||||
shipped `5200 :: [7:0]` `Add Building Warehouse05` strip
|
||||
|
||||
That also keeps the direct named-availability boundary honest:
|
||||
|
||||
- `Warehouse05 = 1` in the fixed scenario table still does not explain the runtime split by itself
|
||||
- the next meaningful owner seam is the later port-versus-warehouse runtime-record rebuild under
|
||||
`0x00412d70`, before `0x00412c10` mirrors anything into `[candidate+0x7ac]`
|
||||
|
||||
## Writer-Side Split Above The Availability Bytes
|
||||
|
||||
One more direct disassembly pass narrows that owner seam further.
|
||||
|
||||
`structure_candidate_stream_load_runtime_record_and_rebuild_cargo_state` `0x004120b0` does
|
||||
rebuild a substantial portion of each live candidate record:
|
||||
|
||||
- clears dependent runtime pointers and flags such as
|
||||
`[candidate+0x79c/+0x7a0/+0x78c/+0x790/+0x794/+0x7b0]`
|
||||
- reads the fixed per-record stream fields at
|
||||
`[candidate+0x04/+0x22/+0x26/+0x28/+0x2a/+0x2e/+0x32/+0x33]`
|
||||
- allocates and streams the packed `0xbc` descriptor array into `[candidate+0x37]`
|
||||
|
||||
But in the checked `0x004120b0` body there is still **no** write to:
|
||||
|
||||
- `[candidate+0xba]`
|
||||
- `[candidate+0xbb]`
|
||||
|
||||
So the current strongest ownership split is now:
|
||||
|
||||
- direct named-availability table `[state+0x66b2]` is not the missing differentiator by itself
|
||||
- per-record stream-load `0x004120b0` is also not where the port-versus-warehouse availability
|
||||
bytes are authored
|
||||
- the surviving writer-side frontier is the later template-bank path in `0x00412d70`, where the
|
||||
imported record is cloned or reused against one bank-qualified live candidate before the runtime
|
||||
descriptor and membership rebuilds run
|
||||
|
||||
That makes the next Tier 2 question more concrete still:
|
||||
|
||||
- how the bank-qualified template source selected under `[candidate+0xba]` versus `[candidate+0xbb]`
|
||||
seeds the later `Warehouse%02d` side in `Louisiana.gmp`
|
||||
- and whether that preserved bank/template state is the real bridge from the minimal recipe cluster
|
||||
to the shipped `5200 :: [7:0]` `Add Building Warehouse05` row
|
||||
|
|
|
|||
|
|
@ -660,6 +660,30 @@ Working rule:
|
|||
recover the later runtime-record / named-availability consequence under
|
||||
`0x00412d70 / 0x00412fb0 / 0x00412c10` that makes the minimal cluster land on
|
||||
`5200 :: [7:0]` only in `Louisiana.gmp`.
|
||||
- the direct named-availability table is still not that consequence:
|
||||
the nearest single-import peer `South East USA.gmp` keeps `Warehouse05 = 1` and `Port01 = 1`
|
||||
just like `Louisiana.gmp`, matching the earlier `Dutchlantis.gmp` read. So the next later
|
||||
Tier 2 question is now even narrower:
|
||||
recover the runtime-record bank/template consequences under `0x00412d70`
|
||||
(plus dependent `0x00411ce0 / 0x00411ee0`) before `0x00412c10` mirrors anything into
|
||||
`[candidate+0x7ac]`.
|
||||
- the `0x00412d70` runtime-record roots are grounded now too:
|
||||
direct `objdump` over `RT3.exe` shows `0x005c93d8 = "Warehouse%02d"` and
|
||||
`0x005c93e8 = "Port%02d"`, with the rebuild choosing the `Port%02d` root only when
|
||||
`[candidate+0xba] != 0` and the `Warehouse%02d` root otherwise. That turns the next queue head
|
||||
into a concrete port-versus-warehouse runtime-record question:
|
||||
recover how the bank/template pass and live availability bytes `[candidate+0xba/+0xbb]`
|
||||
make `Louisiana.gmp` land on the `Warehouse%02d` side that later lines up with
|
||||
`5200 :: [7:0]`.
|
||||
- the writer-side split is narrower now too:
|
||||
direct disassembly of `0x004120b0` shows that the per-record stream-load helper clears
|
||||
`[candidate+0x79c/+0x7a0/+0x78c/+0x790/+0x794/+0x7b0]`, restores the fixed fields through
|
||||
`[candidate+0x33]`, and streams the packed `0xbc` descriptor array into `[candidate+0x37]`,
|
||||
but does **not** write `[candidate+0xba/+0xbb]` in the checked body. So the next concrete
|
||||
recovery target is now the bank-qualified template source in `0x00412d70`, not the lower
|
||||
tagged-record reader:
|
||||
recover how preserved `[candidate+0xba/+0xbb]` bank/template state feeds the
|
||||
`Warehouse%02d` runtime side before `0x00411ee0 / 0x00411ce0 / 0x00412c10` run.
|
||||
kinds”; it is the smaller set of scenario-specific records where that sweep explicitly writes
|
||||
`[event+0x7ef]` itself or a still-later owner does.
|
||||
- two explicit trigger-kind materializations are now grounded inside that retagger:
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue