fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

backlog: n settled as a unit count; in-table roster is the key-resolution rule

Browse Source
This commit is contained in:
Sylpheed RE agent
2026-08-25 10:04:34 +00:00
parent 7db341f76a
commit a1820b1335
1 changed files with 25 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
docs/re/BACKLOG.md
View File

@@ -900,8 +900,31 @@ the route-name kind letters `F/S/A/M/B`, what activates a sub-objective, and
durations, spawn triggers and arrival positions are not in `UnitGroup`. The
stage record names two untouched candidates: `Formation_*.tbl` (formation
geometry, possibly its timing) and `EnumSquadron_Test.tbl`. Also still open: the
4-byte record key and the member field `n`. ~~the missing S17–S23 stage
records~~ — **SETTLED 2026-08-25, and half the premise was wrong.**
4-byte record key. ~~the member field `n`~~ — **SETTLED 2026-08-25, see below.**
~~the missing S17–S23 stage records~~ — **SETTLED 2026-08-25, and half the
premise was wrong.**
* ✅ **`n` is the number of units the member tuple instantiates**, filling slots
of the squadron's formation. `FormationSet_S<NN>.tbl` records are **slot
lists** — `1 + 8·FrameCount` fields, exactly (4→33, 14→113, 30→241, 32→257).
Resolving every squadron's `FormationID` and comparing: **`sum(n) ≤ FrameCount`
holds 1159/1160 across all 28 stages, 0 unresolved, 539 filling the formation
exactly.** The lone violation is a debug leftover (S20, `AI_Test` /
`MessageSet_test`, `Formation_1_only` with `n=2`) and is recorded, not swept
up. The old "`n` is not the `_NN` suffix of `FormationID`" was right but drew
the wrong conclusion — **the suffix IS `FrameCount`**, so `n=9` against `_30`
just means 9 units in 9 of 30 slots.
* ✅ **`FormationID` resolves by an in-table roster, not by hashing** — 0/16
resolve via `name_hash`; `FormationSet_S02.tbl` has 17 records for 16
formations and the extra one carries no `FrameCount`, its fields being
`(tag, name, "")` with the **tags equal to the record keys**. Same convention
as `Enumerate_Squadrons`. **Second sighting — treat it as the rule for the next
table.**
* 🟡 **Does NOT close the 387-vs-~300 gap** in `roster-to-craft-link.md`. Σ`n`
over Stage 02 is 387 vs 296–300 live craft, but that was measured mid-mission
after kills and squadrons deploy across phases, so they are not comparable as
they stand. The earlier rejection of `n` assumed everything deploys at once —
**still untested**. The record-key derivation also stays ❔ (the tag is not
`name_hash`; a second hash function is unidentified).
* ✅ **S18–S23 stage records were never missing.** `stagetbl.py Stage_S18` returns
a full six-record definition and always would have; it was never run. They omit
the literal `Stage_S<NN>` (no per-stage `.xpr`; `AIParams`/weapons/strings/