Clarify add-building batch row semantics

This commit is contained in:
Jan Petykiewicz 2026-04-19 02:08:05 -07:00
commit 32e7d797fe
2 changed files with 14 additions and 4 deletions

View file

@ -10856,6 +10856,11 @@ fn parse_real_grouped_effect_row_summary(
row_shape = "scalar_assignment".to_string();
semantic_family = "scalar_assignment".to_string();
}
if descriptor_metadata.is_some_and(|metadata| metadata.parameter_family == "world_building_spawn")
{
row_shape = "building_spawn_batch".to_string();
semantic_family = "building_spawn_batch".to_string();
}
let mut notes = Vec::new();
if locomotive_name.is_some() {
@ -11708,6 +11713,9 @@ fn build_real_grouped_effect_semantic_preview(
};
format!("Set {label} to {state}")
}
"building_spawn_batch" => format!(
"Batch place {label} with scalar {raw_scalar_value}, count {value_byte_0x11}, and span words [{value_word_0x14}, {value_word_0x16}]"
),
"timed_duration" => format!(
"Set {label} to {raw_scalar_value} for {value_word_0x14} years {value_word_0x16} months"
),

View file

@ -301,10 +301,12 @@ Working rule:
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 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
direct disassembly of `0x00430270` now shows that the add-building consumer does not branch on
grouped opcode at all for descriptor strip `503..613`; it consumes the descriptor-derived
candidate id, placement count byte `0x11`, and the packed span words at `0x14/0x16`.
The next static-analysis pass should therefore target the remaining span-field meaning and
shell-owned placement-flow ownership on that strip, 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