# Runtime Effect Kind-8 Tier2 Named Availability Note This note records the current named-candidate availability comparison between the strongest title-overlap pair: - `Louisiana.gmp` - `Dutchlantis.gmp` The comparison uses the checked `rt3_105_save_name_table_probe` surface from `inspect-smp`. ## Immediate Result `Warehouse05` is **not** the differentiator. Observed values: - `Warehouse05` - `Louisiana.gmp = 1` - `Dutchlantis.gmp = 1` - `Port01` - `Louisiana.gmp = 1` - `Dutchlantis.gmp = 1` - `Furniture Factory` - `Louisiana.gmp = 1` - `Dutchlantis.gmp = 1` - `FarmGrain` - `Louisiana.gmp = 1` - `Dutchlantis.gmp = 1` - `Logging Camp` - `Louisiana.gmp = 1` - `Dutchlantis.gmp = 1` So the strongest current `Louisiana -> Dutchlantis` title overlap does not also come with a unique `Warehouse05` availability toggle that would directly explain the one-row `Add Building Warehouse05` dispatch cluster in `Louisiana.gmp`. ## Full Named-Availability Differences The current comparison shows `18` differing names: - `AluminumMill`: `Louisiana = 0`, `Dutchlantis = 1` - `AutoPlant`: `Louisiana = 0`, `Dutchlantis = 1` - `Bauxite Mine`: `Louisiana = 0`, `Dutchlantis = 1` - `Chemical Plant`: `Louisiana = 0`, `Dutchlantis = 1` - `Farm Corn`: `Louisiana = 1`, `Dutchlantis = 0` - `FarmCotton`: `Louisiana = 1`, `Dutchlantis = 0` - `FarmRice`: `Louisiana = 1`, `Dutchlantis = 0` - `FarmSheep`: `Louisiana = 0`, `Dutchlantis = 1` - `FarmSugar`: `Louisiana = 1`, `Dutchlantis = 0` - `Fertilizer Factory`: `Louisiana = 0`, `Dutchlantis = 1` - `Iron Mine`: `Louisiana = 0`, `Dutchlantis = 1` - `Nuclear Power Plant`: `Louisiana = 0`, `Dutchlantis = 1` - `Oil Refinery`: `Louisiana = 1`, `Dutchlantis = 0` - `Plastics Factory`: `Louisiana = 0`, `Dutchlantis = 1` - `Recycling Plant`: `Louisiana = 0`, `Dutchlantis = 1` - `Steel Mill`: `Louisiana = 0`, `Dutchlantis = 1` - `Tool And Die`: `Louisiana = 0`, `Dutchlantis = 1` - `Uranium Mine`: `Louisiana = 0`, `Dutchlantis = 1` The broader `compare-candidate-table` surface agrees with the same conclusion: - common semantic family remains `scenario-named-candidate-availability-table` - `Warehouse05` stays `1 / 1` - `difference_count = 43`, but those differences are still driven by the wider industrial mix, header words, and the zero-trailer-name set rather than by any unique `Warehouse05` bit ## Current Implication The Tier 2 candidate/world-state rebuild strip remains plausible in general because it owns named candidate availability seeding and refresh, but the current evidence no longer supports the narrow claim that `Louisiana.gmp` gets its `Add Building Warehouse05` row from a unique `Warehouse05` availability difference relative to `Dutchlantis.gmp`. Two deeper grounded notes tighten that further: - `structure_candidate_collection_rebuild_runtime_records_from_scenario_state` `0x00412d70` does **not** consult the scenario-side recipe-book name at `[state+0x0fe8]`; it formats the rebuilt candidate display stem from one of two fixed built-in roots `0x005c93d8` or `0x005c93e8` plus the current ordinal. - `scenario_state_upsert_named_candidate_availability_record_and_refresh_runtime_filters` `0x00434f20` now reads safely as a real boolean availability override writer rather than a wider mode enum. So the next Tier 2 recovery question is now tighter still: - whether the relevant difference is in broader candidate-state rebuild sequencing, latch refresh, or cargo-membership/runtime-record reconstruction under `0x00437737 / 0x00412c10 / 0x00412bd0 / 0x00412d70 / 0x00412fb0`, rather than in the direct named availability bit for `Warehouse05` itself. ## Nearest Single-Import Peer Check The same boundary now holds against the nearest single-import recipe peer too: - `Louisiana.gmp` - `South East USA.gmp` Direct `inspect-candidate-table` checks still keep the key port/warehouse rows aligned: - `Warehouse05` - `Louisiana.gmp = 1` - `South East USA.gmp = 1` - `Port01` - `Louisiana.gmp = 1` - `South East USA.gmp = 1` So even after the recipe-side frontier moved from “same coarse mode shape” to “same single-import family,” the direct named-availability table still does not provide the missing Tier 2 split for the shipped `5200 :: [7:0]` `Add Building Warehouse05` row. That leaves the same later owners as the honest next focus: - `0x00412d70` template-bank and runtime-record rebuild - `0x00411ce0 / 0x00411ee0` dependent mode-flag and cargo-summary refresh - `0x00412c10` latch refresh after those runtime records already exist ## Port Versus Warehouse Runtime Roots One broader binary pass now closes the fixed-root ambiguity inside `0x00412d70`. Direct `objdump` over `RT3.exe` shows the two built-in format roots are: - `0x005c93d8 = "Warehouse%02d"` - `0x005c93e8 = "Port%02d"` And the candidate rebuild chooses between them exactly as: - if `[candidate+0xba] != 0` - use `Port%02d` - else - use `Warehouse%02d` So the later Tier 2 runtime-record frontier is no longer an abstract “two built-in roots” question. It is specifically: - how `0x00412d70` bank or template selection and the live availability bytes `[candidate+0xba/+0xbb]` determine which rebuilt candidates land on the `Warehouse%02d` side versus the `Port%02d` side - and why the `Warehouse%02d` side in `Louisiana.gmp` is the one that later lines up with the shipped `5200 :: [7:0]` `Add Building Warehouse05` strip That also keeps the direct named-availability boundary honest: - `Warehouse05 = 1` in the fixed scenario table still does not explain the runtime split by itself - the next meaningful owner seam is the later port-versus-warehouse runtime-record rebuild under `0x00412d70`, before `0x00412c10` mirrors anything into `[candidate+0x7ac]` ## Writer-Side Split Above The Availability Bytes One more direct disassembly pass narrows that owner seam further. `structure_candidate_stream_load_runtime_record_and_rebuild_cargo_state` `0x004120b0` does rebuild a substantial portion of each live candidate record: - clears dependent runtime pointers and flags such as `[candidate+0x79c/+0x7a0/+0x78c/+0x790/+0x794/+0x7b0]` - reads the fixed per-record stream fields at `[candidate+0x04/+0x22/+0x26/+0x28/+0x2a/+0x2e/+0x32/+0x33]` - restores the selector-bank bytes `[candidate+0xb9/+0xba/+0xbb]` - allocates and streams the packed `0xbc` descriptor array into `[candidate+0x37]` So the current strongest ownership split is now: - direct named-availability table `[state+0x66b2]` is not the missing differentiator by itself - both source-record import `0x00414490` and per-record stream-load `0x004120b0` do carry the relevant selector-bank bytes from persisted/source state into the live candidate family - but the stock `Data/BuildingTypes/*.bca` corpus currently keeps `[record+0xb8/+0xb9/+0xba/+0xbb]` at zero across every observed file, including `Warehouse.bca` and `Port.bca` - so the surviving frontier is no longer “does the lower loader import `[candidate+0xba/+0xbb]`?” but rather which later owner or alternate content path makes the live bank-qualified split differ from that all-zero shipped BCA corpus before `0x00412d70` clones or reuses one bank-qualified live candidate That makes the next Tier 2 question more concrete still: - how any nonzero bank-qualified template source under `[candidate+0xba]` versus `[candidate+0xbb]` is actually seeded above the stock all-zero BCA corpus, and then drives the later `Warehouse%02d` side in `Louisiana.gmp` - and whether that preserved bank/template state is the real bridge from the minimal recipe cluster to the shipped `5200 :: [7:0]` `Add Building Warehouse05` row ## Later Consumer-Side Reads Already Narrowed One broader non-hook pass now rules several tempting later neighbors onto the consumer side rather than the missing writer or projection seam. - `aux_candidate_collection_rebank_or_clone_records_by_availability_pass_and_refresh_owner_links` `0x00419230` does not seed `[candidate+0xba/+0xbb]` into the live candidate pool. It walks the already-imported auxiliary/source pool at `0x0062b2fc`, selects template records only when the linked live owner candidate at `[entry+0x173]` already passes the current bank test (`+0xba` on pass `0`, `+0xbb` on pass `1`), and then clones or reuses auxiliary entries before stamping the built-in `Port%02d` / `Warehouse%02d` roots back into `[entry+0x22]` and `[entry+0x04]`. - `world_grid_refresh_projected_rect_sample_band_and_flag_mask` `0x00418610` is also only a consumer of the same candidate-bank state. It resolves the current candidate through helper accessors, uses `candidate[0xba]` and the subtype/class predicates as mode inputs for the projected-rectangle sample pass, and never writes the candidate bank bytes. - the broader projected-offset lane at `0x0041a5fd..0x0041a944` is the same shape: after geometric reuse tests it resolves the current candidate owner, immediately branches on `candidate[0xba]`, and then either runs one world-cell occupancy sweep or falls back to localized status strings. Current direct disassembly still shows this path consuming the bank byte as a gate, not reconstructing it. So the surviving frontier is narrower again: - `0x00414490`, `0x004120b0`, and the shipped `BuildingTypes/*.bca` corpus explain how the stock zero bank bytes enter the source and live candidate families - `0x00419230`, `0x00418610`, and `0x0041a5fd..0x0041a944` explain how later auxiliary and projected-placement consumers react to already-materialized bank bytes - the `.smp` restore-side auxiliary temp-bank path is ruled out as a hidden bank-byte source too: `0x00413f80` restores queued temporary images with scalar runs, inline dword runs, and paired byte streams, but not the auxiliary fixed body or selector bytes `[+0xb8..+0xbb]`; and `0x0041a950`, when the restore flags demand it, only releases the current live aux collection and tail-jumps back into the same `0x004196c0 -> 0x00419230` import-plus-follow-on chain - the world-entry load branch does not add a hidden title-specific selector in between either: `0x00438c70` allocates the live candidate pool through `0x004131f0` and the auxiliary/source pool through `0x0041aa50`, and both constructors tail directly into the same fixed tagged-import families rooted at `0x005c93fc` and `.\Data\BuildingTypes\` - but the still-missing owner is the earlier non-stock writer or restore-time projection seam that makes some live candidates reach those later consumers with nonzero `[candidate+0xba/+0xbb]` despite the observed all-zero BCA corpus