975c19a57d
The client-side allocator is not a second allocator. StrategyServer and StrategyClient are both StrategySim, which owns an IDMap at +0x80; each sim allocates from its own map on its own local node index. StrategyServer::InitGameForPlayer sets that index to PlyrIdx + 1 (node 0 is the server's) and seeds the client from the server's counter for that node. IDMap::Initialize names the save's NM* tags: NMSz nodes, NMLc local node, NMnx that node's counter -- confirming B5's labelled hypothesis and adding the other two. Cross-checked on 20 saves: nodes 1, 2 and 3 all occur, counters run from 1 per node, and 2,600 ids collide zero times. Corrects turn-command-replay.md row 2: design 18 IS in turn2-state.sav, so the canonical pair needs one minted id, not two. One open item, with the one-hook probe named: a reloaded save produced fleet 34 rather than 18, and nothing I read restores a client counter. techId is the 0-based index into the master tech list sorted by _stricmp -- read out of MasterTechTree's ctor, which sorts a copy of the parse-order list and then writes def->techId = i. 282 is XNC_TrnsHum2, which lane L4 had already observed live and nobody connected. tools/techid_table.py derives all 293 offline and refuses to print unless the four observed points agree. |
||
|---|---|---|
| .. | ||
| lane-a.json | ||
| lane-a2.json | ||
| lane-ai1.json | ||
| lane-ai2.json | ||
| lane-ai3.json | ||
| lane-ai4.json | ||
| lane-b5.json | ||
| lane-b6.json | ||
| lane-c3.json | ||
| lane-d2.json | ||
| lane-e1.json | ||
| lane-e3.json | ||
| lane-ev.json | ||
| lane-g2.json | ||
| lane-g3.json | ||
| lane-h.json | ||
| lane-i.json | ||
| lane-id.json | ||
| lane-j.json | ||
| lane-k.json | ||
| lane-l1.json | ||
| lane-l3.json | ||
| lane-l4.json | ||
| lane-l5.json | ||
| lane-n.json | ||
| lane-o.json | ||
| lane-p2.json | ||
| lane-par.json | ||
| lane-pl.json | ||
| lane-q.json | ||
| lane-rb.json | ||
| lane-sv.json | ||
| lane-t.json | ||
| lane-t2.json | ||
| lane-u.json | ||
| lane-v2.json | ||
| lane-w.json | ||
| lane-w2.json | ||
| lane-w3.json | ||
| lane-z.json | ||
| README.md | ||
Per-lane address fragments
addresses.json is a single shared file. When several lanes run concurrently they edit the
same lines, and three times on 2026-09-08 one lane's git add swept another's in-flight
entries into the wrong commit. Nothing was lost, but authorship and atomicity were.
A lane may instead drop its own file here:
{ "entries": [ { "name": "...", "addr": "0x...", "convention": "...",
"prototype": "...", "status": "verified", "source": "findings/..." } ] }
Name it after the lane (lane-d.json). tools/gen_addresses.py merges every fragment in
sorted order after addresses.json. A duplicate name across files is a hard error, not
last-wins — two lanes disagreeing about an address is exactly the thing we must not paper over.
The integrator folds fragments back into addresses.json once the lane's work is merged.