From e70ecaf3821478f27f4ec23a577ed7af8b13e78f Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Mon, 24 Aug 2026 12:24:20 +0000 Subject: [PATCH] =?UTF-8?q?re:=20withdraw=20the=20"turrets=20don't=20move"?= =?UTF-8?q?=20hedge=20=E2=80=94=20Turret=20is=20a=20craft,=20not=20a=20shi?= =?UTF-8?q?p=20mount?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The user pointed out that the "Turret" enemy of the first few missions is its own craft type and must not be confused with the AA turrets mounted on capital ships. The tables agree, and I should have checked them before hedging: UN_e007_ADAN_Turret AI_ADAN_CraftSquadron_Rookie x70, _Veteran x19 UN_e007_ADAN_Turret_EX4 AI_ADAN_CraftSquadron_Ace x4 No *_Turret unit ever uses AI_Structure, which is reserved for the things that genuinely do not move -- asteroids, FloatingMine, SchlosBase, TransitPlatform, SpaceFortress. AI_ADAN_CraftSquadron_* is Type=Squad in AIParams with the full manoeuvre-weight block. The distribution matches "first few missions" too: 93 turret members across S01-S06, then nothing until S27. This retracts the caveat on the 10-of-116 result. Removing it makes that evidence stronger rather than weaker: the 106 inert records cannot be dismissed as immobile scenery, because Stage 02's turrets are craft that should be manoeuvring. The pre-allocated-roster reading survives a test it had been allowed to dodge. Lesson recorded in the doc: do not infer a unit's behaviour from its English name -- check its AIID. The roster is self-describing and the answer was already in the dump committed two iterations ago. --- docs/re/BACKLOG.md | 7 +++++-- docs/re/mission-wave-arrivals.md | 36 ++++++++++++++++++++++++++++---- 2 files changed, 37 insertions(+), 6 deletions(-) diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index 45a90bf..c9d8424 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -322,8 +322,11 @@ search cannot find a *schedule*. ❔ Still unmeasured: whether the timetable's `t` is frames or seconds. * πŸ”΄ **Diffing inside the 116 records did not find the arrival flag** (2026-08-24, same doc). 10 of 116 records are dynamic, 106 never change a byte - in 170 s β€” more support for the pre-allocated roster, though turret-heavy S02 - means "inert" β‰  "not arrived". No field transitions in groups of 3 at the + in 170 s β€” more support for the pre-allocated roster β€” and STRONGER than + first written: the "turrets don't move" hedge was withdrawn after the user + pointed out that early-mission "Turret" is a craft type, which the data + confirms (`UN_e007_ADAN_Turret` flies under `AI_ADAN_CraftSquadron_*`, never + `AI_Structure`). Lesson: check a unit's `AIID`, not its English name. No field transitions in groups of 3 at the predicted times. **Blocked on two of my own defects**: the recordβ†’unit-ID label resolved to `?` for all 116 (reuse `unit_discover.py`, do not re-derive), and `RECLEN=0x200` was assumed, not measured β€” the busiest fields sit at the diff --git a/docs/re/mission-wave-arrivals.md b/docs/re/mission-wave-arrivals.md index a5689f5..fbf81fc 100644 --- a/docs/re/mission-wave-arrivals.md +++ b/docs/re/mission-wave-arrivals.md @@ -103,10 +103,38 @@ That is a second, independent line of support for the reading in the section above: if all 116 were live entities they would be moving, and position words would churn in most of them every tick. Instead the overwhelming majority are inert, which is what a pre-allocated roster of not-yet-activated members looks -like. It is still not proof β€” Stage 02's roster is heavy with -`UN_e007_ADAN_Turret` entries, and a turret does not move even when it is very -much alive, so "inert" and "not yet arrived" are not distinguishable from this -run alone. +like. + +**Correction (2026-08-24, from the user).** The first version of this paragraph +hedged the conclusion by saying Stage 02's roster is heavy with +`UN_e007_ADAN_Turret` and "a turret does not move even when it is very much +alive", so inert and not-yet-arrived could not be told apart. **That hedge was +wrong, and it was wrong because I read the unit's English name instead of its +data.** "Turret" in the early missions is a *craft* β€” a distinct enemy type β€” not +an anti-aircraft mount on a capital ship. The tables say so plainly: + +| | | +|---|---| +| `UN_e007_ADAN_Turret` | `AI_ADAN_CraftSquadron_Rookie` Γ—70, `AI_ADAN_CraftSquadron_Veteran` Γ—19 | +| `UN_e007_ADAN_Turret_EX4` | `AI_ADAN_CraftSquadron_Ace` Γ—4 | +| `AI_Structure` is used by | asteroids, `UN_mn500_ADAN_FloatingMine`, `UN_bf001_TCAF_SchlosBase`, `UN_bf002_TCAF_TransitPlatform`, `UN_be005_ADAN_SpaceFortress` | + +`AI_ADAN_CraftSquadron_*` is `Type = Squad` in +[`AIParams`](structures/stage-mission-tables.md), with the full manoeuvre-weight +block β€” these things fly. `AI_Structure` exists precisely for the units that do +not, and no `*_Turret` unit ever uses it. The type also matches "an enemy of the +first few missions": 93 turret members in total, in S01 (20), S02 (21), S03 (11), +S04 (6), S05 (12), S06 (19), and then nothing until S27 (4). + +So the caveat is withdrawn, and removing it makes the evidence **stronger**, not +weaker: the 106 inert records cannot be explained away as immobile scenery, +because Stage 02's turrets are craft that should be manoeuvring. The reading +that they are pre-allocated, not-yet-activated roster entries survives a test it +would otherwise have dodged. + +The general lesson, which cost a wrong hedge: **do not infer a unit's behaviour +from its English name β€” check its `AIID`.** The roster is self-describing and +the answer was already in the committed dump. ## πŸ”΄ No transition matching the arrival timetable