Expose region policy dword candidates

This commit is contained in:
Jan Petykiewicz 2026-04-18 19:30:45 -07:00
commit a1cd21549a
2 changed files with 62 additions and 4 deletions

View file

@ -546,9 +546,16 @@ Working rule:
owner that rebuilds those latches or the separate tagged body seam that persists them.
- The save-side region payload probe is wider now too: the checked-in `region_record_triplets`
surface no longer stops at raw pre-name prefix bytes and now also emits structured prefix dword
candidates per record. That gives the next region payload pass a direct way to compare the
opaque pre-`0x55f1` band against the remaining acquisition-side lane shapes instead of redoing
raw hex inspection by hand.
candidates per record, and the fixed `0x55f2` policy chunk now also carries structured reserved
dword candidates instead of raw integers only. That gives the next region payload pass a direct
way to compare both opaque payload bands against the remaining acquisition-side lane shapes
instead of redoing raw hex inspection by hand.
- Grounded real-save output already narrows that new probe once further: on `p.gms`, every decoded
region triplet currently still has `pre_name_prefix_len = 0` and an empty
`pre_name_prefix_dword_candidates` vector, so the remaining acquisition-side payload target does
not appear to live in the pre-`0x55f1` band on that save. That shifts the next payload-comparison
pass onto the fixed `0x55f2` policy chunk and any later separate body seam, not back onto the
pre-name prefix.
- The rest of `0x00455fc0` is ruled down further now too: after the `+0x48` callback it only runs
`0x0052ebd0`, which reads two one-byte generic flags through `0x531150` into base object bytes
`[this+0x20]`, `[this+0x8d]`, `[this+0x5c..+0x61]`, `[this+0x1ee]`, `[this+0x1fa]`, and