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

re: the arrival timetable confirmed live -- t is in SECONDS

Browse Source 
ADN110/111/112 all carry first-keyframe time 170 on their _p1F routes, and in a
live run all three flipped from not-deployed to active at ~143s on the probe
clock. The probe zero sits roughly 10-20s into the mission, putting the arrival
at ~155-165s of mission time against a predicted 170.

That pins the unit as seconds: 170 frames at 30fps is 5.7s, so they would have
been active at the first sample and demonstrably were not. Three squadrons
sharing one timetable entry changing state in the same 5s window is not
coincidence. Flagged as a match rather than an exact measurement -- the probe
clock is not aligned to phase start.

Supersedes mission-arrival-watch.md's headline negative: 'no arrival has ever
been observed across six runs' was an instrument limit, not a fact about the
game. Its craft-counting analysis stays accurate -- craft counts conflate
deployment with attrition and cannot see an arrival at all.
This commit is contained in:
Sylpheed RE agent
2026-08-25 15:07:08 +00:00
parent ab08c77388
commit 852256525d
2 changed files with 49 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
docs/re/mission-arrival-watch.md
View File

@@ -1,8 +1,19 @@
# Six runs, no arrival — and an accidental control
> 🔴 **SUPERSEDED 2026-08-25 — the premise was an instrument limit, not a fact
> about the game.** Arrivals *do* happen and are directly observable in the
> script VM's per-unit table: ADN110/111/112 flip from "not deployed" to
> "active" at ~143 s, matching their routes' `t=170` timetable entry, while the
> count of active records climbs 24 → 35 in four minutes. Everything below
> remains accurate about **craft counting**, which conflates deployment with
> attrition and cannot see an arrival. See
> [script-runtime-probe](script-runtime-probe.md) and
> [mission-wave-arrivals](mission-wave-arrivals.md).
Status: ✅ the deployment structure reproduces exactly; ✅ losses require the
player; 🔴 **no arrival has ever been observed**, across six runs; ❔ whether
mission/phase time is advancing at all is now the prime suspect and is untested.
player; ~~🔴 no arrival has ever been observed~~ — **superseded, see the banner above**;
the "is mission time advancing at all?" suspicion is also answered: it is, and
the timetable is in seconds.
## ✅ The deployment structure reproduces byte-for-byte

40
docs/re/mission-wave-arrivals.md
View File

@@ -1,9 +1,14 @@
# The arrival timetable, and what the entity table is really counting
Status: ✅ the static arrival timetable is in `Route_S<NN>.tbl`; 🟡 the runtime
entity table appears to be one record per roster member, pre-allocated (n = 1);
🔴 counting entity records does **not** show wave arrivals; ❔ the timetable's
time unit is still unmeasured.
Status: ✅ the static arrival timetable is in `Route_S<NN>.tbl`;
✅ **arrivals ARE observable — and the time unit is SECONDS** (2026-08-25, see
below); 🔴 counting *entity records* does not show them, which is what the
original negative measured.
> ✅ **CORRECTION 2026-08-25.** "Counting entity records does not show wave
> arrivals" is still true, but the conclusion drawn from it — that arrivals
> could not be seen — was wrong. The **script VM's own unit table** shows them
> directly. See [script-runtime-probe](script-runtime-probe.md).
## ✅ The arrival timetable is the routes' first keyframe time
@@ -23,6 +28,33 @@ is measured **from the start of its phase**, not from the start of the mission.
Entering a phase releases that phase's t = 0 group, and the rest arrive on the
offsets above.
## ✅ The timetable is confirmed live, and `t` is in SECONDS
The three squadrons the phase-1 clear condition polls — ADN110, ADN111, ADN112 —
all have **first-keyframe time `170`** on their `_p1F` routes:
```
Route_ADN110_p1F FrameCount=3 first field: 170
Route_ADN111_p1F FrameCount=3 first field: 170
Route_ADN112_p1F FrameCount=2 first field: 170
```
In a live run (`data/phase-watch-s02.txt`) all three flipped from
state 1 (not deployed) to state 2 (active) at **~143 s on the probe's clock**.
The probe starts after flight entry and after the pilot bind, so its zero sits
roughly 10–20 s into the mission — putting the arrival at about **155–165 s of
mission time against a predicted 170**.
**That pins the unit as seconds.** The alternatives are not close: 170 *frames*
at 30 fps is 5.7 s, so those squadrons would have been active at the first
sample, and they demonstrably were not. Three squadrons sharing one timetable
entry all changing state in the same 5 s sampling window is not coincidence.
⚠️ It is a **match, not an exact measurement** — the probe clock is not aligned
to phase start, so this bounds the unit rather than verifying the value to the
second. Logging mission start and phase start in the same stream would close
that.
That is the "algorithm with parameters" this line of work was after: the
schedule is data — squadron, phase, arrival time, and the path flown in — spread
across `UnitGroup` (who) and `Route` (when and from where). Stage 02 phase 1