# ✅ The MISSION timer is a second, separate clock — and `timer_set`'s second argument is a second COUNTDOWN `mission-phase-timers.md` left this open: "`timer_set`'s second argument (`180`) — a limit and a warning threshold is the obvious reading, but it is **not** established." It is established now, and **the obvious reading is wrong**. This clock has nothing to do with the 32 stopwatches in [isl-timers](isl-timers.md); it is five separate scalar fields on the same ScriptPhase, driven by its own updater. ## The five fields Zeroed together by `sub_8225FEF8` (`0x82260084`–`0x82260098`): | field | type | meaning | |---|---|---| | `[phase+304]` | f32 | **elapsed**, counts **up** | | `[phase+308]` | f32 | **countdown A**, counts **down** | | `[phase+312]` | f32 | **countdown B**, counts down *only after A reaches 0* | | `[phase+316]` | int | **running** — gates the elapsed counter | | `[phase+320]` | int | **armed** — gates the two countdowns | ## The five built-ins All are stubs into the ScriptPhase vtable, slots 90–94 (`0x8226C690`–`0x8226C6F0`): | built-in | slot | what it does | calls disc-wide | |---|---|---|---| | 127 `timer_set(a, b)` | 94 | `armed = 1; A = (f32)local[0]; B = (f32)local[1]` | 29 | | 123 `timer_resume` | 90 | `running = 1` | 40 | | 124 `timer_stop` | 91 | `running = 0; armed = 0` | 170 | | 125 `timer_reset` | 92 | `elapsed = A = B = 0.0; armed = 0` | **0** | | 126 `timer_elapsed` | 93 | returns `elapsed` as a double in `[phase+176]` | **0** | `timer_set` reads its two arguments as **doubles** at `0(r4)` and `8(r4)`, `r4` being the converted locals array — so `local[0]` and `local[1]`. ## ✅ The update — `sub_822639B8(phase, dt)` Called from **`ScriptPhase::Update` at `0x82263528`**, with **`fmr f1, f30`** — the *same* `dt` the stopwatch bank gets at `0x82263480`. So this clock counts the same **seconds** ([isl-timers](isl-timers.md)), and `600 / 900 / 1200 / 1800` and `180` are 10 / 15 / 20 / 30 minutes and 3 minutes. ``` 822639C8 if [+316] != 0: [+304] += dt ; elapsed counts UP 822639E4 if [+320] != 0: 822639F4 if [+308] > 0.0: [+308] -= dt ; A counts down ... 82263A00 else: [+312] -= dt ; ... then B does 82263A10 if [+312] < 0.0: [+312] = 0.0 ``` ### 🔴 That refutes "a limit and a warning threshold" A threshold would be **compared** against the countdown. `[+312]` is never compared with `[+308]` anywhere. It is *decremented*, and the `bc 12, gt` at `0x822639FC` jumps **away** to the `A -= dt` arm — so `B -= dt` runs **only** in the `A <= 0` branch. The two are **sequential countdowns**: a per-mission period, then a fixed second period. ## ✅ Every mission agrees, and the second value never varies 29 `timer_set` sites across the disc: | first argument | sites | |---|---| | 600 | 19 | | 1200 | 8 | | 900 | 1 (Stage 26) | | 1800 | 1 (Stage 24) | | **second argument** | **180 in all 29** | A per-mission limit that varies, followed by a fixed 3-minute stage. Note this constancy is *consistent* with the sequential reading and does not by itself establish it — the disassembly above is what does. ## ✅ What it feeds — and what it does not Each frame the updater allocates a 32-byte message (type tag `0xAB03E5BA`, vtable `0x820A8D68`) and posts it to the bus at `[0x828F35DC]`, carrying: ``` +24 = [phase+304] elapsed +28 = [phase+312] countdown B +16 = running ([+316] != 0) +20 = expired ([+320] == 1 && [+308] <= 0.0) ``` `expired` is exactly "countdown A has run out" — the point at which B starts. 🔑 **The script never reads this clock.** `timer_elapsed` and `timer_reset` have **zero call sites in all 28 scripts**; the script only *arms* (127), *starts* (123) and *stops* (124) it. Its only consumer read here is the posted message. ## 🔴 A conflation in `mission-phase-timers.md`, corrected That page says timer 0 "is started by `timer_set(1200, 180)` then `timer_resume`, with a 1200-second limit". Those are **two different clocks armed back to back**: ``` timer_set(1200, 180) -> this object: A = 1200, B = 180, armed timer_resume -> this object: elapsed starts counting set_flag(0) -> STOPWATCH 0 starts (isl-timers.md) ``` The timeline's `kind = 0` reads stopwatch 0, not `[phase+304]`. The two start in the same coroutine one instruction apart, which is why they read almost the same value and the conflation was invisible. **The 1200-second limit belongs to the mission timer; it is not stopwatch 0's limit.** ## 🔴 The message bus: what the "one occurrence" of the tag is worth — nothing The obvious next move was to search for a second site building `0xAB03E5BA` and conclude from its absence that nothing consumes the timer message. **That reasoning is dead**, and the control kills it: | | | |---|---| | instructions building `0xAB03E5BA` (`addis 0xAB03` + `ori 0xE5BA`) | 1 — the producer | | `0xAB03E5BA` as a 4-byte word **anywhere** in the image | **0** | | *any* 4-aligned word beginning `0xAB03` anywhere in the image | **0** | | distinct `0xAB03xxxx` tags built by an `addis`/`ori` pair | 40 | | **of those, built exactly once** | **25 (62.5 %)** | Single-site construction is the **majority** case, so it says nothing about this tag in particular. And because no tag is ever stored as a static word, there is no table of subscribed tags to find either. ### ✅ Two structural reasons it cannot be a compare or a virtual call * **The post is a QUEUE PUSH, not a dispatch.** `sub_82175C20(bus+4, &msg)` is a ring-buffer append — capacity at `+8`, head at `+12`, count at `+16`, element array at `+4`, growing through `sub_8228E208`. It never looks at the message. * **The message class has a ONE-METHOD vtable.** `0x820A8D18`–`0x820A8DA0` is a run of 2-word records `{ sub_82301C20, 0x8210Exxx }`. The timer message's vptr is `0x820A8D68`, so `vtable[0] = sub_82301C20` — a scalar deleting destructor (it stores `0x820A7014` over the vptr and conditionally frees) — and `vtable[-1] = 0x8210E288`, an MSVC RTTI locator (`0,0,0, &typeDescriptor 0x8289D094, &classHierarchy 0x8210E29C`, `numBaseClasses = 3`). Not code: that address is data, and the disassembly does not even reach it (`sylpheed.db` starts at `0x82150000`). **The message carries no handler of its own.** ### 🟡 Where the subscriber actually lives — located, not read The bus object at `[0x828F35DC]` carries a **map at `+8216`**, looked up through `sub_82254A08` from **`sub_823001E8`** — whose only caller is `sub_8230C398`. 🔴 **Correction to my own label from the previous pass.** I called `sub_8230C398` "the per-frame message pump". It is *called* every frame (from `sub_821A6470` at `0x821A654C` and from the mission loop `sub_821AA1B0` at `0x821AA7DC`, both with the frame `dt`), but **it drains nothing**: its whole body is a state machine on the counter at `[0x828E1F8C]`, and across 466 instructions it calls only an allocator (`sub_8230C160`), string building (`sub_8217FA08`), a map lookup (`sub_823001E8`) and a *push* (`sub_8225FEA0`). It is a boot/loading sequencer that posts messages, not the consumer of them. Two further cautions the search turned up: * `sub_82254A08` is a **generic map find** with ~120 call sites image-wide, and `+8216` is a common offset — the pair alone identifies nothing. * The key `sub_823001E8` looks up is a **pointer** (`lwz r4, 13780(r11)` stored and passed by address), **not a message tag**. So `bus+8216` may not be the subscriber registry at all. **So the drain of the queue at `bus+4` is still unlocated**, and with it the answer to whether running out of time ends the mission. ## 🟡 Not settled * **Who subscribes to `0xAB03E5BA`** — see above. Located to the registry at `bus+8216`; the registration path is unread, so whether running out of time ends the mission is still unknown. * What B counting to zero does. Nothing observed acts on it. * Whether `timer_stop`'s 170 sites are all phase teardown, or some are a real mid-mission stop.