jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Rule out base placed-structure load callback

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 12:50:46 -07:00
commit 39fdf444ba
3 changed files with 16 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

7
docs/control-loop-atlas/runtime-roots-camera-and-support-families.md
View file

@ -3712,6 +3712,13 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
`[world+0x217d/+0x2181]` gated by mode byte `[world+0x2175]`; they can clear or republish
currently-selected site ids through `0x00413620 / 0x00413750`, but they do not repopulate
`[site+0x276]` for already-restored rows.
The base load callback underneath the same family is narrower now too. Local `.rdata` at
`0x005cb4c0` shows that the shared base table, not the `0x005c8c50` specialization table, owns
the `0x0045c150 / 0x0045b560 / 0x00455870 / 0x00455930` load-save quartet. Direct disassembly of
`0x0045c150 -> 0x00455fc0` then shows that callback only reloads the generic
`0x55f1/0x55f2/0x55f3` triplet/scalar bands and re-enters the same base triplet/scalar slots
`0x00455870 / 0x00455930`, so the missing placed-structure owner-company lane `[site+0x276]`
still lies outside the checked-in base load path.
On the wider chooser question, the current evidence is also tighter than before: every recovered
external owner of `0x00402cb0` is still in the city-connection family, so the two later direct
placement lanes currently read as city-connection fallback behavior rather than a broadly shared

6
docs/rehost-queue.md
View file

@ -67,6 +67,12 @@ Working rule:
world-side helpers `0x00452d80 / 0x00452db0 / 0x00452fa0` are live selected-site or active
service-state setters/dispatchers over `[world+0x217d/+0x2181]` gated by mode byte
`[world+0x2175]`, not restore-time republishers for `[site+0x276]`
- the base placed-structure load callback is narrower now too:
local `.rdata` at `0x005cb4c0` shows the shared base table, not the `0x005c8c50`
specialization table, owns the `0x0045c150 / 0x0045b560 / 0x00455870 / 0x00455930`
load-save quartet; direct disassembly of `0x0045c150 -> 0x00455fc0` shows that callback only
reloads the generic `0x55f1/0x55f2/0x55f3` triplet/scalar bands and then re-enters the base
triplet/scalar slots `0x00455870 / 0x00455930`, so it does not repopulate `[site+0x276]`
- that makes the next linked-transit question narrower:
identify which earlier restore or service owner feeds `[site+0x276]` and the live linked-peer
rows before replay continuation `0x0040e360..0x0040edf6`, beyond the already-grounded