# Control-Loop Atlas

This atlas is the high-level map for RT3 1.06. It is intentionally broader than the function map:
each section explains who owns a loop, where it starts, what dispatches it, which state blocks
anchor it, and where control is handed to neighboring subsystems.

## CRT and Process Startup

- Roots: `entry` at `0x005a313b`, CRT helpers in the `0x005a2d..0x005ad4..` range, and `app_bootstrap_main` at `0x00484440`.
- Trigger/Cadence: single process startup path before shell or engine services exist.
- Key Dispatchers: `startup_init_tls_state`, `startup_init_file_handle_table`, `startup_run_init_callback_table`, `__setenvp`, `startup_build_argv`, `___crtGetEnvironmentStringsA`, then `app_bootstrap_main`.
- State Anchors: CRT heap and file-handle tables; process environment and argv storage.
- Subsystem Handoffs: exits the generic CRT path at `app_bootstrap_main`, which becomes the first RT3-owned coordinator.
- Evidence: `artifacts/exports/rt3-1.06/startup-call-chain.md`, `artifacts/exports/rt3-1.06/function-map.csv`.
- Open Questions: exact ownership boundary between compiler CRT shims and the first game-owned bootstrap helper; whether any nontrivial startup callbacks seed game globals before `app_bootstrap_main`.

## Bootstrap and Shell Service Bring-Up

- Roots: `app_bootstrap_main` at `0x00484440`, `bootstrap_init_shell_window_services` at `0x004840e0`, and `shell_install_global_controller` at `0x0051ff90`.
- Trigger/Cadence: one-time bootstrap handoff immediately after CRT completion.
- Key Dispatchers: `app_bootstrap_main`, `bootstrap_init_shell_window_services`, `shell_install_global_controller`, `shell_service_pump_iteration`, graphics config load or default-init helpers, runtime capability probes, and early shell service initializers under the `0x004610..0x0053f0..` branch.
- State Anchors: global shell controller pointer `0x006d4024`, sibling display/runtime globals under `0x006d402c` and `0x006d4030`, and host capability flags gathered by `bootstrap_probe_system_profile`.
- Subsystem Handoffs: after the global shell controller has been installed the bootstrap path enters the repeating `shell_service_pump_iteration` loop, which services shell-state work and hands each iteration down into the controller frame path; when the shell lifetime ends this same bootstrap path tears the shell bundle down and returns to `app_bootstrap_main`.
- Evidence: `startup-call-chain.md`, function-map rows for `app_bootstrap_main`, `bootstrap_init_shell_window_services`, `shell_install_global_controller`, `shell_service_pump_iteration`, `shell_load_graphics_config_or_init_defaults`, `shell_reset_display_runtime_defaults`, and related graphics setup helpers.
- Open Questions: whether gameplay or in-engine world stepping later escapes this bootstrap-owned shell loop entirely, or whether gameplay entry still rendezvous with the same outer coordinator before the shell bundle is destroyed.

## Shell UI Command and Deferred Work Flow

- Roots: shell callback paths that converge on `shell_dispatch_ui_command` at `0x00464410`.
- Trigger/Cadence: event-driven UI command dispatch plus deferred-message queue flushing during shell activity.
- Key Dispatchers: `shell_dispatch_ui_command`, `shell_enqueue_deferred_work_message`, `shell_post_deferred_message_type5`, `shell_post_deferred_message_type6`, `shell_enqueue_deferred_message_type4`, `shell_enqueue_deferred_message_type1`.
- State Anchors: shell object at `0x0062be68`, queue roots around `[this+0x11369d]`, `[this+0x1136a1]`, and `[this+0x1136a5]`, global routing gates at `0x006d4034`, and the separate detail-panel controller rooted at `0x006d0818`.
- Subsystem Handoffs: routes into graphics config, scenario-text export, overlay generation, multiplayer UI, shell detail windows such as `EditorPanel.win` and `TrainDetail.win`, and presentation-facing deferred work later drained by `shell_service_frame_cycle`.
- Evidence: function-map shell rows around `0x00464410`, `0x004d4500`, `0x004ddbd0`, and `0x0051f1d0..0x0051f460`.
- Open Questions: whether the shell command dispatcher is also used by hotkeys or only by UI callback tables; the current `0x006d0818` detail-panel path looks shell-only and does not yet explain gameplay world entry.

