Link infrastructure footer gate to presentation owner
This commit is contained in:
parent
ebee1a3a58
commit
52d47b6f91
2 changed files with 8 additions and 1 deletions
|
|
@ -222,10 +222,15 @@ Working rule:
|
|||
`[owner+0x3692]` is set, or bit `0x20` in `[child+0x20]` is set; the sibling loop
|
||||
`0x00529730` only takes the later `0x530280` follow-on when bit `0x40` in `[child+0x20]` is
|
||||
set.
|
||||
- That footer-bit consumer strip is tied to a broader higher-layer owner family now too:
|
||||
`0x005295f0..0x005297b7` repopulates candidate cells through `0x00533ba0`, walks candidate
|
||||
child lists through `0x00556ef0/0x00556f00`, and honors the same controller mode byte
|
||||
`[owner+0x3692]` that the atlas already places under the world-window presentation dispatcher.
|
||||
- That means the remaining infrastructure question is no longer both footer bytes. It is
|
||||
specifically why the stable `0x000055f3 / 0x0001 / 0xff` tunnel family sets the first footer
|
||||
byte / bit-`0x20` admission gate while the sparse `0xff0000ff / 0x0001 / 0xff` outlier class
|
||||
clears it.
|
||||
clears it, inside that nearby-presentation/controller owner family rather than at the serializer
|
||||
layer.
|
||||
- Source-side constructor analysis is narrower now too. `0x00490960` takes:
|
||||
- mode at stack arg 1
|
||||
- stem at stack arg 2
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue