Bound linked-transit selected-site helper strip

This commit is contained in:
Jan Petykiewicz 2026-04-19 12:47:20 -07:00
commit 406668b4d8
3 changed files with 16 additions and 0 deletions

View file

@ -3704,6 +3704,14 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
`0x00409720`, strips route lists from company-owned trains in modes `0x0a/0x13`, and then
re-enters `train_try_append_linked_transit_autoroute_entry` `0x00409770` only when a train's
route list has become empty.
One nearby live helper strip is narrower now too. Direct inspection of the replay-side sibling
around `0x0040e775` shows `0x004337a0` is exactly the raw selected-company getter over
`[world+0x21]`, used there only to compare the current selection against placed-structure lane
`[site+0x276]`. The adjacent world-side helpers `0x00452d80 / 0x00452db0 / 0x00452fa0` are
separate live selected-site or active service-state setters/dispatchers over
`[world+0x217d/+0x2181]` gated by mode byte `[world+0x2175]`; they can clear or republish
currently-selected site ids through `0x00413620 / 0x00413750`, but they do not repopulate
`[site+0x276]` for already-restored rows.
On the wider chooser question, the current evidence is also tighter than before: every recovered
external owner of `0x00402cb0` is still in the city-connection family, so the two later direct
placement lanes currently read as city-connection fallback behavior rather than a broadly shared

View file

@ -62,6 +62,11 @@ Working rule:
- the owner-company branch is tighter now too:
direct inspection of `0x0040ea96..0x0040eb65` shows that it consumes `[site+0x276]` and
branches through owner/company helpers, but does not itself rehydrate `[site+0x276]`
- the nearby selected-company and live-site helper strip is tighter now too:
`0x004337a0` is the raw selected-company getter over `[world+0x21]`, and the adjacent
world-side helpers `0x00452d80 / 0x00452db0 / 0x00452fa0` are live selected-site or active
service-state setters/dispatchers over `[world+0x217d/+0x2181]` gated by mode byte
`[world+0x2175]`, not restore-time republishers for `[site+0x276]`
- that makes the next linked-transit question narrower:
identify which earlier restore or service owner feeds `[site+0x276]` and the live linked-peer
rows before replay continuation `0x0040e360..0x0040edf6`, beyond the already-grounded