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

Refine next owner questions for blocked seams

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 12:56:43 -07:00
commit 4d98967c41
3 changed files with 34 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

10
docs/control-loop-atlas/post-load-generation-paintterrain-and-save-load-restore.md
View file

@ -73,7 +73,15 @@ The same brush strip is tighter now too:
`[region+0x316]` is still clear, the same owner publishes one alternate one-shot notice from the
same amount and region scalar before setting `[region+0x316]`. So the pending-region bonus lane
is no longer just a queued setup artifact: it has a concrete later service owner and an explicit
shell-facing fallback above the same queue family now too. `0x00438710` is the recurring queue
shell-facing fallback above the same queue family now too. That narrows the next closure target
as well: ordinary-save probes can stop treating `[world+0x66a6]` persistence as the primary
blocker, because the checked-in negative results on `q.gms`, `p.gms`, and `Autosave.gms` now make
the pending-bonus owner plus its peer/linkage strip the first safe static target instead. The
next pass should therefore ask only three concrete questions: which persisted owner seam rebuilds
or restores `[region+0x25e/+0x276/+0x302/+0x316]`, which stable region id or class discriminator
survives save/load strongly enough to drive `0x004358d0`, and how far the city-connection peer
helpers `0x00420030/0x00420280` plus linked-company resolver `0x0047efe0` can be reused
directly before the transient queued-notice family matters again. `0x00438710` is the recurring queue
service owner above `[world+0x66a6]` and `[world+0x66aa]`; the short dirty-mark path is tighter
now as well, because it checks the per-node promotion-latch dword `[node+0x0c] == 1` rather than
reusing the queue kind field. `0x00438840` is the tiny

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

@ -2911,6 +2911,18 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
The smaller attach helper `0x00490a3c` is now bounded too: it conditionally allocates one
`Infrastructure` child from a caller-supplied payload stem, attaches it to the current owner, and
then seeds three caller-supplied position lanes through `0x00539530` and `0x0053a5b0`. The
remaining closure target above the grounded `0x38a5` side-buffer seam is therefore narrower now:
the next safe static pass should start at this exact attach/rebuild strip, not at the whole
placed-structure family. The key open questions are whether the compact-prefix/name-pair groups
feed the first-child triplet clone lane, the caller-supplied payload-stem lane, or only the
later route/local-runtime follow-on family; whether cached primary-child slot `[this+0x248]`
becomes the first owner-visible bridge between those side-buffer groups and route-entry rebuild;
and which child fields or grouped rows absorb the side-buffer payload before
`0x00448a70/0x00493660/0x0048b660` become relevant. That keeps the top-ranked next mapping target
explicit as `0x0048a1e0`, `0x0048dd50`, and `0x00490a3c`, with the serializer/load companions and
route/local-runtime follow-ons staying secondary until one concrete child-consumer bridge is
grounded.
The
direct route-entry side of the same family is no longer anonymous either: `0x0048e140`,
`0x0048e160`, and `0x0048e180` are the three direct resolvers over owner fields
`[this+0x206/+0x20a/+0x20e]` into the live route-entry collection `0x006cfca8`. Another shared