Ground front-half add-building descriptor names

This commit is contained in:
Jan Petykiewicz 2026-04-19 02:05:08 -07:00
commit 3ea14a7d33
3 changed files with 139 additions and 105 deletions

View file

@ -291,19 +291,20 @@ Working rule:
grouped descriptor ids `521`, `526`, `528`, `548`, and `563` are now recovered as
`Add Building FarmGrain`, `Add Building Furniture Factory`, `Add Building Logging Camp`,
`Add Building Port01`, and `Add Building Warehouse05` respectively. The checked-in
`event-effects-building-bindings.json` artifact grounds those names from the stable RT3 1.05
`event-effects-building-bindings.json` artifact now widens that same bridge across the whole
first `67` add-building rows (`503..569`), grounding candidate names from the stable RT3 1.05
candidate-table order plus the direct `descriptor_id - 503` candidate-id bridge in
`0x00430270`
`0x00430270` and the load-side `0x0041ede0` name-catalog copy keyed by live candidate id
- the earlier `label_id - 2000` bridge for `548` and `563` is now known to be a false lead:
those numeric collisions hit the special-condition label table
(`Disable Building Stations`, `Completely Disable Money-Related Things`), but the extended
EventEffects table proves the actual grouped descriptors are add-building slots, not
special-condition verbs
- the compact opcode-`8` frontier therefore shifts:
the next static-analysis pass should widen the concrete add-building candidate-name bridge
beyond the already grounded `521/526/528/548/563` rows and then determine whether opcode `8`
on that shell-owned strip means a distinct add-building shell flow, not more missing-label
recovery
the next static-analysis pass should determine whether opcode `8` on that shell-owned
add-building strip means a distinct add-building shell flow, and then continue the candidate
bridge past the currently grounded `503..569` front half of the widened strip, not more
missing-label recovery
- the concrete owner strip above that bundle is grounded now too:
`0x00433060` is the direct non-direct serializer loop that writes `0x4e99/0x4e9a/0x4e9b`,
calls `0x00430d70` per live collection row, and sits beside the sibling `0x00433130` size/load