# Object id allocation: one allocator, sixteen node counters, and why the client's ids are free Lane ID, 2026-09-08. **Host work only — no VM run was needed and none was taken.** VM140 was held and released untouched; its `SavedGames` set is byte-identical to the oracle (§8). Closes row 2 of `turn-command-replay.md` §4 — "the client's id allocator" — which lane RB flagged as "a watchpoint, not a week of reading". It turned out to be neither: it is arithmetic on ids the corpus already held, confirmed against the instruction stream and cross-checked on twenty saves. Predictions were written before any of the work below and are quoted verbatim where they were falsified (§3.2). Consumes: `combat-retreat-pipeline.md` (B5, `IDMap::AllocateID`), `turn-command-replay.md` (RB), `ai-order-emission.md` (AI4), `struct-recovery.md`. --- ## 0. Lead: there is no second allocator RB's gap list says "**two id spaces**, and the small one is part of the wire protocol". There are two id *spaces*, and RB is right that a reimplementation which allocates on apply gets every AI-created id wrong. But there is **one allocator, one implementation, and one formula** — B5's `IDMap::AllocateID` 0x008b8ae0, `id = (counter << 4) | (node & 0xF)`. What differs is **which node's counter** is used, and that is a property of the *sim object*, not of the code: > `Game::StrategyServer` and `Game::StrategyClient` are **both** `Game::StrategySim` > (RTTI: `StrategyClient` bases `[StrategyClient, StrategySim]` at offset 0; `StrategyServer` bases > `[StrategyServer, IStreamable, StrategySim]` with vftables at offset 0 **and** offset 4 — that is > the "two bases 4 bytes apart" of earned rule 1, and the +4 one is the `StrategySim` subobject). > > `StrategySim` owns an `IDMap` at **`StrategySim + 0x80`** — i.e. `StrategyServer + 0x84`, > `StrategyClient + 0x80`. Every sim allocates from **its own** map, on **its own** local node > index at `IDMap + 0x18`. So the object-creation code is base-class code that runs unchanged on both sides. The whole client-allocates/server-honours protocol is one branch in `StrategySim::CreateDesign` 0x008827e0: ``` 008828b3 mov eax,[ebp+0x10] ; explicitId, the third argument 008828b6 test eax,eax 008828b8 jne 0x8828c5 ; non-zero -> use the id the command carried 008828ba lea ecx,[edi+0x80] ; else: this sim's own IDMap 008828c0 call 0x8b8b70 ; IDMap::AllocateOnLocalNode 008828c5 ... call 0x8b9350 ; IDMap::Insert(map, design+0xa0, id) ``` The client calls it with `explicitId = 0` and mints; the server calls it with the id off the wire and mints nothing. ## 1. The arithmetic, which is the whole result B5's formula, run backwards on RB's numbers: | id | | counter | node | |---:|---|---:|---:| | **18** design | *client-allocated* | **1** | **2** | | **34** fleet | *client-allocated* | **2** | **2** | | 1712 | from the master counter | 107 | 0 | | 1728 | ship in the input save | 108 | 0 | | 1776 | | 111 | 0 | | 272, 288 systems; 32, 496, 512 players | | 17, 18, 2, 31, 32 | 0 | Every id that comes out of a save carries node nibble **0**. Both client-allocated ids carry node nibble **2**, with counters **1** and **2** — the first two ids that node ever issued. ### 1.1 On twenty saves, four games, three distinct client nodes Nibble histogram over `FltID`/`DesID`/`ShipID`/`SysID`/`PlayerID` in the whole corpus (`verify/results/saves/*.sav`, read with `verify/save-reader/save_reader.py --dump`): | save | ids | nibbles | the non-zero ones | |---|---:|---|---| | `turn1-state` | 98 | `{0: 98}` | — | | `turn2-state` | 102 | `{0: 101, 2: 1}` | 18 | | `turn3-state` | 104 | `{0: 102, 2: 2}` | 18, 34 | | `cb-turn2to3-autosave` | 104 | `{0: 102, 2: 2}` | 18, 34 | | `human-turn3-noderoute` | 90 | `{0: 86, 2: 4}` | 18, 34, 50, 66 | | `human-turn8-traderoutes` | 151 | `{0: 141, 2: 10}` | 18 … 242 | | `human-turn15-spyprogram` | 295 | `{0: 252, **1: 1**, 2: 42}` | **17**, 18 … 818 | | `zuul-turn15-orders` | 150 | `{0: 139, 2: 10, **3: 1**}` | 18 … 162, **19** | | `zuul-turn17-orders2` | 167 | `{0: 151, 2: 14, **3: 2**}` | 18 … 226, **19, 35** | | `zuul-turn23-fleet23` | 222 | `{0: 198, 2: 22, 3: 2}` | … | Three facts fall straight out, and none of them needed a hook. 1. **Nodes 1, 2 and 3 all occur.** "The client" is not singular. Each node's counters run **1, 2, 3, …** contiguously from the start of the game — node 2's first id is `18` in *every* save in the corpus, node 3's first is `19`, node 1's first is `17`. 2. **The partition is absolute.** ~2,600 ids across four games, zero collisions between spaces. That is the entire purpose of the nibble and of `IDMap::Initialize`'s `numNodes <= 0x10` cap. 3. **Node = owning player's index + 1.** Every node-nibble object belongs to exactly one player: | save | id | owner `PID` | that player's `PlyrIdx` | node | |---|---:|---:|---:|---:| | `turn3-state` | design 18, fleet 34 | 32 | 1 | 2 | | `human-turn15` | design 17 | 16 | 0 | 1 | | `human-turn15` | design 18 | 32 | 1 | 2 | | `zuul-turn17` | designs 18, 34, … | 32 | 1 | 2 | | `zuul-turn17` | designs 19, 35 | 496 | 2 | 3 | ## 2. The node index, read from the instruction stream `StrategyServer::InitGameForPlayer` 0x007c8d90 builds the CreateGame message for one player's client. Four instructions do the assignment: ``` 007c8ddf mov esi,[eax+0x28] ; player->PlyrIdx ... 007c8ecb cmp esi,0xffffffff 007c8ece je 0x7c8ed3 007c8ed0 inc esi ; localNode = PlyrIdx + 1 007c8ed1 jmp 0x7c8ed5 007c8ed3 xor esi,esi ; PlyrIdx == -1 -> localNode = 0 007c8ed5 ... [ebx+0x90] - [ebx+0x8c], /20 ; numNodes = the server map's node count 007c8ef2 mov [ebp-0x134],ecx ; msg->numNodes 007c8ef8 push esi 007c8ef9 lea ecx,[ebx+0x84] ; the SERVER's IDMap 007c8eff mov [ebp-0x130],esi ; msg->localNode 007c8f05 call 0x8b8b80 ; IDMap::GetNodeCounter(server map, localNode) 007c8f1a mov [ebp-0x12c],eax ; msg->startId ``` The message is `{numNodes, localNode = PlyrIdx + 1, startId = the server's counter for that node}`. The client receives it as **case 0** of `StrategyClient::RaiseEvent` 0x00783ee0 (jump table 0x00784200, handler 0x00783f05) and `StrategySim::OnCreateGame` 0x00776f20 calls `IDMap::Initialize` on its own map at `+0x80` with exactly those three words. So `PlyrIdx + 1` is not an inference from the saves any more. The saves and the disassembly agree, which is the only reason either is worth reporting. ## 3. Seeding: what a save carries, and what it cannot `IDMap::Initialize(numNodes, localNode, startId)` 0x008b9ad0, `ret 0xc`: * refuses `numNodes > 0x10` — **sixteen nodes, and that is the four-bit nibble**; * refuses `localNode` outside `[0, numNodes)`; * resizes the 0x14-stride node vector, then **zeroes every node's counter** (0x008b9b20); * writes `startId` into **`nodes[localNode].counter` alone** (0x008b9b38); * stores `localNode` at `this->+0x18` (0x008b9b3d). ### 3.1 The save's `NM*` tags are now named `StrategyServer::Read` 0x007d27a0 reads three ints and passes them straight in: ``` NMSz -> numNodes NMLc -> localNode NMnx -> startId ``` That **confirms and extends B5's labelled hypothesis** ("the counter is almost certainly NMnx"). It is NMnx, it is the counter *for node NMLc only*, and the two tags beside it are the node count and the local node index. Corpus: | save | NMSz | NMLc | NMnx | ModCount | Frame | |---|---:|---:|---:|---:|---:| | `turn1-state` | 16 | 0 | 106 | 0 | 1 | | `turn2-state` | 16 | 0 | 109 | 12 | 2 | | `turn3-state` | 16 | 0 | **111** | 24 | 3 | `StrategyServer::LoadGame` 0x007dd530 sets a fresh game up with `Initialize(16, 0, 0)`, which is where `NMSz 16` / `NMLc 0` come from and why the host's ids all carry nibble 0. **A correction to `turn-command-replay.md` §4 row 2** (earned rule 11). It says the server "issued 1712 and 1776 the same turn", and that design 18 and fleet 34 are "objects that do not exist in the input save". Neither is quite right on the canonical pair: * 1712 is counter **107**, issued during turn **1→2** (NMnx 106 → 109 covers counters 107, 108, 109 = ids 1712, 1728, 1744). 1776 is counter 111, issued during turn **2→3** (109 → 111). * **Design 18 is present in `turn2-state.sav`.** It is in the master `DesignIDs` list and in player 32's block, and it was allocated during turn 1→2. Only **fleet 34** is new on the canonical pair. So the turn-2→3 build order names an id the input save already holds, and a faithful replay of that pair has to mint exactly **one** id, not two. That is a materially smaller gap than the row claims. Everything else in the row stands, including the load-bearing part: allocate on apply and you get `1792` where the original has `34`. ### 3.2 A falsified prediction, and the open item it leaves Prediction ID-P3 said, in full: > If NMLc = 0 holds, then the node-2 counter that issued 18 and 34 is NOT in the save, is NOT > restored by Initialize (which zeroes it), and therefore **restarts at zero on every load**. NMLc is 0, and the first two clauses are read directly out of the code: no save carries a per-node array, `Initialize` zeroes the rest, `IDMap::Insert` 0x008b9350 **never touches a counter** (read to the end: it logs a duplicate, refuses id 0, bounds-checks `id & 0xF`, writes the id into `obj->+4` and inserts into `nodes[n]`'s map — no counter write), and `InitGameForPlayer` seeds a client from `GetNodeCounter`, which therefore returns 0 for every client node in a freshly loaded game. **The third clause is falsified by a save already in the corpus.** `cb-turn2to3-autosave.sav` is a fresh process that *loaded* `turn2-state.sav` (which contains design 18 = node 2, counter 1) and pressed End Turn. The fleet it created is **34 — counter 2**, not 18. If the client's counter had started at 0 the fleet would have been 18, colliding with a design that already exists. Two explanations survive, and this lane cannot separate them without a hook: * **(A)** something restores the server's node-2 counter to 1 during the load, and the client is seeded with it. I read `Initialize`, `Insert`, `AllocateID`, `FindNode`, `GetNodeCounter` and `InitGameForPlayer` and found no such write. Absence in six functions is not absence. * **(B)** the counter really does start at 0 and the client made **one earlier allocation that turn which never reached the save** — a local design object, a task, an order — taking counter 1, so the fleet got counter 2. This fits the read code exactly and requires nothing unread. **The probe is one hook and it is cheap** (earned rule 18, and rule 20 — instrument the *entry*): detour `IDMap::AllocateID` 0x008b8ae0 and log `(this, nodeIndex, resulting id, return address)` for one `turn2-state → turn3-state` End Turn. (A) predicts the client's very first allocation that turn returns 34; (B) predicts it returns 18 from a site that is not the fleet creator. **A count alone cannot separate them** — that is exactly the shape rule 20 exists for. Whichever it is, the consequence for a reimplementation is the same and is stated in §5. ### 3.3 The collision hazard, stated as a hypothesis If (B) is right, then a client's counter is a pure function of **allocation order within the process** and a save/load loses it. Load a save in which a client has already allocated *n* objects and let it allocate again, and it re-issues `(1<<4)|k` — an id the map already holds. `IDMap::Insert` logs `IDMap: Object already exists with id %d.` and **inserts anyway** (0x008b9367: the log is followed by fall-through, not a return). That would be an original defect, not ours. Labelled hypothesis. The same one-hook probe settles it, and `human-turn15-spyprogram.sav` — node 2 at counter 51 — is the workload that would make it loud. ## 4. Layout, for the record ``` IDMap (StrategySim + 0x80) +0x08 / +0x0c / +0x10 vector, STRIDE 0x14 (allocator +0x10, rule 5) +0x18 int localNodeIndex NodeEntry 0x14 bytes +0x00 .. +0x0f std::map id -> object, for THIS node +0x10 int counter pre-incremented; 0 is never issued ``` `AllocateID(node)`: 0 if `node == -1` or the node does not exist; else `++nodes[node].counter` (pre-increment, and on wrap to 0 it logs and increments again, so `INVALID_NETWORK_ID` is never handed out); `id = (counter << 4) | (node & 0xF)`, with an overflow log if the counter no longer round-trips. ## 5. What a faithful replay has to do 1. **A per-node counter array, not one counter.** Sixteen of them. 2. **Node 0 for the sim that owns the board; node `PlyrIdx + 1` for each player's client.** 3. **Restore only node `NMLc`'s counter from `NMnx`.** There is nothing else in the save to restore, and inventing a per-node array in the save format would diverge from the original. 4. **Mint the id at command *emission*, not at apply**, and carry it in the command — the applier must honour a non-zero id and mint only on zero (`StrategySim::CreateDesign`'s branch). 5. **Do not model the client counter as a function of the save.** It is a function of allocation order in the process, and until §3.2 is settled a replay of the canonical pair should take the client's ids from the capture rather than derive them. For the canonical pair specifically, (4) plus "design 18 is already in the input save" means the replay needs exactly one minted id, `34`, and it is the *second* thing node 2 allocates that turn. ## 6. What this lane did NOT do 1. **No hook, no VM run, no new instrument.** Every number is from the checked-in corpus and the image. That is also the limit: §3.2 is open precisely because nothing ran. 2. **The second `LoadTechFile` loop and the message *send* were not read.** I read `InitGameForPlayer` up to the point where the message is filled, and `OnCreateGame` from the point where it is received; the transport between them is assumed, not read. It is a single process, so nothing observable depends on it — but it is not read. 3. **`FUN_008a9030`'s counter at `+0x23c` is a different mechanism** (a Mars scene object with its own `IDMap` at `+0x68`, `Initialize(1, 0, 0)`, and a separate per-object counter gated on `obj->+0x20 & 0xF == 2`). It is not game state and it is not this. Recorded so the next lane that greps for `& 0xF` does not chase it. 4. **Multiplayer is untested.** Every save in the corpus is `NMLc 0`. A real client machine would save with `NMLc = k` and its own counter, and *the server's* copy of that counter is the thing §3.2 is about. Nothing here has been exercised across two machines. 5. **`ShipID` allocation was not traced to its site.** Ships in the corpus are all node 0, so they are minted server-side; I did not read which function does it. ## 7. Reproducing every number here ```sh cd ~/sots-re uv run python3 verify/save-reader/save_reader.py --dump verify/results/saves/turn3-state.sav \ | grep -E 'NMSz|NMLc|NMnx' # nibble histogram: see the one-screen script in section 1.1's method note below uv run python3 dumps/b6dis.py 0x008b9ad0 # IDMap::Initialize uv run python3 dumps/b6dis.py 0x007c8d90 # InitGameForPlayer; the +1 is at 0x007c8ed0 ``` The histogram is `re.match(r'\s*@[0-9a-f]+\s+(\S+)\s+int\??\s+(-?\d+)', line)` over the dump, keeping the five id tags and counting `value & 15`. No tool was added for it — it is four lines and a tool would only hide what it does. ## 8. VM140 released The game was never launched and nothing was written. `C:\SOTS\SavedGames` verified over SSH before release — **8 files**, and the three oracle hashes match: | file | bytes | sha256[0:16] | | |---|---:|---|---| | `(Autosave).sav` | 67,219 | `978041acd168b56e` | ✅ oracle | | `(Autosave EndTurn).sav` | 66,732 | `bb4fd9ac89f41e3b` | ✅ oracle | | `(Autosave Backup).sav` | 67,219 | `978041acd168b56e` | ✅ oracle | | `MyGameverify1rtD.sav` | 66,732 | `bb4fd9ac89f41e3b` | | | `MyGameverify1rtE.sav` | 66,732 | `bb4fd9ac89f41e3b` | | | `MyGameverify1verify1.sav` | 66,732 | `bb4fd9ac89f41e3b` | | | `ref-turn2.sav` | 66,739 | `ab4ac2d7e2977260` | | | `zuul-turn5.sav` | 59,131 | `48559ab5b719b332` | | Note for the next VM lane: a filename with parentheses cannot be hashed through `ssh … 'certutil -hashfile "…(Autosave).sav"'` — `cmd.exe` eats the parens and returns "Check the spelling", which reads exactly like a missing file. Use `powershell -NoProfile -c "(Get-FileHash -LiteralPath '…' -Algorithm SHA256).Hash"`. My first attempt reported the three oracle files as absent and they were never absent. **Please mark VM140 free.**