From 3a3513b5cc726d6376760a59a34eeaba9ffc8058 Mon Sep 17 00:00:00 2001 From: alex Date: Tue, 8 Sep 2026 09:49:17 -0400 Subject: [PATCH] Z: S+0x8 is 12-44 per turn, not 12-14 -- it scales with the game state The second save's numbers were not in the first draft's table. Correcting my own correction: on a turn-19 Zuul game the counter moves 16, 21 and 44 times between ProcessTurn entries, against 12-14 on an early two-colony game. So it is not a driver-invocation counter and not a constant either. --- findings/control-flow/combat-done-tail.md | 14 ++++---- findings/control-flow/tail-rng-ledger.md | 44 +++++++++++++---------- 2 files changed, 33 insertions(+), 25 deletions(-) diff --git a/findings/control-flow/combat-done-tail.md b/findings/control-flow/combat-done-tail.md index 8c93c98..224a173 100644 --- a/findings/control-flow/combat-done-tail.md +++ b/findings/control-flow/combat-done-tail.md @@ -623,12 +623,14 @@ same word. Given §6's inference that the message is delivered every turn, `S+0x per turn while `S+0xc` (`ModCount`) advances once. They are not in lockstep, and a reimplementation must not treat `S+0x8` as a turn number. It reads as a **server-phase / driver-invocation counter**. -> **MEASURED by lane Z, 2026-09-08 — "at least twice" is the right phrasing; it is 12 to 14.** Read live at -> hook entry over eight turns on two saves, `S+0x8` advances **12–14 times per turn**, of which the two -> drivers account for 2. Both drivers were hooked, so the other 10–12 increments come from a writer nobody -> has identified, and they happen between the post-turn autosave and the next `ProcessTurn`. `S+0xc` -> advances by exactly 1 per turn over the same records. The conclusion here is strengthened: `S+0x8` is not -> a turn number and is not even a driver-invocation counter. `findings/control-flow/tail-rng-ledger.md` §5. +> **MEASURED by lane Z, 2026-09-08 — "at least twice" is the right phrasing, and the real number is 12 to +> 44.** Read live at hook entry over eight turns on two saves, `S+0x8` advances **12–14 times per turn** on +> an early two-colony game and **16–44** on a turn-19 Zuul one, of which the two drivers account for 2. +> Both drivers were hooked, so the rest come from a writer nobody has identified, between the post-turn +> autosave and the next `ProcessTurn`. `S+0xc` advances by exactly 1 per turn over the same records. The +> conclusion here is strengthened: `S+0x8` is not a turn number, it is not a driver-invocation counter, and +> it is not even a constant per turn — it scales with the size of the game state. +> `findings/control-flow/tail-rng-ledger.md` §5. ### 7.2 Turn results and turn events are not where lane T said diff --git a/findings/control-flow/tail-rng-ledger.md b/findings/control-flow/tail-rng-ledger.md index c51f356..aaee3a2 100644 --- a/findings/control-flow/tail-rng-ledger.md +++ b/findings/control-flow/tail-rng-ledger.md @@ -166,16 +166,16 @@ RNG cost attached*, which none of the eleven corpus saves has. > **§6, labelled hypothesis:** "I did not prove that `SNMAllCombatDone` is delivered on turns with no > combat." -**The handler runs on every End Turn.** Four out of four, `OnAllCombatDone_Tail` recorded exactly one call -per End Turn, at depth 0, between the two autosaves, with the post-turn autosave following it. The -determinism-note inference was right. +**The handler runs on every End Turn.** Eight out of eight, across two unrelated saves, +`OnAllCombatDone_Tail` recorded exactly one call per End Turn, at depth 0, between the two autosaves, with +the post-turn autosave following it. The determinism-note inference was right. The stronger claim — that it runs with an *empty encounter vector* — is **not** settled by this workload and -must not be reported as though it were. On `ref-turn2` the encounter vector is **empty at `ProcessTurn` -entry and holds exactly one encounter by the time the tail runs** on every one of the four turns: detection -(`ProcessTurn` phase 31) creates it, and the tail's phase 7 clears it. So what is proved is "the tail runs -on a turn with **no battle**", not "on a turn with no encounter at all". See §8 for what closing the -remaining gap needs. +must not be reported as though it were. On **both** saves the encounter vector is **empty at `ProcessTurn` +entry and holds exactly one encounter by the time the tail runs**, on every one of the eight turns: +detection (`ProcessTurn` phase 31) creates it, and the tail's phase 7 clears it. So what is proved is "the +tail runs on a turn with **no battle**", not "on a turn with no encounter at all". See §8 for what closing +the remaining gap needs. Two things fall out of the same records and are worth more than the phrasing: @@ -194,18 +194,24 @@ Two things fall out of the same records and are worth more than the phrasing: Lane K wrote that `S+0x8` "advances **at least twice** per turn". That is correct and this lane's prediction that it advances **exactly** twice is **wrong**. Observed `S+0x8` at hook entry: -| turn | `ProcessTurn` entry | tail entry | tail's callees | next turn's `ProcessTurn` entry | -|---|---|---|---|---| -| 3 | 22 | 23 | 24 | 34 | -| 4 | 34 | 35 | 36 | 48 | -| 5 | 48 | 49 | 50 | 60 | -| 6 | 60 | 61 | 62 | — | +| save | turn | `ProcessTurn` entry | tail entry | tail's callees | increments to the next turn | +|---|---|---|---|---|---| +| ref-turn2 | 3 | 22 | 23 | 24 | **12** | +| ref-turn2 | 4 | 34 | 35 | 36 | **14** | +| ref-turn2 | 5 | 48 | 49 | 50 | **12** | +| ref-turn2 | 6 | 60 | 61 | 62 | — | +| zuul-noderoute | 17 | 253 | 254 | 255 | **16** | +| zuul-noderoute | 18 | 269 | 270 | 271 | **21** | +| zuul-noderoute | 19 | 290 | 291 | 292 | **44** | +| zuul-noderoute | 20 | 334 | 335 | 336 | — | -The two drivers account for 2 of the **12 to 14** increments per turn. Ten to twelve more happen between the -post-turn autosave and the next `ProcessTurn`, from a writer this lane did not identify (both drivers are -hooked, so it is neither of them). Lane K's operational conclusion is strengthened, not weakened: **`S+0x8` -must never be treated as a turn number.** `S+0xc` (`ModCount`) reads 3, 4, 5, 6 across the same four turns -and is the turn counter. +The two drivers account for **2 of 12 to 44** increments per turn, and the count is not a constant — it +grows with the size of the game state (12–14 on a turn-3 two-colony empire, 16–44 on a turn-19 Zuul one). +The rest happen between the post-turn autosave and the next `ProcessTurn`, from a writer this lane did not +identify (both drivers are hooked, so it is neither of them). Lane K's operational conclusion is +strengthened, not weakened: **`S+0x8` must never be treated as a turn number** — and it is not a +driver-invocation counter either. `S+0xc` (`ModCount`) reads 3, 4, 5, 6 and 17, 18, 19, 20 over the same +records and is the turn counter. ## 6. Corrections to `combat-done-tail.md` §3 and §6.1