fabi/Syplheed-Reborn
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: enemies come into play per phase, deployed at phase start

Browse Source 
Cross-referencing Route_S02 with UnitGroup_S02 gives per-phase membership: phase
1 has 37 squadrons and 42 members, phase 2 has 34 and 36, phase 3 has 44 and 49,
with squadrons appearing in more than one phase so the totals overlap. The
measured deployed count, stable across many runs and from the first observable
instant, is 41 of 116 records.

41 against 42. The deployed set is the phase-1 roster, to within one record.

That makes every previously puzzling observation coherent. All 116 records exist
at mission load, confirmed on two stages, but only the current phase's squadrons
hold craft. Deployed is 41 before the ready room ends and never moves because
phase 1 deploys as a unit at load rather than on a schedule. No arrival was ever
observed in up to 435 s of verified-live flight with 42 kills because phase 1
never completed in any run, and phases 2 and 3 hold the other 85 members. And
the route times are within-phase fly-in timings rather than release times, which
fits the frames reading where Stage 01 phase 2's 1500, 1800 and 2100 are 50, 60
and 70 seconds at 30 Hz.

So enemies come into play per phase, deployed together at phase start, with each
squadron's route giving its entrance path and the moment it flies in.

The off-by-one is not explained and is recorded rather than rounded away. The
player's record may be counted differently, one squadron may hold craft in a way
the liveness read misses, or one phase-1 member may genuinely not deploy. A
one-record gap is exactly the size of the errors that have misled this corpus
before.

What advances a phase is now the single remaining question. It is directly
observable, since deployed would jump toward the phase-2 roster. It did not
happen in 435 s of verified-live flight with 42 craft destroyed, so it is
neither a short timer nor a small kill count. SUBObjectiveSettings names nine
objectives but carries only rewards and HUD strings, no trigger. Not yet
searched: StageMessageSet_S02.tbl, which has never resolved in the pak, and the
executable, whose decrypted image exists only in guest RAM.
This commit is contained in:
Sylpheed RE agent
2026-08-24 20:49:10 +00:00
parent 1f8a5b8dd5
commit aac791e0e9
2 changed files with 88 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/re/BACKLOG.md
View File

@@ -507,6 +507,18 @@ search cannot find a *schedule*.
❔ **Phases 2 and 3 are entirely untested** — every run has stayed in phase 1,
and phase advance was never located; a phase transition is now the most likely
place an arrival could exist.
* 🟡 **(2026-08-24) ANSWER: enemies come into play PER PHASE, deployed at phase
start** — [`mission-phase-deployment.md`](mission-phase-deployment.md). Static:
phase 1 = 37 squadrons / **42 members**, phase 2 = 36, phase 3 = 49. Dynamic:
**`deployed` = 41** from the first instant, never changing. **41 vs 42 — the
deployed set IS the phase-1 roster.** That makes everything coherent: all 116
records exist at load but only the current phase holds craft; no arrival was
ever seen because phase 1 never completed; route times are within-phase fly-in
timings, not release times. ⚠️ The **off-by-one is unexplained** and recorded,
not rounded away. ❔ **Single remaining question: what advances a phase.** It is
directly observable (deployed would jump), did not happen in 435 s with 42
kills, and `SUBObjectiveSettings` names 9 objectives but carries no trigger.
Unsearched: `StageMessageSet_S02.tbl` (never resolved) and the PE in guest RAM.
🔴 `SYLPH_HZ=3` refuted as a lever: it gave the LOWEST frame rate (8/s) with the
most kills, so pilot polling is not the throttle.
* ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**;

76
docs/re/mission-phase-deployment.md Normal file
View File

@@ -0,0 +1,76 @@
# Enemies come into play per PHASE, deployed at phase start
Status: 🟡 strongly supported and internally consistent, one unexplained
off-by-one; ❔ what advances a phase is now the single open question.
This is the answer the wave line of work has been converging on, and it is not
the one the route timetable first suggested.
## The evidence
**Static**, from `Route_S02.tbl` cross-referenced with `UnitGroup_S02.tbl`:
| phase | squadrons with routes | members |
|---|---|---|
| 1 | 37 | **42** |
| 2 | 34 | 36 |
| 3 | 44 | 49 |
| no route | 3 | 3 |
(Squadrons appear in more than one phase — 37+34+44 = 115 against 111 squadrons —
so the member totals overlap and do not sum to 116.)
**Dynamic**, measured repeatedly across many runs:
```
deployed = 41 of 116 records, from the first observable instant, never changing
```
**41 deployed against 42 phase-1 members.** The deployed set is the phase-1
roster, to within one record.
## What this makes coherent
Every previously puzzling observation falls into place:
* **All 116 records exist at mission load** — confirmed on two stages — but only
the current phase's squadrons hold craft.
* **`deployed` is 41 before the ready room ends and never moves**, because phase 1
deploys as a unit at load rather than on a schedule.
* **No arrival was ever observed** in up to 435 s of verified-live flight with 42
kills, because phase 1 never completed in any run — and phases 2 and 3 are
where the other 85 members are.
* **The route times are within-phase fly-in timings**, not release times, which
fits the frames reading (Stage 01 phase 2's t = 1500/1800/2100 → 50/60/70 s at
30 Hz).
So: **enemies come into play per phase, deployed together at phase start.** The
route entry gives each squadron its entrance path and the moment it flies in.
## The off-by-one is not explained
41 observed against 42 expected. Candidates, none tested: the player's own record
may be counted differently; one squadron may hold craft in a way the liveness
read misses; or one phase-1 member may genuinely not deploy. It is recorded
rather than rounded away — a one-record gap is exactly the size of the errors
that have misled this corpus before.
## ❔ The single open question: what advances a phase
This is now the whole remaining question, and it is the same one raised many
iterations ago in
[structures/stage-mission-tables.md](structures/stage-mission-tables.md) — the
stage record declares `Phase_1..3` but nothing found says what ends one.
What is now known that was not then:
* a phase advance is **directly observable** — `deployed` would jump from 41
toward the phase-2 roster, which is unmissable with the current probe;
* it did **not** happen in any run, including 435 s of verified-live flight with
42 craft destroyed, so it is not a short timer and not a small kill count;
* the likely gate is an **objective**, and `SUBObjectiveSettings_S02.tbl` names
nine of them but carries only rewards and HUD strings — no trigger.
Places not yet looked: `StageMessageSet_S02.tbl` (never resolved in
`GP_MAIN_GAME_E.pak`), and the executable, whose decrypted image is only
available in guest RAM.