e30619630e
FUN_007066c0 is not a path finder. It performs no graph search: it walks the caller's already-chosen destination list and classifies each consecutive pair through FUN_00703730, accumulating flags and the index of the first failing leg. The only graph structure in the subtree is a single-hop adjacency query. A multi-hop node route in a save is n waypoints, one per hop. OrderFleetMove's three failure bits, from the 0x418 literal: 0x008 the destination fleet is on a node route and no intercept could be solved, 0x010 a ship's drive is destroyed, 0x400 the destination point is not one the player may use. The other nine bits are advisory or route-quality complaints the server commits anyway -- the UI's dry run tests the whole word, which is what separates the two groups. Waypoint type 2 is the Liir drive, not a node line. The species-to-drive jump table maps Human and Zuul (the two node races) to 3 and Liir to 2, so lane O's 20+ all-type-3 observations were forced by the table. Nothing is unreachable and nothing needs fixing; exercising type 2 needs a Liir fleet, not a node line. Also: GFlags(+0xdc) is the per-player gate mask; CstR is the gate-projection radius and type 5 is a gate throw at a gateless system, not the Zuul bore; pnd is the node transit's origin id; FtTrans is a second saved copy of the first waypoint's type. Two original defects recorded as shipped (a loop-invariant drive comparison, a loop-invariant node-line ranking term) and one predicted (the leading-destination drop shifting the output arrays). P1/P2/P5 written before the run and checked offline against all 11 saves: 58 waypoints, 46 flight plans, 0 failures. 37 addresses filed; merge generates 912, validated to a scratch path. |
||
|---|---|---|
| .. | ||
| lane-a.json | ||
| lane-b5.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-u.json | ||
| lane-v2.json | ||
| lane-w.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.