Tighten Tier2 checkpoint sequencing order
This commit is contained in:
parent
9c6acbd4b3
commit
25418c8c42
2 changed files with 29 additions and 2 deletions
|
|
@ -10,6 +10,8 @@ The earlier post-load recipe-runtime rebuild call at `0x00443ebc` runs:
|
|||
|
||||
- immediately after the named candidate-availability collection at `[world+0x66b2]`
|
||||
has been restored from fixed `0x22`-byte rows
|
||||
- by directly calling `0x00435630`
|
||||
- then calling `0x00412c10` only if live candidate pool `0x0062b268` is non-null
|
||||
- before the neighboring candidate filter/count rebuilds
|
||||
`0x00412c10 / 0x00412bd0`
|
||||
- before the year-derived follow-ons
|
||||
|
|
@ -27,11 +29,13 @@ The later explicit `0x197` checkpoint at `0x00444ac1` sits:
|
|||
- after the territory-side sweep
|
||||
`world_region_border_overlay_emit_segment_geometry_from_region_grid`
|
||||
`0x00487de0`
|
||||
- and then falls through into
|
||||
- and then directly reruns `0x00435630`
|
||||
- then falls through into
|
||||
`world_preseed_named_candidate_availability_records_from_live_pool`
|
||||
`0x00437737`
|
||||
- followed by the later candidate-side availability refresh
|
||||
- followed by the later unconditional candidate-side availability refresh
|
||||
`0x00412c10`
|
||||
- and then `0x00434d40`
|
||||
|
||||
So the late Tier 2 strip begins with named-availability preseed and latch refresh, not with the
|
||||
shell progress or territory overlay helpers that precede it.
|
||||
|
|
@ -70,4 +74,6 @@ The strongest remaining Tier 2 question is sequencing, not naming:
|
|||
`0x00435630 -> 0x00412d70`
|
||||
and the broader load-side rebuild owner
|
||||
`0x00412fb0`,
|
||||
with the early checkpoint only conditionally refreshing `0x00412c10` but the late checkpoint
|
||||
always rerunning `0x00435630 -> 0x00437737 -> 0x00412c10`,
|
||||
rather than on a direct `Warehouse05` availability bit or recipe-book display-name leak.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue