Bound infrastructure asset consumer candidates
This commit is contained in:
parent
6bfe4d043f
commit
61aed9e9ab
2 changed files with 47 additions and 1 deletions
|
|
@ -13,7 +13,11 @@ Working rule:
|
|||
`runtime inspect-infrastructure-asset-trace <save.gms>` now shows that the `0x38a5`
|
||||
infrastructure-asset seam is grounded and the old alias hypothesis is disproved on `q.gms`, so
|
||||
the next placed-structure slice should target the consumer mapping above that seam rather than
|
||||
more collection discovery.
|
||||
more collection discovery; the same trace now also carries atlas-backed candidate consumers
|
||||
(`0x0048a1e0`, `0x0048dd50`, `0x00490a3c`, `0x004559d0`, `0x00455870`, `0x00455930`,
|
||||
`0x00448a70/0x00493660/0x0048b660`, `0x004133b0`) plus bridge/tunnel/track-cap name-family
|
||||
counts, so the next pass can start at those concrete owners instead of the whole
|
||||
placed-structure family.
|
||||
- Reconstruct the save-side region record body on top of the newly corrected non-direct tagged
|
||||
region seam (`0x5209/0x520a/0x520b`, stride hint `0x06`, `Marker09` record stems) now that the
|
||||
`0x55f3` payload is known to be fully consumed by the embedded profile collection on grounded
|
||||
|
|
@ -82,6 +86,11 @@ Working rule:
|
|||
seams; the region trace keeps the queued kind-`7` notice family on the transient side; and the
|
||||
infrastructure trace now makes the `0x38a5` consumer-mapping blocker first-class after
|
||||
disproving any alias to the `0x36b1` placed-structure triplet corpus.
|
||||
- The infrastructure trace now also carries one small atlas-backed static-analysis layer above that
|
||||
seam: bridge/tunnel/track-cap name-family counts from the real side-buffer corpus plus concrete
|
||||
consumer candidates rooted at the `Infrastructure` child attach/rebuild/serializer helpers and
|
||||
the later route/local-runtime follow-on owners. That means the next `0x38a5` pass can be
|
||||
targeted static mapping instead of another generic scan.
|
||||
- Save inspection now splits the shared `0x5209/0x520a/0x520b` family correctly: the smaller
|
||||
direct `0x1d5` collection is the live train family and now exposes a live-entry directory rooted
|
||||
at metadata dword `16`, while the actual region family is the larger non-direct `Marker09`
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue