From ea155ea0352bbc782a564afb41cabc9ad9c8121e Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Wed, 26 Aug 2026 04:47:10 +0000 Subject: [PATCH] re: the wave timetable's t is SECONDS, measured against the live speed law Route keyframes are (time, quat x4, pos x3), so each consecutive pair gives an implied speed. The flight-speed law was measured live against a real-time clock (cruise ~420, max ~1530 world units/s), which makes it an independent yardstick in known units. Across all 28 stage tables, 331 Route_* records and 1104 keyframe pairs: under SECONDS not one pair exceeds the 1530 ceiling (median 147); under frames at 30 or 60 fps, 89% and 94% of the game's routes would demand impossible speeds. Two corrections recorded. A first pass silently skipped non-numeric fields while flattening records, shifting every later value -- it reported a median implied speed of 65534, suspiciously 2^16, which is what exposed it. And the remaining outliers were Frame_S_Asteroid records, not routes; the final measurement filters by record kind rather than dropping whole stages. --- docs/re/BACKLOG.md | 5 ++- docs/re/mission-wave-arrivals.md | 58 ++++++++++++++++++++++++++++++++ 2 files changed, 62 insertions(+), 1 deletion(-) diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index e64822ab..125c156d 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -395,7 +395,10 @@ search cannot find a *schedule*. 🟑 116 is exactly Stage 02's roster member count, suggesting one pre-allocated record per member (n=1, NOT promoted; the refutation needs another stage's save, which we do not have β€” only slot 01 / Stage 02 exists). - ❔ Still unmeasured: whether the timetable's `t` is frames or seconds. + βœ… **Settled 2026-08-26: `t` is SECONDS.** Consecutive route keyframes give an + implied speed; checked against the live-measured player ceiling (~1530 world + units/s), **0 of 1 104** pairs exceed it under seconds while 89–94 % do under + frames at 30/60 fps. See [`mission-wave-arrivals.md`](mission-wave-arrivals.md). * βœ…πŸŸ‘ **Motion-independent liveness probe works; `n` is probably craft-per-member** (2026-08-24) β€” [`mission-liveness-probe.md`](mission-liveness-probe.md). Enumerating by definition pointer instead of by motion removes the Β±10 noise diff --git a/docs/re/mission-wave-arrivals.md b/docs/re/mission-wave-arrivals.md index 518fc121..bddbcb91 100644 --- a/docs/re/mission-wave-arrivals.md +++ b/docs/re/mission-wave-arrivals.md @@ -418,3 +418,61 @@ Two things are needed before this run type can settle the question: the hunt did not actually destroy anything in 160 s, in which case this run does not test the event-gated model either. `REMAINING OB` at `0xbdb59668` still did not read as a counter, so that check remains unavailable. + +## βœ… The timetable's `t` is SECONDS (2026-08-26) + +This was recorded as "❔ still unmeasured: whether the timetable's `t` is frames +or seconds". It is seconds, and the evidence is a physical one rather than an +argument from plausibility. + +**The method.** A route record is a list of `(time, quatΓ—4, posΓ—3)` keyframes, so +each consecutive pair gives a distance and a time delta β€” an implied speed. The +flight-speed law was measured **live, against a real-time clock** +([flight-speed-law.md](flight-speed-law.md)): the player's craft cruises at ~420 +world units/s and tops out at **~1530** under `RT`. That is an independent +yardstick in known units, so the two readings of `t` can simply be checked +against it. + +**The result.** `Route_*` records across all 28 stage tables β€” 331 records with +two or more keyframes, **1 104** consecutive pairs: + +| reading of `t` | median | p99 | max | pairs above 1 530 | +|---|---|---|---|---| +| **seconds** | 147 | 959 | **1 310** | **0 of 1 104 (0.0 %)** | +| frames @30 fps | 4 422 | 28 758 | 39 309 | 984 (89.1 %) | +| frames @60 fps | 8 844 | 57 516 | 78 617 | 1 037 (93.9 %) | + +Under **seconds** not one keyframe pair in the game requires a craft to exceed +the measured player maximum, and the median 147 sits comfortably below cruise β€” +which is what waypoint-to-waypoint averages should look like once turns are +included. Under either **frames** reading, ~90 % of the game's routes would +demand impossible speeds. There is no overlap to argue about. + +### ⚠️ Two corrections made while measuring this + +Both are the same kind of mistake and worth recording: + +1. **A first pass silently skipped non-numeric fields** while flattening a + record, which shifts every subsequent value and corrupts the frame split. It + produced a median implied speed of 65 534 β€” suspiciously exactly 2^16, which + is what gave it away. Fixed by rejecting a record outright rather than + dropping a field from it. +2. **The remaining outliers were not routes at all.** Seven stage tables gave + maxima in the tens of thousands; every offending record was named + `Frame_S_Asteroid`. The corpus already records that the 8-value frame is + not universal, and these are the cases. The final measurement therefore + filters on the record name (`Route_*`, 1 389 of the 1 477 records; the rest + are 60 `Frame_*` and 28 `Enumeration_*`) rather than excluding whole stages β€” + a filter by kind, not a filter that removes inconvenient numbers. + +### What this does not settle + +* **331 of the 1 389 `Route_*` records** carry two or more keyframes and pass the + `FrameCount*8` length identity; the rest are single-keyframe (arrival only) or + do not fit the 8-value frame. The conclusion rests on those 331. +* The **~1.25Γ— world-unit factor** noted in `flight-speed-law.md` is not applied + here; it would move the ceiling, not the 30Γ— and 60Γ— gaps, so it cannot change + the answer. +* Whether `t` is measured from **phase start** (as the arrival schedule reads it) + or from mission start is unchanged by this β€” that was already settled + separately.