## Presentation, Overlay, and Frame Timing

- Roots: the bootstrap-owned `shell_service_pump_iteration` at `0x00483f70`, the shell-state service pass `shell_state_service_active_mode_frame` at `0x00482160`, the installed global shell controller at `0x006d4024`, the pending frame-cycle owner `shell_service_frame_cycle` at `0x00520620`, and the frame-time history path under `shell_update_frame_time_history` at `0x0051fd70`.
- Trigger/Cadence: recurring bootstrap-owned shell service work once the active mode, controller window, and display runtime are live; special modal or content-building paths can also force immediate frame servicing inside that broader cadence.
- Key Dispatchers: `shell_service_pump_iteration`, `shell_state_service_active_mode_frame`, `shell_service_frame_cycle`, `shell_refresh_presentation_frame`, `shell_update_frame_time_history`, `shell_get_smoothed_frame_scalar`, `shell_set_gamma_ramp_scalar`, and overlay builders such as `shell_queue_single_world_anchor_overlay`, `shell_queue_world_anchor_overlay_list`, and `shell_queue_indexed_world_anchor_marker`.
- State Anchors: shell state at `0x006cec74`, active mode pointer `0x006cec78`, shell frame history ring at `0x006d403c`, display/runtime state inside the controller block near `[this+0x114282]` and `[this+0x11428a]`, presentation service pointer at `[this+0x0c]`, and the native controller window handle at `[this+0x00]`.
- Subsystem Handoffs: the bootstrap-owned pump runs shell-bundle polling and shell-state maintenance before the shell-state pass synchronizes active-mode helpers and modal-status work and dispatches the controller frame cycle, which then consumes world/object state for overlays and presentation refresh, uses the controller window handle for one-time `ShowWindow` and related UI interaction, and drains the deferred work queues at the end of the cycle.
- Evidence: function-map rows for `shell_service_pump_iteration`, `shell_state_service_active_mode_frame`, `shell_service_frame_cycle`, `shell_flush_deferred_work_queues`, frame history, gamma ramp, world-anchor overlay builders, and graphics runtime helpers.
- Open Questions: how simulation cadence rendezvous with the shell presentation cadence once gameplay takes over and whether gameplay stepping exits this shell-owned controller path entirely.

## Map and Scenario Content Load

