ae47971316
Joins the emission side (lanes AI1-AI3) to the counting side (A2, W2). Three results. The cost of applying a command is a property of its list, and the boundary is sharp: lists 1-16 each advance ModCount once per element, lists 17-27 never do. Four of the six prologue gates bump, one is free, and the sixth has no applier anywhere in the application path -- its cost is unknown, not zero. The batch applies the twenty-seven lists in a fixed order that is neither list nor offset order, with the six gates split across three separate per-player loops at three different points, and four of the sixteen bumps inlined into the batch rather than living in a handler, which is why a call-graph sweep under-counts them. Lane W2's four unnamed handler EIPs are named, and so are its two inlined ones, and the ten measured command bumps then decompose with zero residual. Four of the ten are the research-rate gate, one per submitted block, and one of those four is the human's. Two are list 14, on a turn that moved exactly one fleet -- which confirms lane AI2's P1 (an AI fleet order deposits two fleet-task elements where the interface deposits one) from the counter side, at no VM cost. The reference game is not what the record says. ref-turn2.sav IS turn2-state.sav; there are THREE AI players, not one, and the two dormant ones do run -- all three set a research rate and picked a research target on turn 1; and the four monster-faction players submit no command block at all, which is the first direct evidence that they have no client rather than an empty task list. Prediction committed for turn1-state: the same 12, out of a different set of commands -- 4 rate gates, 3 research targets, and three orders from the one AI with an empire, which are predicted to be a new design, a build order and a system-rates command, with NO fleet order on turn 1. The trap multiset it predicts contains two EIPs W2 has never seen and omits three it did, so it is cheap to falsify: one save swap on W2's unchanged watchpoint module. Also: phase 2 of the AI's turn is Hiver-only (a fifth cross-check on the species reading, and the reason one prologue gate has never been observed set), phases 29-33 are dead because the submit latches the client before it builds the send buffer, and cl_SetResearchTarget is AI-only surface with exactly one caller. 14 addresses in ghidra/addresses.d/lane-ai4.json; validated to a scratch path, 1,138 -> 1,152, no duplicate names.
116 lines
12 KiB
JSON
116 lines
12 KiB
JSON
{
|
|
"entries": [
|
|
{
|
|
"name": "TurnCommandApply_ResearchRate",
|
|
"addr": "0x00821a80",
|
|
"convention": "__thiscall",
|
|
"prototype": "void (StrategySim* this, int playerId, float* rate) -- the server-side applier for TurnCommands prologue gate @0x0c. Bumps ModCount as its SECOND instruction, `inc [ecx+4]` @0x00821a84. Called from ApplyTurnCommandBatch+0x616 inside the per-player gate loop that opens at 0x0088fdb0 with esi = block+0x38: the gate tested is `[esi-0x2c]` (= block+0x0c) and the arguments are `[esi-0x34]` (= block+0x04, playerId) and `&[esi-0x30]` (= block+0x08, the rate). THIS NAMES ONE OF LANE W2'S FOUR UNRESOLVED HANDLER EIPs, and it is the one that fires most: because StrategyClient::BuildTurnCommands sets that gate UNCONDITIONALLY, it costs one ModCount bump per SUBMITTED BLOCK regardless of what the player did -- 4 of the 10 command bumps on the reference turn",
|
|
"status": "verified",
|
|
"source": "findings/subsystems/ai-order-emission.md §1.1 (lane AI4 2026-09-08, instruction stream); the EIP was measured live by lane W2, watchpoints-modcount-status.md §2 row 2-5"
|
|
},
|
|
{
|
|
"name": "TurnCommandApply_SystemRates",
|
|
"addr": "0x0086c3e0",
|
|
"convention": "__thiscall",
|
|
"prototype": "void (StrategySim* this, int playerId, void* element) -- the applier for TurnCommands list 5 (system rates: `{i32 systemId, StarSystem::OutputRates}`). Bumps ModCount @0x0086c3e6. Called from ApplyTurnCommandBatch+0x32d, in the block that walks member +0xa0. Names lane W2's trap EIP 0x0086c3e9. On the reference turn exactly one element was applied, from the one AI player with an empire",
|
|
"status": "verified",
|
|
"source": "findings/subsystems/ai-order-emission.md §1 (lane AI4 2026-09-08); EIP measured by lane W2"
|
|
},
|
|
{
|
|
"name": "TurnCommandApply_BuildOrder",
|
|
"addr": "0x00849460",
|
|
"convention": "__thiscall",
|
|
"prototype": "void (StrategySim* this, int playerId, void* element) -- the applier for TurnCommands list 3 (build orders: `{i32 ordinal, i32 designId, i32 systemId, i32}`). Bumps ModCount @0x0084946b. Called from ApplyTurnCommandBatch+0x6ef, walking member +0x88. Names lane W2's trap EIP 0x0084946e. This is the site that puts the AI's destroyer into the build queue on the reference pair -- the order lane B6 could not find in the pre-turn save because it does not exist yet when that file is written",
|
|
"status": "verified",
|
|
"source": "findings/subsystems/ai-order-emission.md §1 (lane AI4 2026-09-08); EIP measured by lane W2"
|
|
},
|
|
{
|
|
"name": "TurnCommandApply_List10",
|
|
"addr": "0x0088bed0",
|
|
"convention": "__thiscall",
|
|
"prototype": "void (StrategySim* this, int playerId, void* element, int flag=1) -- the applier for TurnCommands list 10 (`{i32, i32, counted i32}`). Bumps ModCount @0x0088befe. Called from ApplyTurnCommandBatch+0x8ff with a literal 1 pushed as a fourth argument, walking member +0xdc. Names lane W2's trap EIP 0x0088bf01, which W2 recorded only as 'unresolved (near DestroyFleet)'. WHAT list 10 IS is still open: AI3 has AssignFleetsAndIssueOrders reaching lists 14, 8 and 10 together, the element is an id pair plus an id vector, and the turn that produced it also produced a brand-new fleet -- but that is a shape argument, not a name",
|
|
"status": "verified",
|
|
"source": "findings/subsystems/ai-order-emission.md §1 (lane AI4 2026-09-08); EIP measured by lane W2"
|
|
},
|
|
{
|
|
"name": "TurnCommandApply_List14_Inline",
|
|
"addr": "0x0089046c",
|
|
"convention": "site",
|
|
"prototype": "`inc [ecx+4]` with ecx = the StrategySim -- the ModCount bump for TurnCommands list 14, INLINED into ApplyTurnCommandBatch at +0xabc rather than living in a handler. The containing block starts at 0x00890445 with `add ecx,0x10c` (list 14's member offset) and fetches playerId as `[eax-0x108]`. Lane W2 measured this site firing EXACTLY TWICE on a turn in which exactly ONE fleet was moved (one list-8 bump), which CONFIRMS lane AI2's prediction P1: the AI's fleet-order bridge calls ClientOrder_FleetTask twice, mode 0 then mode 1, and the adder's (fleetId, mode) key makes those two distinct elements, where the UI emits only mode 0",
|
|
"status": "verified",
|
|
"source": "findings/subsystems/ai-order-emission.md §0.3 (lane AI4 2026-09-08); EIP measured by lane W2 as 0x0089046f, x2"
|
|
},
|
|
{
|
|
"name": "TurnCommandApply_ResearchTarget_Inline",
|
|
"addr": "0x0088fe0a",
|
|
"convention": "site",
|
|
"prototype": "`inc [ebx+4]` -- the ModCount bump for TurnCommands prologue gate @0x14 (research target), inlined into ApplyTurnCommandBatch at +0x45a. Guarded by `cmp BYTE [edi-0x24],0` @0x0088fdfa with edi = block+0x38, i.e. the gate at block+0x14; playerId from `[eax-0x34]` and the tech id from `[ecx-0x28]` (= block+0x10). NEVER FIRED in either of lane W2's measured windows, which is consistent with the saves: no player's ResTNm changes on turn 2->3 or 3->4. Lane AI4 predicts it fires exactly THREE times on turn 1->2, once for each of the three AI players, all of which go ResTNm '' -> a named tech",
|
|
"status": "mapped",
|
|
"source": "findings/subsystems/ai-order-emission.md §1.1 and §3 P2 (lane AI4 2026-09-08, instruction stream; not yet observed live)"
|
|
},
|
|
{
|
|
"name": "TurnCommandApply_ResearchBoost_Inline",
|
|
"addr": "0x008907bc",
|
|
"convention": "site",
|
|
"prototype": "`inc [ebx+4]` -- the ModCount bump for TurnCommands prologue gate @0x20 (research boost), inlined into ApplyTurnCommandBatch at +0xe0c. This is a SEPARATE per-player gate loop that runs AFTER all twenty-seven command lists, opening at 0x008907a6 with esi = block+0x20; the payload `[esi-0x8]`/`[esi-0x4]` is block+0x18 (savings spent) and block+0x1c (a fraction), handed to 0x00820560. So the six prologue gates are applied in THREE separate loops at three different points in the batch, not together",
|
|
"status": "mapped",
|
|
"source": "findings/subsystems/ai-order-emission.md §1.1 (lane AI4 2026-09-08, instruction stream)"
|
|
},
|
|
{
|
|
"name": "TurnCommandApply_Group4Gate",
|
|
"addr": "0x00821b90",
|
|
"convention": "__thiscall",
|
|
"prototype": "void (StrategySim* this, int playerId, void* payload) -- the applier for TurnCommands prologue gate @0x2c (a bool at +0x24 and an int at +0x28). Bumps ModCount @0x00821b93. Called from the LAST loop in ApplyTurnCommandBatch, at +0xe6d, with esi = block+0x24 and the gate tested as `[esi+0x8]`. Never observed set in any save; its AI producer is Process Turn phase 14 (0x006c3510 -> client order method 0x00763910), so an AI turn on which phase 14's own gate opens costs one bump nothing in the corpus has ever paid",
|
|
"status": "mapped",
|
|
"source": "findings/subsystems/ai-order-emission.md §1.1 (lane AI4 2026-09-08, instruction stream)"
|
|
},
|
|
{
|
|
"name": "TurnCommandApply_NewDesign",
|
|
"addr": "0x00882910",
|
|
"convention": "__thiscall",
|
|
"prototype": "void (StrategySim* this, int playerId, void* element) -- the applier for TurnCommands list 1 (`StreamableHelper<ShipDesignDef>` frame plus an int). Bumps ModCount @0x0088291a. Called from ApplyTurnCommandBatch+0x652, walking member +0x70. Lane AI4 predicts this is the site that registers the AI's new hull on the reference pair's turn 1 (`Des[18 \"Honor Lance\"]`, NumDes 5 -> 6) and that it fires exactly once there; if it does NOT fire, an AI design is not a command at all and is carried some other way -- which is the single most useful falsifier in that prediction",
|
|
"status": "mapped",
|
|
"source": "findings/subsystems/ai-order-emission.md §1 and §3 P2 falsifier (d) (lane AI4 2026-09-08)"
|
|
},
|
|
{
|
|
"name": "TurnCommandApply_Colonize_Inline",
|
|
"addr": "0x008905c8",
|
|
"convention": "site",
|
|
"prototype": "`inc [ebx+4]` -- the ModCount bump for TurnCommands list 7 (colonize: `{i32 shipId, i32}`), inlined into ApplyTurnCommandBatch at +0xc18. The containing block opens at 0x008905b5 with `lea ecx,[eax+0xb8]`, which is why an `add reg,imm` scan for the list member offsets misses it; the per-element mutator is 0x00849280 and does not itself bump. Recorded because the AI's colonize orders are the one command family whose producer is currently mis-attributed: Process Turn phase 32 reaches the colonize order method but runs AFTER cl_EndTurn has latched the client, so its orders are refused (see AIProcessTurn_SubmitLatch)",
|
|
"status": "mapped",
|
|
"source": "findings/subsystems/ai-order-emission.md §1 (lane AI4 2026-09-08, instruction stream)"
|
|
},
|
|
{
|
|
"name": "AIProcessTurn_SubmitLatch",
|
|
"addr": "0x00783c59",
|
|
"convention": "site",
|
|
"prototype": "`mov BYTE [esi+0x15c],1` inside StrategyClient::EndTurn -- the turn-ended latch. It is set BEFORE the calls to BuildTurnCommands (0x00783cd7) and SendEndTurn (0x00783d0d), and EVERY client order method opens with `if (this->+0x15c) return false`. Since cl_EndTurn is Process Turn phase 28 of 34, PHASES 29-33 ARE DEAD: they run, they call their order methods, and every one is refused -- including phase 32 (0x006af790 -> 0x00769640), which would otherwise issue a colonize order. A reimplementation that ports the phase list literally is one command per AI per turn over on ModCount",
|
|
"status": "verified",
|
|
"source": "findings/subsystems/ai-order-emission.md §3 P4 (lane AI4 2026-09-08, instruction stream)"
|
|
},
|
|
{
|
|
"name": "AIProcessTurn_Phase2_HiverGate",
|
|
"addr": "0x006c5813",
|
|
"convention": "site",
|
|
"prototype": "`cmp DWORD PTR [eax+0x5c],1; jne 0x006c5a28` at the head of Process Turn phase 2 (0x006c57e0), where eax = client->+0x150 (the ClientPlayer) and +0x5c is Species. SPECIES 1 IS HIVER, so the whole of phase 2 -- a cl_Chance draw at 0x006c592a and the client order method 0x00762ca0 at 0x006c59b6, which sets TurnCommands prologue gate @0x3c -- is skipped for every other species. Two consequences: gate @0x3c is AI-only AND Hiver-only, which is why no save has ever carried it (the corpus has no Hiver player); and this is a FIFTH independent cross-check on lane AI2's reading of player+0x5c as Species",
|
|
"status": "verified",
|
|
"source": "findings/subsystems/ai-order-emission.md §1.1 and §3 P3 (lane AI4 2026-09-08, instruction stream)"
|
|
},
|
|
{
|
|
"name": "cl_SetResearchTarget",
|
|
"addr": "0x00578f60",
|
|
"convention": "__cdecl",
|
|
"prototype": "The `cl_*` facade entry for the research-target order, reaching client order method 0x00763110 at 0x00578faa. It has EXACTLY ONE caller in the whole image: 0x006caf70, which is AI Process Turn phase 18. So this entry point is AI-only surface, exactly as cl_EndTurn is -- extending lane AI1's P4 list, which was drawn from the order methods rather than the facade. The UI reaches the same order methods directly from 0x005d20a0 / 0x005d2140, so the *method* is shared and the *facade entry* is not",
|
|
"status": "verified",
|
|
"source": "findings/subsystems/ai-order-emission.md §3 P5 (lane AI4 2026-09-08, image-wide rel32 caller scan)"
|
|
},
|
|
{
|
|
"name": "AIProcessTurn_Phase18_Research",
|
|
"addr": "0x006caf70",
|
|
"convention": "__thiscall",
|
|
"prototype": "AI Process Turn phase 18 (called at 0x006cfc82). The only caller of cl_SetResearchTarget 0x00578f60, and it also calls cl_SetResearchRate. This is where an AI player's research target is chosen, and therefore where the ResTNm change lane C3 attributes to 'the AI's own orders, generated during the same turn' originates. Its internal gate -- when the AI does and does not pick a target -- was NOT read; the corpus says it opens on turn 1 for all three AI players and stays shut on turns 2 and 3",
|
|
"status": "mapped",
|
|
"source": "findings/subsystems/ai-order-emission.md §3 P5 (lane AI4 2026-09-08)"
|
|
}
|
|
]
|
|
}
|