jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
rrt/artifacts/exports/rt3-1.06/runtime-effect-kind8-late-bringup-note.md

7.4 KiB
Raw Blame History

Runtime Effect Kind-8 Late Bringup Note

This note extracts the current grounded late-bringup facts for the ordinary startup runtime-effect lane, so the remaining recovery work does not have to keep jumping between the queue, the large function map note, and the broader subgraph artifacts.

Grounded Ordering

  • world_load_saved_runtime_state_bundle 0x00446d40 directly reaches scenario_event_collection_refresh_runtime_records_from_packed_state 0x00433130.
  • The same loader does not directly reach scenario_event_collection_service_runtime_effect_records_for_trigger_kind 0x00432f40.
  • world_entry_transition_and_runtime_bringup 0x00443a50 is the owner above both restore and service.
  • Current function-map.csv notes for 0x00443a50 already state that:
    • the tagged load phase reloads event runtime records through 0x00433130
    • the one-shot kind-8 service through 0x00432f40 only runs much later in the final reactivation tail
    • shell-profile latch [0x006cec7c+0x97] is cleared after that late kind-8 service

Late-Tail Candidate Branches

  • The remaining unknown is therefore no longer abstract restore-vs-service ordering.
  • The remaining unknown is:
    • which late bringup branch or retagger between 0x00433130 reload and final kind-8 0x00432f40 service materializes the live mutation-capable records

Checked Corpus Counts

  • The checked export artifacts/exports/rt3-1.06/compact-event-dispatch-cluster-counts.json now keeps the ordinary rt3_105/maps compact-dispatch corpus grounded without re-running the wider inspection command.
  • Current corpus totals are:
    • 41 maps scanned
    • 38 maps with dispatch-strip rows
    • 318 nondirect compact dispatch-strip rows total
    • 0 rows with recovered trigger kind
    • 10 add-building grouped occurrences across 7 descriptor keys (Barracks, Bauxite Mine, FarmGrain, Furniture Factory, Logging Camp, Port01, Warehouse05)
  • The same export now also carries the concrete carrier-map paths directly through add_building_descriptor_map_paths and add_building_signature_condition_cluster_map_paths, including:
    • Texas Tea.gmp for 548 Add Building Port01
    • Louisiana.gmp for 563 Add Building Warehouse05
    • Alternate USA.gmp for the repeated FarmGrain / Logging Camp ge34 family
    • Chicago to New York.gmp and Pacific Coastal.gmp for the mixed [-1:4] cluster
  • The widened counts surface now also keeps the strongest full nondirect families visible beyond the add-building subset:
    • dispatch_signature_condition_cluster_occurrence_counts now shows the broadest checked family is nondirect-ge1e-h0001-0360-0004-0100-0200-p0000-0000-0000-ffff :: [864:4] at 36 grouped occurrences across 18 maps
    • the next family remains the mixed [-1:4] cluster at 27 grouped occurrences across 14 maps
    • dispatch_signature_condition_cluster_descriptor_keys keeps the first cluster grounded on the variable/status descriptor family (Economic Status, Game Variable 1..4, Company Variable 1..4) and keeps the second cluster grounded on that same family plus the two checked add-building descriptors Barracks and Bauxite Mine
  • That keeps the remaining late-bringup/control-lane question narrow:
    • ordinary loaded nondirect rows already reach the 0x00431b20 mutation strip at scale
    • but the missing trigger-kind lane is still the blocker above the already-grounded descriptor bridge

Direct Trigger-Kind Gate

Fresh direct disassembly now keeps that control lane explicit rather than inferred:

  • 0x00444d92
    • calls 0x00432f40 with trigger kind 8
    • then clears shell-profile latch [0x006cec7c+0x97]
  • 0x00432f40
    • iterates the live runtime-effect collection
    • calls 0x004323a0 for each row with the requested trigger kind
    • records whether any row fired
    • if collection flag [this+0x88] is raised, reruns the same service loop with trigger kind 0x0a
  • 0x004323a0
    • returns immediately unless [event+0x81f] == 0
    • returns immediately unless [event+0x7ef] == trigger_kind
    • only after that exact compare does it continue into the compact dispatch body

So the active question is no longer whether the trigger kind is a direct row gate. It is where the ordinary loaded rows get a nonzero [event+0x7ef] that matches the later kind-8 or follow-on kind-0x0a service.

Reload-Side Boundary

The ordinary reload strip is bounded in the same negative way now:

  • 0x00433130
    • restores tagged record families 0x4e99, 0x4e9a, and 0x4e9b
    • reads one fixed 4-byte scalar block through 0x00531150
    • loops live rows through per-record restore helper 0x0042db20
    • clears collection flag [this+0x88] = 0 before returning
  • that reload path does not pass any trigger-kind argument analogous to the later 0x00432f40(kind) service

So the remaining late-bringup/control-lane frontier stays between reload and service rather than inside the already-bounded restore loop itself.

Current Writer Census

The direct writer set for [event+0x7ef] is narrower now too:

  • 0x0042d5a0
    • zero-initializes the live runtime-effect record control band
    • clears [event+0x7ee], [event+0x7ef], [event+0x7f4], [event+0x81f], [event+0x823], and [event+0x82b]
  • 0x0042e11a
    • straight copy helper over the same control band
    • copies [event+0x7ee/+0x7ef/+0x7f0/+0x7f4...] from one live row into another
  • 0x00430b50
    • the already-grounded follow-on runtime-effect builder
    • reaches the fresh live row through 0x00432ea0 -> 0x0042d5a0
    • then seeds [event+0x7ef] to 2 or 3 from the current [world+0x11] threshold
    • also sets [event+0x7f5] = 1
  • 0x00443526 and 0x00443601
    • the already-grounded late retags to 5 and 2

So the active periodic-company/control-lane question narrows again:

  • ordinary reload 0x00433130 -> 0x0042db20 does not itself pass a trigger kind
  • the late service strip gates strictly on [event+0x7ef]
  • and the currently grounded nonzero seed outside the scenario-name retags is the follow-on builder reached from the service/dispatch family rather than from the reload loop itself

Post-Load Scenario Fixup

  • shell_apply_scenario_name_specific_post_load_world_and_object_fixups 0x00442c30 is called from 0x00443a50 at 0x00444b50.
  • This branch is currently prose-first, not graph-first:
    • a direct subgraph export on 0x00442c30 collapses to the seed node
    • the useful evidence lives in the grounded function-map note rather than note-reference edges
  • The function-map note grounds several concrete mutations across collections rooted at:
    • 0x0062be18
    • 0x0062bae0
    • 0x006ada80
    • 0x0062b268

Explicit Trigger-Kind Retags Already Grounded

  • SP - GOLD branch at 0x00443526
    • rewrites [event+0x7ef] from 1 -> 5
    • live runtime-event id 1
    • gated by [world+0x66de]
    • checked payload root kind 7 with subtype byte 5
  • Labor branch at 0x00443601
    • rewrites [event+0x7ef] from 0 -> 2
    • live runtime-event id 0x0d
    • gated by [world+0x66de]
    • checked 0x3c -> 0x3d child payload pair with the matched negative scalar sentinel

Current Best Next Recovery Question

  • Which late bringup branch between:
    • 0x00433130 reload
    • 0x00442c30 scenario-name post-load fixups
    • and final kind-8 0x00432f40
  • is responsible for the live kind-8 records that already carry mutation-capable compact payloads in ordinary nondirect bundles.