- Roots: `shell_map_file_entry_coordinator` at `0x00445ac0`, the first grounded world-entry branch `world_entry_transition_and_runtime_bringup` at `0x00443a50`, `shell_map_file_world_bundle_coordinator` at `0x00445de0`, reference-database setup via `map_bundle_open_reference_databases` at `0x00444dd0`, and narrower loaders such as `map_load_geographic_label_database` and `map_load_city_database`.
- Trigger/Cadence: shell tutorial launch, editor or detail-panel file actions through `fileopt.win`, map-scenario open paths, and scenario-text export batch commands.
- Key Dispatchers: `shell_map_file_entry_coordinator`, `world_entry_transition_and_runtime_bringup`, `world_runtime_release_global_services`, `shell_map_file_world_bundle_coordinator`, `map_bundle_open_reference_databases`, `map_load_geographic_label_database`, `map_load_city_database`, `scenario_text_export_build_language_file`, `scenario_text_export_report_language_file`, `scenario_text_export_batch_process_maps`.
- State Anchors: shell-side file staging buffers at `0x0062bee0` and `0x0062bec4`, shell and mode globals at `0x006cec74` and `0x006cec78`, world object root `0x0062c120`, map bundle state allocated through `0x00530c80`, and geography tables rooted at `0x0062b2fc` and `0x0062b268`.
- Subsystem Handoffs: the shared `fileopt.win` dialog rooted at `0x004dc670` now looks like the shell-side selector above the two broad file coordinators. Its message handler sets `0x006d07f8` for the load or restore side or `0x006d07ec` for the save or package side before the detail-panel transition manager routes into `shell_map_file_entry_coordinator` or `shell_map_file_world_bundle_coordinator`. The former unresolved third flag at `0x006d07f0` is now accounted for too: it escapes into the standalone `SettingsWindow.win` path through `shell_open_settings_window` rather than another map or save verb. The broad coordinators now hand their interactive work through the shared `filerqst.win` helper at `0x004dd010`, and that helper gives the extension split a firmer shape. The paired editor-map path is now grounded as `.gmp` through load mode `4` and save mode `3`. The remaining non-editor families are no longer anonymous either: `.gmc` is the campaign-scenario branch, backed both by the campaign-screen resignation prompt on `0x006cec7c+0xc5` and by the numbered `%s%02d.gmc` save helper at `0x00517c70`; `.gmx` is the sandbox branch, backed by the shell-side `The briefing is not available in sandbox games.` restriction on `0x006cec7c+0x82`; and the default `.gms` branch is therefore the standalone scenario family. When a live runtime world is already active the same helper bypasses those non-runtime extensions and forces the `.smp` runtime-state branch instead. The auxiliary save-side mode `11` is tighter now too: it still maps to `.gmt`, but instead of looking like another gameplay save family it conditionally diverts into the same `.gmt` preview-surface pipeline owned by the Multiplayer preview dataset object at `0x006cd8d8`, and only falls back to the normal reference-bundle path when that dataset object is absent.
- Evidence: function-map map/scenario rows, analysis-context exports for `0x00445ac0`, `0x00445de0`, `0x00443a50`, `0x00434300`, and `0x00444dd0`, plus objdump string and mode-table evidence for `.gmp`, `.gmx`, `.gmc`, `.gms`, `.gmt`, `.smp`, `Quicksave`, the `0x004dd010` mode table at `0x005f3d58`, the auxiliary-owner presence check at `0x00434050`, and the `.gmt` handoff through `0x00469d30`, together with localized string evidence from ids `3018` and `3898`.
- Open Questions: bit `0x1` on both broad coordinators now grounds the Quicksave name seed and the former third `fileopt.win` flag has been ruled out as a file-flow question because it just opens `SettingsWindow.win`. The old broad extension question is mostly resolved: `.gmp` is the editor-map pair, `.gms` is the standalone scenario family, `.gmc` is the campaign-scenario family, `.gmx` is the sandbox family, and `.gmt` is at least bounded as an auxiliary preview-surface branch rather than another gameplay save family. The higher-value global question is no longer whether `0x00443a50` is world entry. It is where the long-lived simulation cadence takes over after this bring-up and whether that cadence still rendezvous with the shell-owned frame path or escapes into a separate gameplay loop.

## Multiplayer Session and Transport Flow

