Split post-load chairman and subtype latch branches

This commit is contained in:
Jan Petykiewicz 2026-04-19 12:44:39 -07:00
commit 15643a6df6
3 changed files with 13 additions and 0 deletions

View file

@ -5910,6 +5910,7 @@ fn build_region_service_trace_report(
"the checked-in shell-load subgraph and function map now place world_load_saved_runtime_state_bundle 0x00446d40 directly ahead of world_run_post_load_generation_pipeline 0x004384d0, so the first later non-hook owner family after the ruled-down 0x00444887 continuation is the post-load generation strip rather than another tagged region payload callback".to_string(),
"0x004384d0 already exposes the stage ordering tightly enough to subdivide the next search: id 319 refreshes the route-entry collection, auxiliary route trackers, and then 0x004133b0 placed-structure local-runtime replay; id 320 runs 0x00421c20(1.0, 1) for the region-owned building setup strip; id 321 runs 0x00437b20 and then sweeps regions through 0x00423d30".to_string(),
"the 319 placed-structure replay strip is now grounded as more than generic setup glue: 0x004133b0 drains queued site ids through 0x0040e450, sweeps every live placed structure through 0x0040ee10, and then reaches the already-grounded linked-site follow-on 0x00480710, which is a stronger structural bridge into acquisition-side site or peer state than the ruled-down territory/support loaders".to_string(),
"the surrounding 319 helpers are ruled down further now too: 0x00437220 and 0x004377a0 stay on chairman-slot selector/profile materialization over [world+0x69d8/+0x69db] and scenario selector bytes [0x006cec7c+0x87], while 0x00434d40 only seeds the subtype-2 candidate runtime latch [candidate+0x7b0] after the later burst".to_string(),
"the 320 building setup strip is narrower but still relevant: 0x00421c20 dispatches every live region into 0x004235c0, and that worker consults the region profile collection [region+0x37f], the placed-instance registry 0x0062b26c, and demand-balancing helpers like 0x00422900/0x00422be0/0x00422ee0, so current evidence keeps it in the same acquisition-adjacent owner family even though it is not yet a direct writer to [region+0x2a4] or [region+0x310/+0x338/+0x360]".to_string(),
"direct worker recovery now narrows 0x004235c0 further: it stays inside the live region demand-and-placement family by routing through 0x00422900 cached category accumulation, 0x004234e0 projected structure-count scalars, 0x00422be0 placed-count subtraction, and 0x00422ee0 placement attempts over 0x0062b26c rather than any restore-time field republisher".to_string(),
"the 321 economy-seeding tail is also now bounded as a narrower cache refresh rather than generic noise: 0x00437b20 only stages a fast-forward guard and then sweeps 0x0062bae0 through 0x00423d30, which refreshes the cached category band [region+0x27a/+0x27e/+0x282/+0x286], so it remains a weaker but still explicit post-load owner family to rule in or out before returning to the deeper 0x00446d40 continuation".to_string(),

View file

@ -797,6 +797,12 @@ The same brush strip is tighter now too:
`[region+0x27a/+0x27e/+0x282/+0x286]` through `0x00422900`. So these post-load branches stay
ruled down as setup and cache-maintenance work rather than the missing restore-time republisher
for `[region+0x2a4]` or `[region+0x310/+0x338/+0x360]`.
The surrounding `319` helpers are narrower in the same negative way now too: `0x00437220` and
`0x004377a0` stay on chairman-slot selector and profile materialization over
`[world+0x69d8/+0x69db]` and scenario selector bytes `[0x006cec7c+0x87]`, while `0x00434d40`
only seeds the subtype-`2` candidate runtime latch `[candidate+0x7b0]` across live placed
structures. That leaves the placed-structure replay strip `0x004133b0` as the only region-
adjacent bridge inside the `319` plateau worth chasing for the missing restore seam.
The
editor-side read path is explicit on the same seam:
`map_editor_economic_cost_panel_refresh_preview_curve_and_numeric_rows` `0x004caaf0` reads the

View file

@ -1565,6 +1565,12 @@ Working rule:
`[region+0x27a/+0x27e/+0x282/+0x286]`. So the next non-hook region work should start from the
post-load `319` placed-structure replay seam and only then revisit the narrower region-side
`320/321` branches if the exact field bridge is still missing.
- The `319` plateau is split more cleanly now too: its neighboring world helpers are no longer
plausible region-body owners. `0x00437220` and `0x004377a0` are the chairman-slot selector and
profile materialization family over `[world+0x69d8]`, `[world+0x69db]`, and scenario selector
bytes `[0x006cec7c+0x87]`, while `0x00434d40` is only the subtype-`2` candidate runtime-latch
seeder over live placed structures. That leaves `0x004133b0` as the only region-adjacent `319`
bridge worth chasing for the missing restore seam.
- The `320` branch is narrower than that headline now too: direct worker recovery shows
`0x004235c0` staying inside the live region demand-and-placement family by routing through
`0x00422900` cached category accumulation, `0x004234e0` projected structure-count scalars,