fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: Stage 02 phase 1 read as a timeline; what arms the mission clock

Browse Source 
Disassembling all 25 timer triggers in threshold order turns the phase into
readable script: fade, BGM, then squadron deployments at 30/60/90/120/170/210/
240s each as deploy + move_order + objective_marker, with radio messages
interleaved and a late block at 1020-1170s.

Answers the open question from the previous entry: timer 0 is armed by
timer_set(1200, 180) followed by timer_resume, fired at 4.0s on the phase-intro
clock (timer 5), which is already running when the phase begins. So the mission
clock has a 1200-second limit.

And it independently confirms the arrival measurement: the timer0 @ 170.0s
trigger deploys symbol index 0x01 = ADN110, the first of the three squadrons the
phase-1 condition polls. The live run measured those three going active at
~155-165s of mission time, and the route table also says 170. Three independent
sources agree -- the route table, the trigger table, and the running game.

Open: whether a coroutine can re-arm its own trigger, and timer_set's second
argument (180), for which 'warning threshold' is a guess rather than a finding.
This commit is contained in:
Sylpheed RE agent
2026-08-25 20:43:07 +00:00
parent 446e029bae
commit eb7a065313
1 changed files with 41 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
docs/re/mission-phase-timers.md
View File

@@ -74,8 +74,46 @@ It also reframes the arrival timetable: the routes' `t=170` entry
same kind of thing — **the mission is substantially a timeline**, with unit
predicates deciding *what* happens at each scheduled point rather than *when*.
## ✅ Stage 02 phase 1, as a timeline — and what arms the clock
Disassembling all 25 triggers in threshold order turns the phase into a script
you can read:
```
timer5 @ 0.0s fade in
timer5 @ 0.5s play_bgm(0x3ED)
timer5 @ 1.0s damage_unit(TCN131, 0)
timer5 @ 4.0s timer_set(1200, 180) ; timer_resume ; set_flag(0) <-- arms timer 0
timer0 @ 1.0s radio 0x52, 0x53
timer0 @ 30.0s deploy + move_order(TCN105 group) ; radio 0x55
timer0 @ 60.0s radio 0x56
timer0 @ 90.0s deploy + move_order(idx 0x08) ; radio 0x57
timer0 @ 120.0s deploy + move_order(idx 0x43) + objective_marker ; radio 0x58, 0x59
timer0 @ 170.0s deploy + move_order(idx 0x01 = ADN110) ; radio 0x5A, 0x5B
timer0 @ 210.0s deploy + move_order(idx 0x33) + objective_marker
timer0 @ 240.0s deploy + move_order(idx 0x19)
timer0 @ 270/300/330 s radio only
timer0 @ 1020/1080/1140/1170 s radio only
```
### ✅ What arms the clock — the open question, answered
**`timer_set(1200, 180)` then `timer_resume`, at 4.0 s on the phase-intro
clock.** So timer 0 is started by the phase's own intro coroutine, with a
**1200-second limit**; timer 5 is already running when the phase begins. That
closes "which built-in arms or resets each timer" for the common case.
### ✅ It independently confirms the arrival measurement
The `timer0 @ 170.0s` trigger deploys **symbol index 0x01 = `ADN110`** — the
first of the three squadrons the phase-1 condition polls. The live run measured
those three flipping to *active* at roughly **155–165 s of mission time**
([mission-wave-arrivals](mission-wave-arrivals.md)), against a route table that
also says `170`. Three independent sources — the route table, this trigger
table, and the running game — agree.
## 🟡 Not settled
* **Which built-in arms or resets each timer.** Indices 0 and 5 are named from
the `+= dt` accumulator and the threshold magnitudes, not from a writer.
* Whether a coroutine started this way can *re-arm* its own trigger.
* Whether a coroutine started this way can **re-arm** its own trigger.
* `timer_set`'s second argument (`180`) — a limit and a warning threshold is the
obvious reading, but it is **not** established.