- Roots: Multiplayer.win session-event callback table around `0x00468de0..0x004691d0`, the Multiplayer preview dataset object at `0x006cd8d8`, and the transport object and pending-template paths around `0x00597880..0x0059caf0`.
- Trigger/Cadence: event-driven session callbacks, registered-name updates, and repeated socket I/O service steps.
- Key Dispatchers: session-event wrappers for actions `1`, `2`, `4`, `7`, `8`; `multiplayer_window_init_globals`; `multiplayer_dispatch_requested_action`; `multiplayer_reset_preview_dataset_and_request_action`; `multiplayer_preview_dataset_service_frame`; `multiplayer_load_selected_map_preview_surface`; `multiplayer_transport_text_stream_service_io`; `multiplayer_transport_dispatch_pending_template_node`; `multiplayer_transport_service_pending_template_dispatch_store`.
- State Anchors: live session globals at `0x006d40d0`, preview dataset object at `0x006cd8d8`, preview-valid flag at `0x006ce9bc`, staged preview strings at `0x006ce670` and `[0x006cd8d8+0x8f48]`, Multiplayer.win backing block at `0x006d1270`, status latch at `0x006cd974`, pending-template list at `[this+0x550]`, dispatch store at `[this+0x55c]`, and text-stream buffers at `[this+0x108]` and `[this+0x114]`.
- Subsystem Handoffs: the Multiplayer.win initializer seeds the backing block at `0x006d1270`, later reset paths construct the separate preview dataset at `0x006cd8d8`, and the shell-owned active-mode frame now services that dataset every frame through `multiplayer_preview_dataset_service_frame`. That preview side then publishes roster and status controls through `multiplayer_window_control_dispatch`, loads `.gmt` preview surfaces through `multiplayer_load_selected_map_preview_surface`, and is even reused by the map/save coordinator’s mode-`11` `.gmt` path when the dataset already exists. Beside that preview/UI branch, the transport side still owns text streams, session state changes, and pending-template completion callbacks.
- Evidence: `function-map.csv`, `pending-template-store-management.md`, `pending-template-store-functions.csv`.
- Open Questions: unresolved request-id semantics for `1`, `2`, `4`, and `7`; the exact owner loop that repeatedly services transport I/O; and how far the Multiplayer preview-dataset machinery is reused outside `Multiplayer.win` beyond the currently grounded `.gmt` save-mode hook.

## Input, Save/Load, and Simulation

