jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Extend atlas seam annotations across load/save and transport

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-13 23:35:17 -07:00
commit 7b44279d7e
7 changed files with 1450 additions and 330 deletions
Download patch file Download diff file Expand all files Collapse all files

52
docs/control-loop-atlas/runtime-roots-camera-and-support-families.md
View file

@ -37,7 +37,7 @@
`Computing Transportation and Pricing...` stays visible while the pipeline runs
`world_compute_transport_and_pricing_grid` `0x0044fb70`, the early collection-owned staging pass
`world_rebuild_secondary_raster_derived_surface_and_companion_planes_in_rect` `0x0044e940`,
`world_setup_building_collection_phase` `0x0041ea50`, and the conditional region pair
`structure_candidate_collection_run_post_load_local_service_setup_phase` `0x0041ea50`, and the conditional region pair
`world_region_collection_seed_default_regions` `0x00421b60` plus
`world_region_collection_refresh_neighbor_and_profile_bands` `0x00420f30`. One save-load-side
status-stack strip is now tighter too: `0x004422d0/0x00442330` push and pop the same four shell
@ -2153,9 +2153,14 @@ Current evidence grounds the shell-controller-backed input and frame path as the
bits `0x40`, `0x20`, and `0x10` in the same flag byte during route-entry rewrites. Those bits are
also no longer copy-only: the neighboring shell helper
`shell_building_detail_refresh_flagged_service_capability_rows` `0x004b9a20` now consumes them to
restyle the `BuildingDetail.win` row bands `0x7d07..0x7d1c` and `0x7f58..0x801f`. The exact
player-facing labels for those rows are still open, but the subflags now have one real shell-side
consumer instead of only preservation logic. The broader `BuildingDetail.win` refresh family is
restyle the `BuildingDetail.win` row bands `0x7d07..0x7d1c` and `0x7f58..0x801f`. The important
boundary is tighter now too: the `0x7d07..0x7d1c` band is a style-only indicator family in current
disassembly, not a hidden text-publishing row family with missing captions. The grounded
player-facing text sits elsewhere: the fixed express-side triplet `0x7f58..0x7f5a` is table-fed
from RT3.lng `494/497/498`, and the sibling special service rows still align to `Dining Car` and
`Caboose`. So the subflags now have one real shell-side consumer instead of only preservation
logic, and the old “missing label” seam on the indicator rows is gone. The broader
`BuildingDetail.win` refresh family is
tighter too: `shell_building_detail_refresh_subject_cargo_and_service_rows` `0x004ba3d0` now
clearly owns the selected subject rows around `0x7d06`, `0x7d96..`, and `0x7d0e`, resolving
ordinary ids through the live candidate collection and the special express-side ids through the
@ -2203,6 +2208,12 @@ Current evidence grounds the shell-controller-backed input and frame path as the
installed by the attach helper, and `+0x0e` is the stable second-site field. One more split is
tighter now too: `placed_structure_route_link_recompute_endpoint_pair_state` `0x00467c30`
currently uses `+0x0a` and `+0x0e` as the active endpoint site pair while recomputing state
byte `+0x12`. The load/save boundary is tighter now too: package save currently persists only the
direct indexed-collection header band of `0x006ada90` through `0x00517d90`, world-entry bring-up
mirrors only that header refresh through `0x00518680`, and the live endpoint or grid state is
then regenerated later through `placed_structure_route_link_collection_recompute_all_endpoint_pair_state`
`0x004682c0` and `placed_structure_route_link_collection_rebuild_route_style_grid_counters_and_endpoint_state`
`0x00468300` rather than through a separate tagged per-record payload lane.
byte `+0x12`; `+0x0c` is still not directly read there. The family also has a clearer release
and refresh side now: `placed_structure_route_link_release_and_detach` `0x004680b0` rolls back
the class counters and then tails into `placed_structure_route_link_detach_current_owner_chain`
@ -2749,8 +2760,9 @@ Current evidence grounds the shell-controller-backed input and frame path as the
best read as the shared `(x,y) -> world-cell*` resolver rather than another object-specific
method.
The next sibling table at `0x005c9750` is tighter now too, though still not fully decoded. The
structural anchor is `map_load_city_database` `0x00474610`: that loader stages bundle tags
`0x61a9..0x61ab`, iterates one collection, and dispatches each entry through vtable slot `+0x44`.
structural anchor is `city_database_entry_collection_refresh_records_from_tagged_bundle`
`0x00474540`: that load-side owner stages bundle tags `0x61a9..0x61ab`, iterates one
collection, and dispatches each entry through vtable slot `+0x40`.
In `0x005c9750`, that same slot resolves into the sibling record family beside
`0x0041ab70/0x0041ab80`, which is enough to treat the table as the city-database entry family
rather than a generic unresolved runtime object. The small load-side slot `0x0041ab70` simply
@ -2760,10 +2772,11 @@ Current evidence grounds the shell-controller-backed input and frame path as the
one named handle through owner `0x006d4020`, writes the resulting handle into `[this+0x1c]`,
queries three base floats through `0x0045c480`, and returns one scaled float derived from the
first queried component. That method is currently called from later world-side branches at
`0x0046e4f7`, `0x004aafee`, and `0x004ab020`. The exact user-facing semantics of the handle and
the many constant-return virtuals in the same table are still open, but the family boundary is no
longer arbitrary: this is now the current city-database entry vtable cluster, not another
placed-structure specialization. One correction matters here too: the lower
`0x0046e4f7`, `0x004aafee`, and `0x004ab020`. The exact user-facing semantic of the handle still
is not grounded, but the leftover rows in the same table are now bounded as low-value
constant-return stubs rather than a meaningful unresolved behavior seam. The family boundary is
therefore no longer arbitrary: this is now the current city-database entry vtable cluster, not
another placed-structure specialization. One correction matters here too: the lower
`0x00455660/0x00455800/0x00455810/0x00455930` helpers are no longer city-only. Local `.rdata`
now shows the same shared slots under both the city-entry table `0x005c9750` and the sibling
`Infrastructure` table `0x005cfd00`, whose constructors at `0x0048a240/0x0048a2dc/0x00490a3c`
@ -3080,12 +3093,14 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
`0x00474110`, allocates one `0x250`-byte live record, resolves it, constructs it through
`0x00474130`, and then tears the temporary entry down through `0x004743d0`; `0x00474510`
resolves one entry id, releases it through `0x00474400`, and removes it from the collection. The
collection-owned load loop at `0x00474540` sits directly beneath `map_load_city_database`
`0x00474610`: it opens the same `0x61a9/0x61aa/0x61ab` bracket on the caller-supplied bundle,
binds the selected path context, iterates the current collection, dispatches each record through
vtable slot `+0x40`, accumulates the returned byte counts, and tears down the temporary entry
after each record. That still leaves broader semantic questions open, but the current static edges
around the city-entry family are now largely exhausted. The adjacent scaffolding is bounded too.
collection-owned load loop at `0x00474540` now has a direct save-side companion too:
`city_database_entry_collection_serialize_records_into_tagged_bundle` `0x00474610` opens the
same `0x61a9/0x61aa/0x61ab` bracket through `0x00531340`, forwards collection metadata through
`0x00517d90`, and dispatches each record through vtable slot `+0x44`. The refresh side binds the
selected path context, iterates the current collection, dispatches each record through vtable
slot `+0x40`, accumulates the returned byte counts, and tears down the temporary entry after each
record. That still leaves broader semantic questions open, but the current static edges around the
city-entry family are now largely exhausted. The adjacent scaffolding is bounded too.
Base helper `0x00455b20` initializes the shared `0x23a`-sized record family by installing base
vtable `0x005cb1c0`, clearing the scalar bands `[+0x206/+0x20a/+0x20e/+0x22e/+0x232]`, zeroing
the seven-dword block `[+0x212..+0x22a]`, and re-entering `0x0052ecd0`; that is why it shows up
@ -3093,8 +3108,9 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
construction paths outside the city family. The city collection itself now has a bounded teardown
side too: `0x00474480` is the small release-and-free wrapper for the collection rooted at
`0x005ce4a8`, and teardown caller `0x004492c3` uses it before freeing the global collection
pointer at `0x006cea50`. On the load side, `0x00445713`'s broader setup branch re-enters
`map_load_city_database` `0x00474610` on that same global `0x006cea50` collection. Outside the
pointer at `0x006cea50`. On the save side, `0x00445713`'s broader package branch re-enters
`city_database_entry_collection_serialize_records_into_tagged_bundle` `0x00474610` on that same
global `0x006cea50` collection. Outside the
city-specific branch, the two tiny dispatch wrappers `0x00455a40` and `0x00455a50` are also now
bounded as raw vtable-slot helpers: the first jumps through entry slot `+0x44`, while the second
pushes one caller argument into slot `+0x40` and then clears the global roots