d4f9404960
findings/subsystems/population-growth.md -- ServerSystem::GrowCivilianPops 0x00754220 read byte for byte, its whole chain, and Ship::RepairCost 0x00815180. The headline is a correction to the brief's premise. The pass is NOT gated on imperial carrying capacity. The whole system's civilian delta is clamped to 20,000,000 -- POPTYPE[1]+0x08, an int64 literal in the executable -- and on both reference pairs that clamp decides the value: the uncapped delta is 7.5x it and the capacity headroom 25x it. The imperial capacity is pinned at exactly Size x 1e8 from the corpus alone, by two independent behaviours of one colony across three turns, with no data files. Two boundary corrections, both of the rule-17 shape. GrowCivilianPops is a loop over group types whose back edge lies outside every decompiler `if`, so it reads as straight-line code if you stop at the first `ret`; its real end is 0x00754b59. MaxPopGeneric ends at 0x0074a6cd, so the 0x0074a6d0 that lanes N and E1 both cite for the capacity-surplus pair is a different function. A table correction with teeth: InitPopTypeTable never writes the group ceiling at +0x28/+0x2c. The CRT static initialiser at 0x009abe20 does, to INT64_MAX, and nothing else touches it -- so the clamp that reads it is always a no-op. A reader who opens only the obvious initialiser sees zero there and would cap every carrying capacity in the game at nothing. Lane N's whole table is otherwise reproduced independently from the six-register fxch rotation. output-turn-path.md: out[6] is NOT the ship-repair demand. 0x007460b0 sums 0x0081f8c0, which gates on the design's carried-population bit and computes GroupIncome over the ship's own Population -- so it is the income of population carried in slaver and colony hulls, a slot the engine already had under a name nobody had connected to it. Corrected in place, with lane-c3.json's three unread stubs superseded by lane-g3.json's read entries. Ship::RepairCost is unexercised on the corpus and that is a measurement, not an absence (rule 20): the independent colony keeps a ten-ship fleet in orbit over Koa'Vo on both reference pairs and its Sav closes exactly with the demand taken as zero, which it could not do if any hull had a cost. Engine side: sots-engine wip/growth ed6602e -- reference pair 78 -> 81 closed, 0 regressed; pair 2 36 -> 39 closed, 0 regressed. |
||
|---|---|---|
| .. | ||
| lane-a.json | ||
| lane-a2.json | ||
| lane-ai1.json | ||
| lane-ai2.json | ||
| lane-ai3.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-j.json | ||
| lane-k.json | ||
| lane-n.json | ||
| lane-o.json | ||
| lane-p2.json | ||
| lane-q.json | ||
| lane-t.json | ||
| lane-t2.json | ||
| lane-u.json | ||
| lane-v2.json | ||
| lane-w.json | ||
| lane-w2.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.