- Roots: the shell controller window-message ingress `shell_controller_window_message_dispatch` at `0x0054e3a0`, the shell input-state object initialized at `0x006d4018` through `shell_input_state_init` `0x0054e710`, the saved-world restore path `world_load_saved_runtime_state_bundle` at `0x00446d40`, the live-world save path `world_runtime_serialize_smp_bundle` at `0x00446240`, `world_entry_transition_and_runtime_bringup` at `0x00443a50`, the frame-owned cadence `simulation_frame_accumulate_and_step_world` at `0x00439140`, the recurring `GameMessage.win` service branch through `game_message_window_service_if_present` `0x004e0720`, the world-facing `GameUppermost.win` overlay branch ensured by `shell_ensure_game_uppermost_window` `0x004e0e40` and serviced through `game_uppermost_window_service_world_hotspot_band` `0x004e0780`, and the lower step family rooted at `simulation_advance_to_target_calendar_point` `0x0040ab50` with periodic branches through `simulation_service_periodic_boundary_work` `0x0040a590`.
- Trigger/Cadence: shell-side input is event-driven by controller-window `WM_*` traffic while save or load work is triggered either directly from shell commands or through the `fileopt.win` branch flags into the `.smp` runtime-state family; post-bring-up world service becomes recurring once a world root exists at `0x0062c120`, but the current grounded top-level cadence still remains the shell-owned `shell_service_pump_iteration` path, which calls `simulation_frame_accumulate_and_step_world` directly and lets it accumulate elapsed wall-clock time into one or more simulation-step quanta.
- Key Dispatchers: `shell_controller_window_message_dispatch`, `shell_input_apply_window_key_transition`, `shell_input_snapshot_dispatch_state`, `shell_input_cursor_inside_active_view`, `world_load_saved_runtime_state_bundle`, `world_runtime_serialize_smp_bundle`, `simulation_frame_accumulate_and_step_world`, `game_message_window_service_if_present`, `game_message_window_service_frame`, `game_uppermost_window_handle_message`, `game_uppermost_window_service_world_hotspot_band`, `game_uppermost_window_refresh_controls`, `world_view_service_keyboard_turn_pan_and_zoom_bindings`, `world_view_step_heading_quadrant`, `world_view_step_zoom_bucket`, `station_place_world_surface_sync_and_dispatch`, `station_place_window_handle_message`, `track_lay_window_refresh_controls`, `track_lay_window_service_frame`, `track_lay_window_handle_message`, `simulation_advance_to_target_calendar_point`, the smaller single-step helper at `0x00409e80`, `0x0040a9c0`, `0x0040a910`, and `simulation_service_periodic_boundary_work`.
- State Anchors: shell input object `0x006d4018`, per-key state table starting at `[input+0x100]`, packed shell input flags at `[input+0xa8c]` now grounded as Right Shift `0x1`, Left Shift `0x2`, Control `0x4`, and Alt `0x20`, nested dispatch counter `[input+0xa90]`, global shell controller `0x006d4024`, active world root `0x0062c120`, `GameMessage.win` object `0x006d081c`, `GameUppermost.win` overlay object `0x006d0820`, `StationPlace.win` tool object `0x006d1720`, `TrackLay.win` tool object `0x006d1a8c`, accumulated leftover simulation time at `[this+0x4c80]`, shell and mode globals at `0x006cec74`, `0x006cec78`, and `0x006cec7c`, world manager collections at `0x0062be10`, `0x006ceb9c`, `0x006cfcbc`, `0x006cec20`, `0x0062bae0`, and `0x006acd34`, plus the packed calendar-like tuple fields around `[this+0x0d]`, `[this+0x0f]`, `[this+0x11]`, and `[this+0x14]`.
- Subsystem Handoffs: the controller window dispatcher now looks like the first grounded input ingress. It translates keyboard and mouse `WM_*` traffic into shell controller state and the separate input object at `0x006d4018`; read-side cursor and camera helpers later snapshot that object through `shell_input_snapshot_dispatch_state` and gate world-relative interaction through `shell_input_cursor_inside_active_view`. Current grounded consumers around `0x00478cb0`, `0x004e0780`, `0x0053f450`, and `0x0053fe90` still sit on the shell controller path and consult `0x006d4024` or the world owner at `0x0062be68`, so there is still no evidence for a distinct gameplay-only input object after world entry. Instead, the first deeper world-mode interaction branch now looks like a shared world-view coordinator layered on top of the same shell-fed input state. Shell_transition_mode ensures the `GameUppermost.win` object at `0x006d0820`; its message dispatcher `game_uppermost_window_handle_message` owns the narrow action band `0x7918` through `0x7921`; and the recurring service helper `game_uppermost_window_service_world_hotspot_band` rate-limits those hotspot actions, rechecks `shell_input_cursor_inside_active_view`, and then pans the live world view through `world_view_pan_relative_offset_in_camera_plane` `0x0043d130`. The same lower setter family is also reached from the cursor-drag path through `world_view_apply_screen_delta_to_focus_position` `0x0043d0c0`. Above both of those sits the larger recurring service `world_view_service_shell_input_pan_and_hover` `0x0043db00`, which now has one grounded keyboard branch beneath it: `world_view_service_keyboard_turn_pan_and_zoom_bindings` `0x0043d740`. That helper resolves four binding-pair families from the shell input table via `0x0054e7d0`, and the localized labels are now grounded from `Data/Language/RT3.lng`: `Camera Forward` and `Camera Backward` feed the first signed pan channel, `Camera Left` and `Camera Right` feed the second signed pan channel, `Camera Zoom In` and `Camera Zoom Out` feed the signed zoom-step channel that `0x0043db00` smooths into `world_view_step_zoom_bucket` `0x0043cc30`, and `Camera Rotate Left` plus `Camera Rotate Right` feed the continuous heading-turn branch through `0x0043c810`. The setup side is now better bounded too: `world_view_seed_keyboard_binding_slot_pairs` at `0x00439e40` seeds the eight slot pairs at `[this+0x0a6]` through `[this+0x0e2]` from the global action-binding registry through `0x0045f370` using the distinct registry keys `0x0043d2a0` through `0x0043d310`, and the registration block at `0x00460769` through `0x004608e7` shows those roots are defaulted to the expected Up Down Left and Right virtual keys before runtime polling begins. Beneath that camera stack, the enclosing frame path now has one grounded non-view sidecar: after `0x0043db00` it reads the active controller-view object pointer at `[0x006d4024+0x18]+0x366e`, compares it against the latched target at `[frame_owner+0x66a2]`, fires exit and enter-style vtable callbacks on pointer changes through slots `+0x64` and `+0x60`, and only latches the new object when the object passes its own slot `+0x1c` availability test and shell detail control id `0x07d6` on `0x006d0818` has flag bit `0x4`. That `0x07d6` gate is now more bounded than before: the dedicated `TrackLay.win` tool family rooted at `0x006d1a8c` special-cases the same control id in both `track_lay_window_service_frame` and `track_lay_window_handle_message`, uses world hit tests through `0x00448ac0` to arm and release a drag latch on that surface, and routes the resulting command work through the shared track-lay mode state at `0x00622b0c`. The surrounding `track_lay_window_refresh_controls` pass now shows that this is not just one isolated drag handler: the same tool family owns three mutually exclusive primary mode buttons at `0x985e` `0x985f` and `0x9860`, and current primary evidence now bounds those values as `Lay single track.` `0x1`, `Lay double track.` `0x4`, and `Bulldoze` `0x40` from the localized strings 2054 2055 and 1721 plus the matching control-routing branches in `track_lay_window_handle_message`. The same family also owns a bridge-type preference selector rooted at `0x006cec74+0x138`, two wrapped `Never` through `Common` frequency settings at `0x006cec74+0x140` and `0x006cec74+0x13c`, two boolean track-lay preference toggles, and the electrify-all-track action path. Those last two toggles are now tighter than before: current evidence strongly aligns control `0x986e` and state `0x006cec74+0x144` with `Auto-Hide Trees During Track Lay` from strings 1838 and 1839, while control `0x986d` and state `0x006cec78+0x4c74` align with `Auto-Show Grade During Track Lay` from strings 3904 and 3905. That mapping is still evidence-backed rather than absolutely direct from a recovered resource table, but the state ownership and control order now make it the strongest current fit. That makes `0x07d6` look like the shared main-world interaction surface inside a broader TrackLay world-command subsystem, not an unrelated detail button. The neighboring `StationPlace.win` family is now grounded on that same surface too: the shell detail-panel constructor family allocates it through `station_place_window_construct` at `0x00509d80`, publishes it at `0x006d1720`, services it each frame through `station_place_window_service_frame` at `0x0050a530`, and routes player-facing commands through `station_place_window_handle_message` at `0x005091b0`. That dispatcher special-cases the same `0x07d6` control, and the shared helper `station_place_world_surface_sync_and_dispatch` at `0x00508bb0` either accepts that direct surface traffic or falls back to the same detail-panel control looked up through `0x006d0818`, rechecks flag bit `0x4`, hit-tests the world through `0x00448ac0`, stages world coordinates into `0x006d1738` and `0x006d173c`, refreshes the selected-site summary through `station_place_format_selected_site_summary`, and updates the live station-placement selection state at `0x00622af0`, `0x00622aec`, and `0x006d1740`. Together with `station_place_select_category_and_refresh` `0x00508880`, `station_place_refresh_category_controls` `0x00507b90`, and `station_place_format_preview_panel` `0x00508730`, that makes StationPlace a second grounded consumer of the shared main-world interaction surface rather than only a sibling constructor plus frame hook. The StationPlace control semantics are now tighter too: the top category strip at `0x697c` through `0x6981` now grounds as small station, medium station, large station, service tower, maintenance facility, and non-station building from `RT3.lng` strings 2197 through 2202. For the three station categories only, the secondary strip at `0x6988` and `0x6989` plus display field `0x698c` no longer looks like another placement mode family; it is a building-style scroller. The click handlers on `0x6988` and `0x6989` cycle the style override in `0x00622aec`, and the display path builds the active style token from `StationSml`, `StationMed`, or `StationLrg` plus the localized architecture styles `Victorian`, `Tudor`, `Southwest`, `Persian`, `Kyoto`, and `Clapboard` from `RT3.lng` ids 2672 through 2667. One layer lower, the remaining opaque controls are now much tighter: `0x6985` and `0x6986` are no longer a generic assist toggle but the two station-rotation policy choices from strings 2207 and 2206, switching between auto-orienting the building to track or obstacles and strictly obeying the rotation specified by the circle above. The dedicated control at `0x6987` is the station-rotation circle itself, wired through callback `0x00507a90` and aligned with `Click to rotate the building. You can also use bracket keys [ and ] to rotate buildings.` string 2208. That matches the lower behavior too: when the strict-rotation choice is off, both preview and commit paths route staged coordinates through `0x00508040`, which performs the extra orientation search before validation; when strict rotation is on, that pass is skipped and the current angle in `0x006d172c` is used directly. The direct shell UI also exposes the same discrete view-step family through `world_view_step_heading_quadrant` `0x0043cb00` and `world_view_step_zoom_bucket` `0x0043cc30`. The neighboring gating predicates `world_view_should_drive_primary_pan_channel` and `world_view_should_drive_secondary_pan_channel` test packed shell input bits `0x3`, and `shell_input_apply_window_key_transition` now grounds those bits as the left and right Shift modifiers from scan codes `0x2a` and `0x36`. That means cursor drag, overlay hotspots, held Shift state, direct keyboard turn/pan/zoom bindings, the TrackLay and StationPlace world-command surfaces, and at least one frame-owned hover or focus-target branch all converge under the same shell-fed world-mode input path rather than a separate gameplay-input stack.
- Evidence: function-map rows for `shell_controller_window_message_dispatch`, `shell_drain_pending_window_messages`, `shell_input_state_init`, `shell_input_apply_window_key_transition`, `shell_input_snapshot_dispatch_state`, `shell_input_cursor_inside_active_view`, `world_load_saved_runtime_state_bundle`, `world_runtime_serialize_smp_bundle`, `world_entry_transition_and_runtime_bringup`, `simulation_frame_accumulate_and_step_world`, `game_message_window_service_if_present`, `game_message_window_service_frame`, `shell_ensure_game_uppermost_window`, `game_uppermost_window_construct`, `game_uppermost_window_handle_message`, `game_uppermost_window_service_world_hotspot_band`, `world_view_set_focus_position_xyz`, `world_view_apply_screen_delta_to_focus_position`, `world_view_pan_relative_offset_in_camera_plane`, `world_view_seed_keyboard_binding_slot_pairs`, `world_view_service_keyboard_turn_pan_and_zoom_bindings`, `world_view_step_heading_quadrant`, `world_view_step_zoom_bucket`, `world_view_should_drive_primary_pan_channel`, `world_view_should_drive_secondary_pan_channel`, `world_view_service_shell_input_pan_and_hover`, `station_place_refresh_category_controls`, `station_place_format_selected_site_summary`, `station_place_format_preview_panel`, `station_place_select_category_and_refresh`, `station_place_world_surface_sync_and_dispatch`, `station_place_window_handle_message`, `station_place_window_construct`, `station_place_window_service_frame`, `track_lay_window_refresh_controls`, `track_lay_window_construct`, `track_lay_window_service_frame`, `track_lay_window_handle_message`, and `simulation_service_periodic_boundary_work`, plus the shell-input disassembly around `0x0054f290`, the world-view setup and service branches around `0x00439e40`, `0x0043d740`, `0x0043db00`, `0x0043cb00`, and `0x0043cc30`, the StationPlace.win constructor plus category, dispatcher, rotation-circle, shared-world-surface, preview-build, and recurring service branches around `0x00507a90`, `0x00507b90`, `0x00508550`, `0x00508730`, `0x00508880`, `0x00508bb0`, `0x005091b0`, `0x00509d80`, and `0x0050a530`, the StationPlace string cluster `Place a small station` 2197 `Place a medium station` 2198 `Place a large station` 2199 `Place a service tower` 2200 `Place a maintenance facility` 2201 `Place a non-station building` 2202 `Scroll through building styles.` 2203 `When placing the building, it will strictly adhere to the rotation specified by the circle above.` 2206 `When placing the building, it will rotate itself as needed to orient to track or avoid obstacles.` 2207 `Click to rotate the building. You can also use bracket keys [ and ] to rotate buildings.` 2208 and the architecture-style labels `Clapboard` 2667 `Kyoto` 2668 `Persian` 2669 `Southwest` 2670 `Tudor` 2671 and `Victorian` 2672, the TrackLay.win constructor and dispatcher family around `0x0050d2d0`, `0x0050e400`, `0x0050e1e0`, and `0x0050e5c0`, the localized `Never` through `Common` strings 615 through 618, the track-lay strings `Bulldoze` 1721 `Lay single track.` 2054 `Lay double track.` 2055 and 3114, the TrackLay preference strings `Auto-Hide Trees During Track Lay` 1838 `If 'Auto-Hide Trees During Track Lay' is checked, trees will automatically be reduced to small stumps whenever you are in track laying mode.` 1839 `Auto-Show Grade During Track Lay` 3904 and `If 'Auto-Show Grade During Track Lay' is checked, you'll see the grade number over the track while laying track - useful for trying to keep your slopes to a minimum.` 3905, the electrify-all confirmation and failure strings 3083 3084 3837 and 3900, the binding-registry lookup path at `0x0045f370`, the registration block at `0x00460769` through `0x004608e7`, and the localized labels in `Data/Language/RT3.lng` ids `3466` through `3473`.
- Open Questions: no separate outer gameplay loop is grounded above `simulation_frame_accumulate_and_step_world` yet and no deeper gameplay-only input object is grounded either, but the first deeper world-mode interaction branch is now better bounded: `GameUppermost.win` hotspots, cursor drag, held Shift state, discrete shell view-step commands, direct keyboard turn/pan/zoom bindings, the `TrackLay.win` and `StationPlace.win` world-command surfaces, and a frame-owned hover or focus-target transition branch all feed the same shell-controller-backed path. The remaining uncertainty has moved farther from basic ownership: the hover-target branch clearly exists, and `0x07d6` now looks like the shared main-world interaction surface rather than a generic detail button for one tool family only. The next unresolved layer is narrower and more semantic: the `TrackLay.win` family now clearly owns `Lay single track.` `Lay double track.` and `Bulldoze` as its three primary modes, its bridge selector, its wrapped frequency preferences, and a strongly aligned pair of `Auto-Hide Trees During Track Lay` and `Auto-Show Grade During Track Lay` toggles; the `StationPlace.win` family now clearly owns its six top-level category buttons, the station-style scroller, and the station-rotation controls; and the packed simulation tuple fields remain semantically open. The older `Building placement center` string 671 no longer looks like a live StationPlace control label in the current recovered flow, because the active constructor, preview, refresh, and dispatcher paths all use neighboring ids such as 669 and 2208 without a direct recovered lookup of 671. On save or load the broad serialize-versus-restore split is now grounded, the non-Quicksave `.gmp/.gmx/.gmc/.gms` families are separated, and the auxiliary `.gmt` path is at least bounded to the preview-surface side owner. The higher-value shell-facing gap has therefore shifted upward to subsystem ownership, especially the outer multiplayer transport and service cadence.

## Next Mapping Passes

- Identify the exact transport-side owner loop that repeatedly services multiplayer I/O and dispatch-store work now that the preview dataset is grounded under `Multiplayer.win`.
- Identify the owner loop that repeatedly services multiplayer transport I/O and dispatch-store work.
- Determine whether any later world-mode branch beneath the frame owner bypasses the shell controller input path for non-cursor gameplay input, since the current grounded overlay and cursor helpers still reuse `0x006d4018`.
- Keep detailed pending-template or transport work scoped to the specific atlas edges that remain unresolved.