From 1f8a5b8dd571de63e5ffc1766769adcc4f4b49c5 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Mon, 24 Aug 2026 20:43:48 +0000 Subject: [PATCH] re: deployment is resolved at mission load; withdraw the take-off hypothesis MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The run meant to catch a deployment step at take-off removed the hypothesis instead. One continuous series of 64 samples over about 380 s, started when the roster first appeared and running through the ready room, the transition to flight at +47 s, and several minutes of flight, shows deployed at 41 and craft at 292 with not one change in either number. So the previous iteration's suggestion that deployment is a single step at take-off is withdrawn. It rested on ready room 39/276 against flight 41/300, which came from different runs and was flagged 🟡 for that reason. Measured within one run the values are identical before and after take-off, so that gap was cross-run variance. What this does establish is stronger. The roster is already deployed when the roster first exists: 41 of 116 records hold craft before the ready room ends and nothing changes afterwards. Together with the roster identity confirmed on two stages and the earlier piloted runs, Stage 02 phase 1 has no observable in-mission arrival at all -- not in the ready room, not at take-off, and not in up to 435 s of verified-live flight during which the player destroyed 42 craft. The route times still mean something, since 0/90/120/170/210/240 and Stage 01's 1500/1800/2100 are structured rather than noise. The frames reading remains the best fit, and under it they are most likely fly-in animation timings applied at load rather than release times. Two things stay open and are recorded as such. Phases 2 and 3 have never been tested: every run has stayed in phase 1 and phase advance was never located, so a phase transition is now the most likely place an arrival could exist. And this particular run had no pilot, so it adds nothing on event-gating; the piloted 435 s run already covers that ground. --- docs/re/BACKLOG.md | 13 ++++++++ docs/re/mission-arrival-watch.md | 54 ++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+) diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index f350b837..35b38210 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -494,6 +494,19 @@ search cannot find a *schedule*. at TAKE-OFF**, not a schedule unfolding in-mission (different runs, so suggestive only). **Next: one ~400 s run spanning ready room → take-off → flight** to catch the 39→41 step in one continuous series. +* ✅🔴 **(2026-08-24) DEPLOYMENT IS RESOLVED AT MISSION LOAD.** One continuous + series, 64 samples over ~380 s from roster-appearance through the ready room, + take-off (`IN FLIGHT` at +47 s) and flight: **`deployed=41, craft=292`, zero + changes throughout.** 🔴 **My own "deployment happens at take-off" is withdrawn** + — the 39/276 vs 41/300 gap was cross-run variance; within one run there is no + step. ⇒ **Stage 02 phase 1 has NO observable in-mission arrival**: 41 of 116 + records are deployed before the ready room ends, and nothing changes in the + ready room, at take-off, or in up to 435 s of verified-live flight with 42 + kills. Route times most likely encode **fly-in animation timing applied at + load**, not release times (frames reading: S01's t=2100 → 70 s at 30 Hz). + ❔ **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. 🔴 `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**; diff --git a/docs/re/mission-arrival-watch.md b/docs/re/mission-arrival-watch.md index 7442cebb..4e906dae 100644 --- a/docs/re/mission-arrival-watch.md +++ b/docs/re/mission-arrival-watch.md @@ -612,3 +612,57 @@ unfolding during the mission. **Next:** one run with the probe waiting for the roster and sampling for ~400 s, long enough to span ready room → take-off → flight in a single continuous series. That would show the 39 → 41 step directly, or refute it. + +--- + +# ✅ Deployment is resolved at mission LOAD (2026-08-24) + +The run that was supposed to catch a take-off step instead removed the +hypothesis. One continuous series, 64 samples over ~380 s, started when the +roster appeared and running through the ready room, take-off (`IN FLIGHT` at ++47 s) and the whole flight: + +``` ++ 0.3s deployed= 41 craft=292 + … 64 samples, ZERO changes … +last deployed= 41 craft=292 +``` + +**Not one change in either number**, across the ready room, the transition, and +several minutes of flight. + +## 🔴 Refuted: my own "deployment happens at take-off" + +The previous entry noted ready room 39/276 against flight 41/300 and suggested +deployment was a single step at take-off, flagged 🟡 because the numbers came +from *different runs*. Measured within one run, there is no step: the values are +identical before and after take-off. **That was cross-run variance and the +hypothesis is withdrawn.** + +## What this establishes + +**The roster is already deployed when the roster first exists** — 41 of 116 +records hold craft before the ready room ends, and nothing changes afterwards. +Combined with everything else in this file: + +* every participant is allocated at mission load (roster identity, two stages); +* 41 of 116 records are deployed from the first observable instant; +* no `0 → n` transition occurs in the ready room, at take-off, or in up to 435 s + of verified-live flight with 42 kills. + +So **Stage 02 phase 1 has no observable in-mission arrival at all.** Whatever the +route table's first-keyframe times do, they do not release squadrons on a clock +that this instrumentation can see, and they do not respond to the player +destroying 42 craft. + +## What remains open + +* The route times still mean *something* — the values 0/90/120/170/210/240 and + S01's 1500/1800/2100 are structured, not noise. The frames reading + (t = 2100 → 70 s at 30 Hz) remains the best fit, in which case they are most + likely **fly-in animation timings applied at load**, not release times. +* Phases 2 and 3 are entirely untested. Every run has stayed in phase 1, and + phase advance was never located. If arrivals exist, a phase transition is the + most likely place to see one. +* This run had **no pilot**, so it says nothing new about event-gating; the + piloted 435 s run already covers that.