Tighten Tier2 stock decode boundary
This commit is contained in:
parent
2b57690c1d
commit
ce982ec32e
5 changed files with 22 additions and 6 deletions
|
|
@ -1426,6 +1426,15 @@
|
|||
tail-calling `0x00419230`. So the remaining Tier-2 source problem is increasingly “which stock
|
||||
rows that rebuild admits or seeds with nonzero bank bytes” rather than “which unrelated later
|
||||
service invokes the banked clone pass.”
|
||||
The source-decoder edge inside that handoff is tighter in the same direction too. Direct
|
||||
disassembly of `0x00414490` shows it already using the imported stock tail structurally rather
|
||||
than merely forwarding it: after importing `[record+0xb8/+0xb9/+0xba/+0xbb]`, it derives the
|
||||
optional-plane byte count from `[record+0xb8] * [record+0xb9] << 5`, allocates and zeroes the
|
||||
four optional plane buffers at `[record+0xcf/+0xd3/+0xd7/+0xdb]`, and then uses the high nibble
|
||||
of `[record+0xba]` while decoding those packed planes. So the remaining Tier-2 seam is not below
|
||||
“raw stock bytes exist at all”; it is above a source decoder that already materializes the
|
||||
shape-plane state before the later `0x00416ce0` bare-name remap and `0x00419230` rebank-or-clone
|
||||
pass.
|
||||
The stock owner chain above those parser fields is explicit now too:
|
||||
`0x00438c8e -> 0x004131f0 -> 0x00412fb0 -> 0x004120b0` constructs root `0x0062b268`, and the
|
||||
adjacent `.rdata` strings at `0x005c93f4..0x005c940e` prove that `0x00412fb0` is the
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue