Rule out event branch in region restore strip

This commit is contained in:
Jan Petykiewicz 2026-04-19 12:55:36 -07:00
commit 499462fae5
3 changed files with 12 additions and 0 deletions

View file

@ -1363,6 +1363,11 @@ The same brush strip is tighter now too:
per-cell compatibility bits through the byte-level helpers
`0x00448c20/0x00448cb0/0x00448d90/0x00448e60/0x00448e90/0x0044de30`, with the older pre-`0x400`
branch explicitly clearing those newer bits back to the legacy fallback pattern.
The `0x00444887` continuation is ruled down further now too: after the region, territory, and
support refresh owners, its next loader `0x00433130` is only the packed runtime-event restore
path, opening `0x4e99/0x4e9a`, repopulating live event collection `0x0062be18` through
`0x0042db20`, and closing `0x4e9b`. So that event-side branch is not the missing later region
restore handoff for `[region+0x2a4]` or `[region+0x310/+0x338/+0x360]` either.
One adjacent mid-restore preview branch is explicit now too: for version `>= 0x3ee` the loader
restores one width/height-tagged dword surface, optionally resamples it through
`shell_world_presentation_stage_overlay_rect_from_normalized_bounds` `0x00534930`, republishes it

View file

@ -1552,6 +1552,12 @@ Working rule:
`[region+0x317/+0x31b]` band through `0x00420350`. So the next region pass should treat the
broader `0x00444887` continuation as the live handoff seam when chasing
`[region+0x2a4]` and `[region+0x310/+0x338/+0x360]`, not as just another generic restore note.
- That same continuation is less ambiguous now too: the loader immediately after territory/support
refresh, `0x00433130`, is only
`scenario_event_collection_refresh_runtime_records_from_packed_state`, opening `0x4e99/0x4e9a`,
repopulating live event collection `0x0062be18` through `0x0042db20`, and closing `0x4e9b`.
So the event-side branch under `0x00444887` is ruled out as the missing later region restore
handoff too.
- That same continuation is slightly less symmetric now too: the atlas-backed territory side at
`0x00487c20` currently restores only collection metadata/live ids and still uses no-op per-entry
load/save callbacks `0x00487670/0x00487680`, so the next pass should bias more heavily toward