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

Tighten atlas seam annotations for transport and load/save

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-14 01:57:02 -07:00
commit aaf9310e62
5 changed files with 299 additions and 120 deletions
Download patch file Download diff file Expand all files Collapse all files

62
docs/control-loop-atlas/editor-breadth.md
View file

@ -89,7 +89,26 @@ The broader map-editor page owner is now bounded through
tighter too: the row pair shown in `Supply Only` and `Production Demand->Supply` is the `+0x08`
supplied-cargo selector, the row pair shown in `Demand Only` and `Production Demand->Supply` is
the `+0x1c` demanded-cargo selector, and the single amount field at `+0x04` is labeled `Annual
Demand:` only in mode `1` but `Annual Supply:` in modes `2/3`. The stronger new runtime-side
Demand:` only in mode `1` but `Annual Supply:` in modes `2/3`. The editor-side token boundary is
narrower now too: `0x004cf910` re-enters the same runtime importer `0x00435630` on entry, then
exact-matches the persisted `+0x08/+0x1c` token strings against visible live cargo names through
`0x005a57cf` while seeding the selector controls. There is still no special marker decode on this
side; unmatched token strings simply leave the selector index at its zero default while the raw
scenario-state strings stay in the recipe-book slab, and `0x004d0040` writes those selected cargo
names back into `+0x08/+0x1c` verbatim rather than normalizing them first. The write-side control
map is tighter now too: `0x59d8` updates the shared production-cap float at `book+0x3ed`,
`0x59d9` opens the rename modal, `0x59da/0x59db` cycle the selected book modulo `12`, and
`0x59de` commits the selected book ordinal. The five line-level write bands are exact in the
same way: `0x5a0a..0x5a0e` write the line-mode dwords at `book+0x3f1+line*0x30`,
`0x5a1e..0x5a22` copy one live cargo name into the supplied-token lane at
`book+0x3f9+line*0x30`, `0x5a32..0x5a36` copy one live cargo name into the demanded-token lane
at `book+0x40d+line*0x30`, and `0x5a50..0x5a54` write the per-line amount float to
`book+0x3f5+line*0x30` after the handler clamps the entered value to `<= 6`. The constructor-side
usage summary is bounded too: it scans the live city-or-region collection at `0x0062bae0`, keeps
only rows whose usage gates `[entry+0x242]` and `[entry+0x2f6]` are live and whose current
recipe ordinal `[entry+0x2f2]` matches the selected book, concatenates up to eight visible names
from `[entry+0x356]` with the separator at `0x005c9f38`, counts the rest, and then formats the
bounded usage summaries from localized ids `508` and `509`. The stronger new runtime-side
result is now a full chain rather than only the importer:
`scenario_state_rebuild_port_warehouse_cargo_recipe_runtime_tables` first imports those same five
lines into one repeated array of identical `0xbc`-byte runtime descriptors with no row-index
@ -120,9 +139,17 @@ The broader map-editor page owner is now bounded through
`[candidate+0x2a]` divided by the descriptor amount, while nonzero mode bypasses that scaling
path and publishes the row amount directly. At that point the candidate import strip is
structurally closed in current local evidence: the local import and rebuild seam is no longer
where the loader reconstructs runtime descriptor or membership tables, but only what the
unresolved supply-marker token family means before those already-grounded candidates are projected
back into live cargo ids. The immediate sibling
where the loader reconstructs runtime descriptor or membership tables. The remaining semantic gap
is narrower instead: current local evidence shows no hidden decode stage for the supply-marker
token family at all. The editor slab preserves unmatched token strings verbatim, the constructor
only reflects selector ordinals for tokens that already exact-match visible live cargo names, and
the importer later writes the exact-matcher result ids straight into the live descriptor lanes,
defaulting failed matches to cargo id `0`. The reset side narrows that further too:
`0x00436d10` only zero-fills the recipe books and reseeds their `# %1` name lane, so those
marker-like token strings are not coming from the built-in reset path. So the open question is
now only what upstream source, if any, authored those marker-like token strings before exact
matching. The
immediate sibling
`structure_candidate_refresh_recipe_runtime_mode_flags_0x78c_0x790` `0x00411ce0`, which for
subtype byte `[candidate+0x32] == 2` scans the imported descriptor strip and derives two compact
post-import flags from mode `0` presence and whether every mode-`0` descriptor keeps at least
@ -141,8 +168,9 @@ The broader map-editor page owner is now bounded through
side is explicit now too: `0x00436d10` is the shared reset-and-rebuild owner beneath startup and
world-entry paths. It zeroes the late scenario-state bands, seeds the fixed year defaults and
chairman-slot rows, rebuilds the two named availability collections at `[state+0x66b2]` and
`[state+0x66b6]`, re-seeds the twelve recipe books at `[state+0x0fe7]` from the fixed template
at `0x005c9f78`, refreshes selected-year state through `0x00409e80`, `0x00433bd0`,
`[state+0x66b6]`, zero-fills the twelve recipe books at `[state+0x0fe7]`, then only reseeds
their per-book name lane from the fixed `# %1` format string at `0x005c9f78` through
`0x0051b700 -> 0x00518de0`, refreshes selected-year state through `0x00409e80`, `0x00433bd0`,
`0x00435603`, and the year-gap scalar helper `0x00434130`, and only then re-enters
`0x00435630`, `0x0041e970`, `0x00412bd0`, and `0x00436af0`. The startup side is tighter now too:
`0x00438890` does not jump straight into one selector-specific file-load branch. It first
@ -250,16 +278,18 @@ The broader map-editor page owner is now bounded through
demand rows preserve string-bearing windows at `line+0x1c`, and the current probe shows those
conservatively as prefixed ASCII previews such as `..Grain`, `..Corn`, `..Livestock`, and
`..Milk`; local `objdump` now grounds `0x0041e9f0` itself as
`cargo_collection_find_entry_by_exact_name`, a direct exact-string walk over the live cargo
collection at `0x0062ba8c`. The importer at `0x00435630` feeds both token lanes through that same
matcher after one conservative in-place cleanup pass: empty strings are replaced with the first
live cargo name, and mode `3` loops until the supplied and demanded token strings no longer
compare equal. By contrast, the imported `supply-marker-entry` rows still feed nonprintable
windows such as `.@...` from `line+0x08` through that same exact matcher, and the resolver path
currently shows no special-case decoding for those marker forms. So the strongest static read is
now: the stem-like demand rows preserve cargo-name text but are skipped because their mode is
zero, while the nonzero imported marker rows are the live descriptor inputs yet likely fail exact
cargo-name resolution unless another upstream transform exists.
`cargo_collection_find_entry_id_by_exact_name`, a direct exact-string walk over the live cargo
collection at `0x0062ba8c` that returns one live cargo entry id or `0`. The importer at
`0x00435630` feeds both token lanes through that same matcher after one conservative in-place
cleanup pass: empty strings are replaced with the first live cargo name, and mode `3` loops
until the supplied and demanded token strings no longer compare equal. By contrast, the imported
`supply-marker-entry` rows still feed nonprintable windows such as `.@...` from `line+0x08`
through that same exact matcher, and the resolver path currently shows no special-case decoding
for those marker forms. So the strongest static read is now: the stem-like demand rows preserve
cargo-name text but are skipped because their mode is zero, while the nonzero imported marker
rows are the live descriptor inputs yet likely fail exact cargo-name resolution unless another
upstream transform exists; when they do fail, the importer writes the returned `0` ids directly
into the runtime descriptor cargo lanes instead of taking any special marker-side fallback path.
The wrapper layer above that query no longer looks like a hiding place for special treatment
either. Local `objdump` now shows `0x00412960` simply summing the two supply-side floats returned
by `0x00412650`, while `0x004129a0` returns the single zero-mode cap-scaled subrow lane directly;