sots-re/findings/control-flow/combat-resolver.md

The combat resolver, read from the instruction stream — FUN_007d5af0 / CombatResolver_Run

Lane J, 2026-09-08. Program sots / "Sword of the Stars.exe", ImageBase 0x00400000, all addresses VAs.

Method. The whole body was disassembled byte for byte with objdump -b binary -m i386 -M intel over the raw image (file offsets from the PE section table, call targets from dumps/functions.json, immediates resolved against .rdata). No claim about control flow below comes from the decompiler. The call graph, the RNG inventory, the inlined-draw scan and the EVENT_* inventory were computed by decoding every function in the image from its real instruction boundaries with tools/x86disp.py's length decoder — never a naive byte scan. Callee bodies were read partly by me and partly by delegated sweeps; every such claim is marked.

Closes the #1 ranked gap of findings/control-flow/combat-done-tail.md (lane K), which read the whole 1,587-byte tail and named this function as the boundary it did not cross. It corrects lane K §3 and §2A.1 — see §7.

---

0. Lead: the RNG draw inventory

This is what lane Z's measured per-turn ledger has to meet.

CombatResolver_Run runs once per encounter that produced a real battle — ApplyEncounterResult 0x007d8920 calls it at 0x007d8d24, on the full path only, i.e. when res->+0x4 == 0. It draws nothing itself. There are exactly three draw sites in its subtree, and each is reached through a function whose callerCount is 1 — the resolver. Nothing else in the image can trigger them.

#	site	reached by	condition	cost, in MT words
R1	RNG_NextInt @ 0x007bb69b, inside CombatResolve_NodeCannon 0x007bb530	resolver 0x007d5be2, unconditional, once per battle	res->+0xa8 != +0xac (something was flung by a node cannon) and the candidate destination list is non-empty	1 with p=3/4, 2 with p=3/16, …; mean 4/3. See §3.1
R2	an inlined RNG_NextFloat @ 0x007a84bd, inside CombatResolve_SalvageBackEng 0x007a7f30	resolver 0x007d77c8, unconditional, once per battle — but the callee loops over combatants	one per back-engineering candidate that passes three gates, per combatant with a non-zero salvage-stat slot	exactly 1 each
R3	RNG_NextInt @ 0x00852ec7, inside SpecialProject_PickRandomAvailable 0x00852d30	R2 → SpecialProject_UnlockRandomForPlayer 0x007a0540	one per R2 roll that succeeds (p >= roll), and only when the available-project list is non-empty	≥ 1, mean 2^ceil(log2 n) / n for n available projects

So the resolver's per-battle cost is

words(battle) = [nodeCannonFired] * NextInt(2)
              + SUM over combatants c with a non-zero salvage slot of
                    ( |candidates(c)| + SUM over successful rolls of NextInt(|projects|-1) )

RNG_NextFloat and RNG_Chance are not called anywhere in the closure. The only NextFloat is the inlined one at R2.

0.1 The finding that matters most: an inlined NextFloat that no RNG sweep can see

R2 is not a call. At 0x007a84bd the compiler emitted RNG_NextFloat 0x0047d830 inline, byte for byte:

007a84b5  mov  eax,[ebp-0x3ac]
007a84bb  mov  ecx,[eax]                    ; ecx = ctx->+0x00 = StrategyServer S
007a84bd  mov  esi,[ecx+0x16c]              ; the strategic RNG object
007a84c3  cmp  DWORD PTR [esi+0x9c8],0x0    ; left == 0 ?
007a84ca  jne  0x7a84d4
007a84cc  lea  ecx,[esi+0x4]
007a84cf  call 0x426e00                     ; RNG_Twist(&mt)  -- the LAZY TWIST, not a bare Twist
007a84d4  mov  ecx,[esi+0x9c4]              ; next
007a84da  dec  DWORD PTR [esi+0x9c8]        ; left--
007a84e0  mov  eax,[ecx]
007a84e2  add  ecx,0x4
          ... shr 0xb / and 0xff3a58ad shl 7 / and 0xffffdf8c shl 0xf / shr 0x12 ...
007a8519  fild DWORD PTR [ebp-0x3b8]
007a851f  jns  0x7a8527
007a8521  fadd QWORD PTR ds:0x9e61b8        ; +2^32 unsigned fix-up
007a8527  fmul QWORD PTR ds:0x9e61b0        ; * 1/(2^32-1)

The tempering masks, the 1/(2^32-1) multiplier at 0x009e61b0 and the +2^32 fix-up at 0x009e61b8 are the exact constants addresses.json already records for RNG_NextFloat. The only edge this leaves in a call graph is FUN_007a7f30 → RNG_Twist, which reads as a bare Twist and is not one. That is why lane K's callee sweep concluded "RNG_Twist plus … RNG_NextInt. No NextFloat and no Chance in that subtree."

An image-wide scan at real instruction boundaries for the two tempering immediates finds fourteen game functions with inlined MT draws, besides the four RNG primitives:

004b1f20 (x4)  004f7670       00507ac0 (x12)  005232a0   006ec720   006f65f0
006f7890       0079f7d0       007a7f30        007aa240   007c2fa0 (x4)  007c4140
008cca30       008e6e30 (x2)

Three of those sit in the strategic turn and no RNG accounting in this repo has counted them:

function	in the direct-call closure of	note
FUN_007a7f30	CombatResolver_Run (d1) and OnAllCombatDone_Tail (d3)	R2 above
FUN_004f7670 (84 B)	StrategyServer::ProcessTurn (d4)	not read here — handed to lane Z / the next lane
FUN_007aa240 (944 B)	StrategyServer::ProcessTurn (d4)	not read here

Prediction to falsify. Any per-turn word ledger built by counting calls to RNG_NextFloat / RNG_NextInt / RNG_Chance will be short on turns where combat happens, by the R2 count — and short on every turn by whatever FUN_004f7670 and FUN_007aa240 spend. If lane Z's measured ledger exceeds the call-site prediction, these are where the difference lives.

0.2 Predictions lane Z's ledger can confirm or falsify

1. A battle with no node cannon and no salvage candidates costs ZERO words in the resolver. The resolver has no unconditional draw. A turn with combat is not automatically a turn with extra RNG.
2. The node-cannon site does not consume an integral number of words. RNG_NextInt takes the bound by pointer and is inclusive on [0, n]; here n = min(3, candidates) − 1, which in any galaxy with ≥ 4 valid systems is 2. The rejection mask is 3, so a y & 3 == 3 draw is rejected and redrawn: the site costs 1 word with probability 3/4, 2 with 3/16, 3 with 3/64 … If lane Z sees a node-cannon battle cost exactly one word every time, my reading of the truncation-to-3 is wrong.
3. Every back-engineering candidate costs exactly one word whether it succeeds or fails. NextFloat has no rejection loop. So the R2 count is the number of candidates, not the number of unlocks — an observer counting EVENT_SPRJBACKENG_UNLOCKED will undercount badly.
4. The salvage step is per combatant, not per battle. A three-way battle rolls three candidate lists.
5. A Twist occurs on the 625th word and every 624th thereafter, from any of these three sites; it is not an independent event and must not be double-counted in a ledger that counts both calls and words.

---

1. Where it sits, what its this is, and how big it really is

StrategyServer::OnAllCombatDone_Tail 0x007d92a0, phase 6
  -> StrategyServer::ApplyEncounterResult 0x007d8920      (res->+0x4 == 0 path only)
       0x007d8d12  CombatResolveContext_Ctor(&ctx, S, enc, res)    ; ~0xea0 bytes of stack
       0x007d8d24  CombatResolver_Run(&ctx)                        <-- THIS DOC
       0x007d8d2f  ...                                             ; the publication tail lane K mapped

Exactly one caller, confirmed by Ghidra (callerCount: 1) and by a whole-image direct-call scan.

The size is wrong in Ghidra. The real body is 0x007d5af0 .. 0x007d78c8 = 7,641 bytes, ending in __security_check_cookie / mov esp,ebp / pop ebp / ret (a plain ret — no stack arguments). Ghidra's 7,499 stops at 0x007d783b, mid-instruction, in the middle of the call 0x81dcf0 at 0x007d7837. A dump taken at Ghidra's size loses the last 142 bytes including the victor block's tail and the epilogue. Lane K's brief quoted 7,499; the honest number is 7,641.

The base was checked before anything was trusted. this is not a StrategyServer at all — it is a stack-built context. Four independent reads settle its shape, all against the S frame lane T established:

read	what it proves
CombatResolveContext_Ctor 0x007b8460 stores [ebp+8]→+0x00, [ebp+0xc]→+0x08, [ebp+0x10]→+0x0c	field assignment
the call site pushes res, enc, S in that order	argument identity — ApplyEncounterResult's own [ebp+8] is enc, [ebp+0xc] is res, ecx is S
resolver 0x007d5c03: [ctx+0x08]->+0x2c − ->+0x28 divided by 0x44	ctx+0x08 is the Encounter (lane K's 0x44 member stride)
CombatResolve_NodeCannon 0x007bb58f: [ctx+0x00]->+0x44/+0x48 walked as Systems, and 0x007bb681 [ctx+0x00]->+0x16c used as the RNG	ctx+0x00 is S, not S+4

// CombatResolveContext -- a ~0xea0-byte STACK local, never heap, never serialized
//  +0x000  StrategyServer*        S           (the S frame)
//  +0x004  void*                  new(0x5c) per-player lookup object (ctor FUN_005a13f0)
//  +0x008  Encounter*             enc
//  +0x00c  Game::EncounterResults* res        (0x178)
//  +0x010  void*                  bio-weapon hit list (0 when absent)
//  +0x014  BYTE
//  +0x018  std::string
//  +0x038  0x40 bytes copied wholesale to a stack scratch at 0x007d68b6
//  +0x290 + PlyrIdx*4  int
//  +0x330 + PlyrIdx*4  int
//  +0x430 + PlyrIdx*4  int
//  +0x7b0 + PlyrIdx*0x10  vector<T*>
//  +0x9b0 + PlyrIdx*4     the event object posted for that player
//  +0xa30, +0xa34         written by FUN_007baef0; +0xa34 is the WINNER PlyrIdx, -1 = none
//  +0xa40, +0xa44[race], +0xa5c[race], +0xa62, +0xa63, +0xa64, +0xa68, +0xa6c/+0xa70/+0xa74
//  +0xa80 + PlyrIdx*0x10  an intrusive list head (the salvage "loot pool")
//  +0xc7c + role*8        per-role handle buckets
//  +0xe7c  = FUN_00787690(enc), the resolver's first act
//  +0xe80  a 0x50-stride intercept record array (+0xe84 its end)

---

2. The block map

this = ebx = ctx throughout. "verified" = read from the instruction stream by me in this lane.

#	VA range	what runs	evidence
—	0x007d5af0–0x007d5b1e	prologue: SEH frame 0x0098f945, sub esp,0x484, cookie	verified
A	0x007d5b1e–0x007d5c02	sixteen unconditional mov ecx,ebx; call member calls. In order: ctx->+0xe7c = FUN_00787690(enc); FUN_007c1c80; FUN_00790280; FUN_007c9e00; FUN_007905e0; FUN_007bad00; FUN_0078bba0(&ctx->+0x90); FUN_0079ab90; FUN_007baef0; FUN_0078b6e0; FUN_0079b700; FUN_0078b9a0; FUN_0079b980; FUN_0079c1b0; FUN_007d5a00; FUN_0079be80; CombatResolve_NodeCannon (R1); FUN_0078ba10; FUN_0079c270; FUN_007874b0; FUN_0078f250	verified. Not one conditional jump between them except the inlined std::string destructor at 0x007d5b97, whose arms converge at 0x007d5ba8
B	0x007d5c03–0x007d779d	ONE loop over enc->members, stride 0x44 — index i in [ebp-0x404], edi = i*0x44 computed as ((i<<4)+i)*4, bound (enc->+0x2c − enc->+0x28)/0x44 recomputed at both ends (magic 0x78787879 / sar 5). 7,021 of the 7,641 bytes. Body detailed in §2.1	verified: back-edge jl 0x7d5c30 at 0x007d779d
C	0x007d77a3–0x007d77cd	five more unconditional member calls: FUN_00790990, FUN_0079ae80, FUN_007b0650, FUN_0078bba0(&ctx->+0x190), CombatResolve_SalvageBackEng (R2/R3)	verified
D	0x007d77cd–0x007d78a5	victor block, gated on ctx->+0xa34 != -1 and enc->+0xc != 0 and the member vector non-empty: winner = S->Players[ctx->+0xa34]; loop over members looking for one whose player->+0x5c == 5, and if FUN_0081dcf0(winner, thatPlayer) > 0 bail out; otherwise FUN_00799270(ctx->+0x00, enc->+0xc)	verified
E	0x007d78a6–0x007d78c8	FUN_0079c740(ctx); SEH unlink; __security_check_cookie; plain ret	verified

2.1 Inside the per-member loop

Body order, all verified from the instruction stream:

1. 0x007d5c30–0x007d5ca9 — the two skips. p = *(ServerPlayer**)(enc->members + i*0x44); [ebp-0x408] = p->PlyrIdx(+0x28); FUN_0059bd70(ctx->+0x04, p) → a per-player record in [ebp-0x3f4]; k = FUN_0081dbd0(enc, p) — if k == -1 the whole member is skipped. Then a linear scan of res->+0x98 .. +0x9c (4-byte stride) for p->+0x04; if the id is absent the whole member is skipped. So a combatant present in the Encounter but not in the result's participant list contributes nothing.
2. 0x007d5ca9–0x007d5d76 — four empty std::string locals at [ebp-0x274], [ebp-0x228], [ebp-0x1f0], [ebp-0x20c]: the event key, the summary, the message, and a spare.
3. 0x007d5d76–0x007d6443 — the event-key composition. If FUN_0080b250(enc) → the EVENT_TRADERAIDERS arm. Otherwise, if enc->+0x38 != 0, PickDominantEncounterType(enc->+0x38) (0x004f4c40, already named by lane K) then FUN_004f4970 turns the id into a name, and the code builds the literal "EVENT_" + name + "_FIGHT", "EVENTSUM_" + name, "EVENTMSG_" + token, where the token is "ENTITYVICTORY" / "ENTITYDEFEAT" / "UNRESOLVED" selected by FUN_00785ad0(ctx, encType) returning 2 / 1 / 0. Each key goes through FUN_008c9690 (a string-table lookup that returns a bool) and, on a hit, FUN_008c8eb0 (a _snprintf into a 0x100 buffer with five spare arguments); on a miss it logs at level 2.
4. 0x007d6443–0x007d6790 — outcome selection. A chain of FUN_00787600 / FUN_00787550 tests picks one of EVENT_COMBAT_OBSERVED, EVENT_DEFEAT, EVENT_VICTORY, EVENT_ENGAGED, all converging at 0x007d6784.
5. 0x007d6790–0x007d68cb — outcome write-back. if ([ebp-0x3f4]) record->+0x10 = outcome — one of only eight non-stack stores in the function. Then if (ctx->+0xa34 == PlyrIdx) the winner arm.
6. 0x007d68cb–0x007d6dee — loss accounting. Per player, (ctx->+0x430[p] − ctx->+0x290[p]) − ctx->+0x330[p] as a 64-bit cdq/sub/sbb clamped at 0, plus a dozen more terms, into a twelve-slot, 0x10-stride stack array at [ebp-0x1d4].
7. Inner loop A, 0x007d6df0–0x007d6edd — a fixed 12 iterations ([ebp-0x3ec] = 0xc, dec, jne) over that array: skip any slot whose int64 is 0, else append ", " (0x009e4588) and the number rendered by FUN_008cea10. This builds the human-readable damage summary.
8. Inner loop B, 0x007d6f40–0x007d7034 — over res->+0x18/+0x1c[i].TacReports. res->+0x18 is a vector<Game::CombatPlayerStats> of stride 0x24 (lea edx,[eax+eax*8]; lea ebx,[eax+edx*4]), indexed by the member index i, not by PlyrIdx; the block is skipped when (res->+0x1c − res->+0x18)/0x24 <= i. The inner container is reached through CombatPlayerStats_TacReportCount 0x00456c20 and CombatPlayerStats_TacReportAt 0x00456c40 — see §5. Per entry: gate on entry->+0x48, HandleMap::Resolve(S+0x84, entry->+0x04), then more string work.
9. 0x007d7040–0x007d7208 — a second statistics pass using FUN_00786dd0, FUN_007437e0, FUN_00786ec0, FUN_00785930, FUN_00820680, FUN_00790dc0, FUN_00857440, FUN_0079d040.
10. 0x007d7208–0x007d7280 — the post. ctx->+0x9b0[PlyrIdx] = FUN_00797700(ctx, PlyrIdx, key, summary, message, 1). This is the second real object store in the function and the only one that leaves anything per-player behind.
11. Inner loops C and D, 0x007d72e8–0x007d749d. C (0x007d7340) builds an MSVC _Tree (operator new for the head node, self-pointers at +0x00/+0x04/+0x08, +0x10 = +0x11 = 1) and inserts every element of a 4-byte-stride vector via FUN_004a0950 / FUN_0054dc60; D (0x007d73b0) walks the tree in order with FUN_0080ceb0 (_Tree::_Inc).
12. 0x007d74a3–0x007d7773 — EVENT_STATION_KILLED, posted through the same FUN_00797700, then the string destructors and the loop increment.

2.2 The if that is not a branch, settled the way lane K settled its own

Every one of the six jb/jae pairs around 0x007d5b97, 0x007d5dfa, 0x007d5fc1, 0x007d76eb, 0x007d7715, 0x007d7746 is the inlined std::string destructor: cmp DWORD PTR [ebp-N],0x10; jb over; mov eax,[ebp-M]; push eax; call operator_delete; add esp,4, converging three to five instructions later on the _Myres = 0xf; _Mysize = 0; buf[0] = 0 reset. The capacity word compared against 0x10 is the MSVC short-string-optimisation threshold, and 0x009e100c is the empty-string literal every one of them is constructed from. None of them gates a phase. The identical shape appears eight times in CombatResolve_SalvageBackEng and once inside SpecialProject_PickRandomAvailable.

2.3 Two structural facts worth more than the block list

Only EIGHT non-stack stores exist in the entire 7,641-byte body, found by decoding every instruction and filtering memory writes whose base register is not ebp/esp:

007d5b34  mov DWORD PTR [ebx+0xe7c],eax        ; ctx->+0xe7c = FUN_00787690(enc)
007d684d  mov BYTE  PTR [eax+0x10],cl          ; the per-player record's outcome byte
007d7272  mov DWORD PTR [edi+esi*4+0x9b0],eax  ; ctx->+0x9b0[PlyrIdx] = posted event
007d72fe  mov DWORD PTR [eax],eax              ; _Tree head node
007d7306  mov DWORD PTR [eax+0x4],eax          ;   "
007d730f  mov DWORD PTR [eax+0x8],eax          ;   "
007d7318  mov BYTE  PTR [ecx+0x10],0x1         ;   "
007d7322  mov BYTE  PTR [edx+0x11],0x1         ;   "

And exactly ONE indirect call, at 0x007d7877, inside the _CxxThrowException path for "vector<T> too long". The resolver has no virtual dispatch at all.

Together those say what the function is: it composes and posts per-player combat events and delegates every state mutation to its 70 direct callees. The resolver's own body writes nothing outside its stack context — but its callees write plenty, including the turn-results accumulator. See §4.

---

3. The three RNG sites, read in full

3.1 R1 — CombatResolve_NodeCannon 0x007bb530 (1,991 B), one caller

007bb560  mov eax,[ebx+0xc]                 ; res
007bb563  mov ecx,[eax+0xa8]
007bb56f  cmp ecx,[eax+0xac]
007bb575  je  0x7bbcf8                      ; EMPTY -> return, NO DRAW

Then:

1. reserve a vector<StarSystem*> at [ebp-0xf0] for S->Systems.size() (FUN_00483410);
2. push back every system with sys->+0xc5 == 0 and sys != enc->+0xc (FUN_0059f1a0);
3. FUN_00796590(first, last, count, {enc->+0x1c, enc->+0x20, enc->+0x24, true}) — a sort by distance from the encounter's position, the functor built on the stack with sub esp,0x10;
4. if (count > 3) FUN_00459f70(&cand, 3) — truncate to the three nearest;
5. the draw, and only if the list is non-empty:

007bb679  cmp ecx,eax
007bb67b  je  0x7bb6af                      ; EMPTY -> skip, NO DRAW
007bb67d  sub eax,ecx
007bb67f  mov ecx,[ebx]                     ; ctx->+0x00 = S
007bb681  mov ecx,[ecx+0x16c]               ; the strategic RNG object
007bb687  sar eax,0x2
007bb68a  lea edx,[ebp-0xbc]
007bb690  dec eax                           ; n = count - 1
007bb691  push edx                          ; the bound, BY POINTER
007bb692  add ecx,0x4                       ; &mt
007bb695  mov [ebp-0xbc],eax
007bb69b  call 0x4271c0                     ; RNG_NextInt
007bb6a0  mov ecx,[ebp-0xf0]
007bb6a6  mov edx,[ecx+eax*4]               ; the chosen destination system

RNG_NextInt's loop head is at 0x004271f0 and the exit test is at the bottom (ja 0x4271f0), so every call consumes at least one word, including n == 0. With n == 2 the or/shift cascade gives mask = 3 and y & 3 == 3 is rejected — the geometric tail in §0.

6. per flung handle, HandleMap::Resolve(S+0x84, h) then FUN_007bb420(&out, chosenSystem, obj) groups by (destination, obj->+0x10) into a 0x18-stride vector; the tail posts EVENT_NODECANNON_FLINGS and EVENT_NODECANNON_KILLS, with no further draw.

Every line of this section is instruction-verified.

3.2 R2/R3 — CombatResolve_SalvageBackEng 0x007a7f30, one caller

This function's Ghidra size is a trap and it caught me first. Ghidra says 2,670 bytes, ending at 0x007a89be. The outer loop's back-edge is at 0x007a89ab → 0x007a80ac, and the real body ends at 0x007a89cd. A dump taken at Ghidra's size shows no back-edge and the whole outer loop reads as straight-line code operating on members[0] for one designated player. It is a loop. Corrected here before publication; recorded because it is the same class of error as reading a std::vector destructor as a branch.

L1  0x007a7f79..0x007a7f88   zero 32 slots of 0x10 at [ebp-0x310] -- a per-PlyrIdx 3-float salvage stat
L2  0x007a7fc0..0x007a8071   per Encounter member: player = S->Players[m->+0x28];
                             gate FUN_00787350(player); FUN_0078bcf0(ctx, player, slot) fills the
                             three floats; sticky byte [ebp-0x39d] records "any slot non-zero"
    0x007a807e   if (!sticky) return           <-- WHOLE-FUNCTION ZERO-DRAW EXIT
    0x007a80a6   if (members.empty()) return   <-- WHOLE-FUNCTION ZERO-DRAW EXIT
L3  0x007a80ac..0x007a89ab   OUTER LOOP over members, counter [ebp-0x3c4]
      idx    = members[i]->+0x28
      player = S->Players[idx]                     -> [ebp-0x3bc]
      slot   = [ebp-0x310] + idx*0x10              -> [ebp-0x3a4]
      0x007a8105  if (slot[+4]==0 && slot[+8]==0 && slot[+0xc]==0) continue   <-- no draw
      0x007a810d  candidates = {}     ([ebp-0x3d4]/[ebp-0x3d0]/[ebp-0x3cc])
  L4  0x007a8150..0x007a8406   per member j: append {void* def; float p} candidates
      0x007a844c  if (candidates.empty()) skip                                 <-- no draw
  L5  0x007a8452..0x007a8693   PER CANDIDATE:
        if (def == 0) continue                                                 no draw
        if (!(p > 0.0f)) continue          (fldz/fcomp/test ah,5/jp)           no draw
        if (!FUN_0078f530(player, def, &out)) continue                         no draw
        roll = <INLINED NextFloat>                                             ** ONE WORD **
        success = !(p < roll)              (fcom st(1)/test ah,1 -- equality succeeds)
        log "%s ... SUCCESS|FAILED" with two _ftol2 percentages
        if (success) {
            name = "SPRJ_BACKENG_" + def->+0x20
            SpecialProject_UnlockRandomForPlayer(&out, name, player)           ** >= 1 WORD (R3) **
            if (out.empty()) log level 2
            else post EVENT_SPRJBACKENG_UNLOCKED
        }

FUN_0078f530 (356 B) is a deterministic gate — already-researched, prerequisite, blacklist, then a difficulty-indexed float table at subentry + player->+0x5c*4 + 0x20 compared against 0.0. No RNG in it. (delegated read, spot-checked by me for RNG signatures — clean.)

R3, SpecialProject_PickRandomAvailable 0x00852d30, verified by me:

00852e59  call 0x59ec00                     ; build the candidate project vector
00852e67  cmp ecx,eax
00852e69  jne 0x852eb4
          ...                               ; EMPTY -> return empty string, NO DRAW
00852eb4  sub eax,ecx
00852eb9  sar eax,0x2
00852ebf  dec eax                           ; n = count - 1
00852ec0  push edx                          ; by pointer
00852ec1  add ecx,0x4                       ; &mt
00852ec7  call 0x4271c0                     ; RNG_NextInt
00852ed9  inc BYTE PTR [eax+ebx*1]          ; mark it taken for this player

L1–L5, the two whole-function exits, the inlined draw and R3 are instruction-verified by me. The contents of FUN_0078bcf0 (which fills the stat slot) and the three sources L4 draws candidates from are a delegated read: a per-player intrusive list at ctx+0xa80+PlyrIdx*0x10 supplying up to two entries per node depending on a per-PlyrIdx bit at node+0x14 and a byte at node+0x18, plus — for the one member whose PlyrIdx equals ctx->+0xe7c — a category-filtered registry query FUN_00584e50(&tmp, 0x7fffffff, 0, cat) whose +0x3c == 1 elements all share one probability. That is the part of the draw count I have NOT verified myself, and it is what determines |candidates(c)|.

3.3 Nothing else draws

Computed twice, independently:

• Direct-call closure. BFS from 0x007d5af0 over a call graph built by decoding all 41,089 functions from their real instruction boundaries (122,624 edges): 754 functions reachable. The only members of that set that call an RNG primitive are CombatResolve_NodeCannon (NextInt ×1), SpecialProject_PickRandomAvailable (NextInt ×1) and CombatResolve_SalvageBackEng (Twist ×1, which §0.1 shows is the lazy twist of an inlined NextFloat). RNG_NextFloat, RNG_Chance and RNG_Seed are not reachable at all.
• Inlined-draw scan. Image-wide, at real instruction boundaries, for the tempering immediates: of the 14 game functions carrying them, exactly one — FUN_007a7f30 — is in the closure.

The honest caveat. That is the direct-call closure. The 754 functions contain 199 functions with 352 indirect call sites. Image-wide there are 148 functions that call an RNG primitive and 14 more with inlined draws; none of the other 158 is in the direct-call closure, so reaching one would require an indirect call. I did not resolve the 352. This is a bound, not a proof.

---

4. What it reads and what it writes

Nothing the resolver writes directly reaches saved state. The eight stores of §2.3 all land in the stack context, in a per-player lookup record's outcome byte, or in an operator new tree head that is destroyed before return.

Turn results — and this corrects a claim I had already drafted. A scan of the whole closure for the SETurnResults stride (imul r32,r32,0x11c / add r32,0x11c at real instruction boundaries) returns three sites in two functions. Two are false positives — FUN_007904d0 at 0x00790512 and 0x007905ad are both add ecx,0x11c taking the address of a 0xc-stride vector living at +0x11c/+0x120 (magic 0x2aaaaaab, sar 1), nothing to do with a 0x11c index. I drafted the third as a false positive too, on a bad address conversion. It is not. Read from a correct instruction boundary:

007ba134  mov  ecx,[ebx+0x4]
007ba137  mov  edx,[ebp+0xc]
007ba13a  mov  [ebp-0x1c],ecx
007ba13d  mov  ecx,[esi+0x28]              ; PlyrIdx
007ba140  imul ecx,ecx,0x11c               ; * sizeof(SETurnResults)
007ba146  mov  [ebp-0x18],edx
007ba149  mov  edx,[ebp-0x14]              ; the StrategyServer
007ba14c  lea  eax,[ebp-0x20]              ; a 0x20-byte record, vptr 0x00a23c54
007ba14f  push eax
007ba150  mov  eax,[edx+0x2f4]             ; S->+0x2f4._Myfirst
007ba156  lea  ecx,[ecx+eax*1+0x90]        ; &accumulator[PlyrIdx] + 0x90
007ba164  call 0x7a6630                    ; push_back

So the combat resolver's subtree DOES write the turn-results accumulator, through FUN_007baef0 → FUN_007b9df0 (path 0x007d5af0 → 0x007baef0 → 0x007b9df0, depth 2), on the independent-system-surrenders arm — the same arm that posts EVENT_INDSYS_SURRENDERS_COMBAT and that writes the winner index ctx->+0xa34 at 0x007bb236. The member written is SETurnResults + 0x90, a different member from the +0x24 one lane K found ApplyEncounterResult writing at 0x007d8f9e.

Lane K's §5A listed FUN_007b9df0 as reachable from ProcessTurn phase 1. It has seven direct callers (FUN_007baef0, FUN_007bd490, FUN_007bd520, FUN_007bd930, FUN_007be870, FUN_007d0580, ProcessTurn), and the first of those is inside combat. So lane K's phase-6 turn-results row should read "ApplyEncounterResult 0x007d8f9e writes +0x24, and the resolver's FUN_007baef0 → FUN_007b9df0 writes +0x90 on the surrender arm".

This does not reach the save file — lane K established SETurnResults has no Read/Write pair and appears in no save schema — but it does reach the client, and it is live in memory when the autosave runs.

Method note, recorded because it nearly produced a wrong published finding: my stride scanner reported hit addresses in decimal and I converted two of them by hand, wrongly, then disassembled the wrong addresses and saw garbage that looked like a false positive. What caught it was re-disassembling from a known instruction boundary instead of trusting the arithmetic. The scanner was right; the reader was not.

Events. The closure references 23 distinct EVENT_* / EVENTSUM_* / EVENTMSG_* keys, found by scanning every reachable function for .rdata string immediates at real instruction boundaries. Lane K predicted seven from the string table; the real list is:

key	posted by	depth
EVENT_ + type name, EVENTSUM_ + name, EVENTMSG_ + token	the resolver itself	0
EVENT_TRADERAIDERS, EVENT_COMBAT_OBSERVED, EVENT_DEFEAT, EVENT_VICTORY, EVENT_ENGAGED, EVENT_STATION_KILLED	the resolver itself	0
EVENT_%s, EVENTSUM_%s_ELIMINATED, EVENTMSG_%s_ELIMINATED	FUN_00790990	1
EVENT_NODECANNON_FLINGS, EVENT_NODECANNON_KILLS	CombatResolve_NodeCannon	1
EVENT_SPRJBACKENG_UNLOCKED	CombatResolve_SalvageBackEng	1
EVENT_PLAGUE_OUTBREAK, EVENT_PLAGUE_CURED	FUN_0079c270	1
EVENT_INDSYS_SURRENDERS_COMBAT	FUN_007baef0	1
EVENT_BETRAYAL	FUN_007b0650	1
EVENT_FLEET_INTERCEPT_COMPLETE	FUN_0079ae80	1
EVENT_MINE_REFINE_NEGNEWS	FUN_00888c40	2
EVENT_FLEET_RETREATED_VIA_TELEPORT	FUN_007d5650	2
EVENT_FLEET_INTERCEPT_ABORTED	FUN_0088b980	3

The five in bold are new to the campaign's combat picture. Plague is resolved inside combat — bio-weapon hits are accumulated by FUN_0078ba10 into ctx->+0xa40 / +0xa44[race] / +0xa5c[race] and turned into EVENT_PLAGUE_OUTBREAK or EVENT_PLAGUE_CURED by FUN_0079c270, both at depth 1 of the resolver, on the strategic side of the client/server split. (String identities verified by me from the raw push imm32 operands; the surrounding logic is a delegated read.)

---

5. Two object facts recovered on the way

sizeof(Game::TacReport) = 0x94, enumerated twice. CombatPlayerStats_TacReportAt 0x00456c40 is return (TacReport*)(this->+0x04 + i * 0x94) — imul eax,eax,0x94 — and its sibling CombatPlayerStats_TacReportCount 0x00456c20 is (this->+0x08 − this->+0x04) / 0x94 by the 0xdd67c8a7 add-back / sar 7 reciprocal. Two independent enumerations, neither of them a touch-scan.

Flag against it, per earned-rule 7: objects/streams.json gives Game::TacReport twenty fields — two embedded Game::TacReportEvents (verified 0x20 each) plus eighteen scalars — which with a vptr accounts for at most 0x8c. About 8 bytes are members the serializer never names. Carried, not named. Not resolved here.

Game::CombatPlayerStats+0x04 is its vector<TacReport> — and that is a live instance of lane Q's rule. sizeof(Game::CombatPlayerStats) is already verified at 0x24, and its stream schema writes RPBon, RPBonT, SavBonus, MaintHF before TacReports. An offset-sorted reading of that schema puts the vector at +0x14 and the scalars at +0x04..+0x13. The instruction stream says the opposite: the vector is at +0x04 and the scalars follow it. Offset order is not write order. Aligned against streams.json, never against layouts.md.

---

6. Callee inventory

Read as instructions by me: CombatResolver_Run in full, CombatResolveContext_Ctor, CombatResolve_NodeCannon, CombatResolve_SalvageBackEng (structure, the two whole-function exits, the inlined draw, the roll loop), SpecialProject_UnlockRandomForPlayer, SpecialProject_PickRandomAvailable, RNG_NextInt, CombatPlayerStats_TacReportAt, CombatPlayerStats_TacReportCount, FUN_00456c20/40.

Delegated reads — call shapes and argument orders are mine from the resolver's bytes; contents are the sweep's. Two agents, both instructed to work from the instruction stream, both asked to state what they skimmed. One of the two got the salvage loop structure wrong in the same way I did, from the same truncated Ghidra size; I found it and corrected it in §3.2. Treat everything below as inferred:

addr	size	what the sweep found
0x00787690	211	takes enc; resolves the node and returns node->+0x28, else scans members for flag 0x400. Sets ctx->+0xe7c. No RNG
0x007c1c80	276	walks res->+0xe0/+0xe4 handles, registers distinct participants into res->+0xfc/+0x100 via FUN_007be340
0x00790280	585	builds the credit-eligible handle list at ctx->+0xa6c/+0xa70/+0xa74, consumed by FUN_0078f250
0x007c9e00	2093	the largest: copies encounter position/type into ctx->+0x04, builds a role bitmask, computes interception distances. Skimmed
0x007905e0	429	per-role handle buckets at ctx->+0xc7c + role*8
0x007bad00	475	formats "intercepted by" text into ctx->+0xe80
0x0078bba0	321	zeroes a caller-supplied 0x100 buffer and sums per-role values as doubles
0x0079ab90	119	a string-builder helper
0x007baef0	1300	interception geometry; writes ctx->+0xa34 = player->PlyrIdx (the winner index) and ctx->+0xa38 at 0x007bb236/0x007bb249 — instruction-verified by me; posts EVENT_INDSYS_SURRENDERS_COMBAT; then calls FUN_007b9df0(S, ctx->+0x10, 2, …) at 0x007bb264, which is the turn-results write of §4
0x0078b6e0	702	participant cleanup over enc->+0x78/+0x7c (0x14 stride) through an interface vtable
0x0079b700	96	per res->+0x28/+0x2c handle: FUN_0079b140 + FUN_00793d60
0x0078b9a0	111	links res->+0x38/+0x3c (0x20 stride) records back into live objects
0x0079b980	511	applies four stat dwords from res->+0x48/+0x4c (0x28 stride); checks tech 0x276e
0x0079c1b0	188	attacker/target pairs from res->+0x58/+0x5c (0xc stride)
0x007d5a00	225	a six-stage sub-dispatcher: builds a 0x18-byte temp from ctx->+0x00/+0x08/+0x0c and runs FUN_0079bb90, FUN_0079bcd0, FUN_007b0320, FUN_00790790, FUN_007d5650, FUN_007a7cd0. The real per-phase combat pipeline is under here. Its whole subtree is inside the 754-function closure and draws no RNG
0x0079be80	799	order/colonization statistics. Skimmed
0x0078ba10	386	bio-weapon hit accumulation into ctx->+0xa40/+0xa44/+0xa5c
0x0079c270	1219	posts EVENT_PLAGUE_OUTBREAK / EVENT_PLAGUE_CURED
0x007874b0	158	scales ctx->+0xa64 by a count; FUN_00925220 here is _ftol2, not RNG
0x0078f250	295	distributes per-participant credit using ctx->+0xa68
0x00790990	1040	24 elimination-condition bits → EVENTSUM_%s_ELIMINATED / EVENTMSG_%s_ELIMINATED / EVENT_%s
0x0079ae80	680	ctx->+0xe80/+0xe84 (0x50 stride) → EVENT_FLEET_INTERCEPT_COMPLETE
0x007b0650	2591	ally-fire detection → EVENT_BETRAYAL. Skimmed. Its [player+0x16c] bit test is a ServerPlayer field, not S+0x16c's RNG
0x00799270	64	find-and-erase on a container at S->+0x314
0x0079c740	2270	the last call; per-member prize/message text pulled from the node's string table, not from a literal. Skimmed. No RNG
0x0081dcf0	280	the relationship/eligibility comparator used by the victor block and by the salvage step

---

7. Corrections

7.1 To lane K §3 — the resolver's subtree does draw NextFloat

combat-done-tail.md §3 says of phase 6's subtree: "No NextFloat and no Chance in that subtree to depth 4." The Chance half is right and now stronger (none in the full closure, not just depth 4). The NextFloat half is wrong, and wrong for a reason worth keeping: the draw is inlined (§0.1), so it is invisible to any call-graph sweep. Lane K's own note that the edge was FUN_007a7f30 → RNG_Twist is the tell — a game function has no business calling Twist directly, and it isn't.

Lane K's conclusion — that the tail advances the generator before the autosave and that nothing models it — is unaffected and, if anything, understated.

7.2 To lane K §2A.1 — the resolver's size and the shape of the call

ApplyEncounterResult "builds a ~0xea0-byte combat report and runs the real resolver FUN_007d5af0 (7499 B)". Two refinements: the object is a context, not a report (the Game::CombatReport that reaches the std::list at S+0x1fc is a different local, constructed at 0x007d8d2f after the resolver returns); and the resolver is 7,641 bytes, not 7,499 — Ghidra's figure ends mid-instruction.

7.3 To my own first reading

I initially read CombatResolve_SalvageBackEng as straight-line code that resolved back-engineering for one designated player, because I dumped it at Ghidra's size and the outer back-edge at 0x007a89ab fell outside the dump. It is a loop over combatants. Recorded rather than quietly fixed: the failure mode is "a truncated range makes a loop look like a sequence", which is the same family as "an inlined destructor looks like a branch" and deserves its own line in the rules.

---

8. Gap list, ranked

Tier 1 — closes an RNG question the campaign is actively measuring

target	size	why
FUN_004f7670 (84 B) and FUN_007aa240 (944 B)	84 + 944	inlined MT draws reachable from StrategyServer::ProcessTurn at depth 4. Nothing in the repo counts them. Eighty-four bytes is the cheapest RNG fact left in the campaign, and lane Z's ledger cannot be explained without both
FUN_0078bcf0 (641 B) — fills the per-player salvage stat slot	641	it decides whether a combatant rolls at all, and its three floats become the probabilities R2 tests. Without it |candidates(c)| stays unquantified
FUN_00584e50 + the ctx+0xa80 loot-pool list	?	the other half of |candidates(c)| — the actual number of R2 draws per combatant
FUN_007bb420 (268 B) + FUN_00459f70/FUN_00796590	268 + 131 + 374	confirms the truncate-to-3 that fixes R1's bound at 2. One sort and one resize; if the truncation is not unconditional, prediction 2 in §0.2 changes

Tier 2 — the actual combat mathematics, still unread

target	size	why
FUN_007d5a00's six callees — FUN_0079bb90, FUN_0079bcd0, FUN_007b0320, FUN_00790790, FUN_007d5650, FUN_007a7cd0	?	this is where the per-phase combat pipeline lives. The resolver is a reporting layer; the sub-dispatcher is the machine. FUN_007d5650 already carries EVENT_FLEET_RETREATED_VIA_TELEPORT. Draw-free by the closure scan, which makes them tractable and deterministic — the best reimplementation target in the whole combat path
FUN_007c9e00	2093	interception geometry; the largest single unread block reachable in one hop
FUN_0079c740	2270	prize/reward resolution, the last thing the resolver does
FUN_007b0650	2591	EVENT_BETRAYAL — a diplomacy rule fired from inside combat, nowhere in findings/subsystems/
FUN_0079c270 + FUN_0078ba10	1219 + 386	plague is decided inside combat. EVENT_PLAGUE_OUTBREAK / EVENT_PLAGUE_CURED at depth 1, and ServerSystem::ProcessPlague is separately known to be draw-free — so this may be the only place plague starts
FUN_00790990	1040	24 elimination conditions and the %s_ELIMINATED event family

Tier 3 — object work this lane opened but did not close

• The ~8 unnamed bytes of Game::TacReport (§5). sizeof is settled at 0x94; the field list is not.
• Game::EncounterResults beyond +0x04, +0x05, +0x06, +0x07, +0x18/+0x1c, +0x28/+0x2c, +0x38/+0x3c, +0x48/+0x4c, +0x58/+0x5c, +0x98/+0x9c, +0xa8/+0xac, +0xe0/+0xe4, +0xfc/+0x100, +0x10c, +0x120, +0x150. That is 16 of 0x178 bytes named; streams.json lists 28 anonymous fields, so the offsets above must be matched to them in write order, not sorted.
• CombatResolveContext — I named 20 offsets; the object is 0xea0 bytes.

Tier 4 — the honest blind spot

352 indirect call sites in 199 of the 754 reachable functions. The RNG inventory in §0 is a bound derived from the direct-call closure plus an image-wide inlined-draw scan. It is strong — 158 of the image's 162 RNG-touching functions are outside the closure entirely — but it is not a proof, and if lane Z measures a combat-turn cost that §0's formula cannot produce, this is the first place to look.

---

9. What this lane did not read

Stated plainly, in the shape lane K used, because it is the most useful section.

• The per-member loop's arithmetic. I read its control flow, its bounds, its calls, its strings and every memory write. I did not decode the ~1,400 bytes of float and int64 accounting between 0x007d68cb and 0x007d6dee that produce the twelve summary counters — only that there are twelve, that they are int64, and that the terms come from ctx->+0x290, +0x330, +0x430 indexed by PlyrIdx.
• FUN_007d5a00's six callees — the real combat pipeline. Confirmed inside the closure and confirmed draw-free; nothing more.
• Twenty-six callee bodies were characterised by delegated sweeps (§6). Their call shapes and argument orders are instruction-verified from the resolver's own bytes; their contents are not mine. Two of them were explicitly skimmed by the sweep and are marked.
• FUN_0078bcf0 and FUN_00584e50, which together determine the R2 draw count. This is the single biggest hole in the deliverable that matters most, and it is Tier 1 above.
• The 352 indirect call sites.
• Whether res->+0x98/+0x9c's elements are the schema's carr<int> — the stride and use are verified, the type identification is a labelled hypothesis and is filed as one in ghidra/addresses.d/lane-j.json.

---

10. Meeting lane Z's measured ledger

findings/control-flow/tail-rng-ledger.md landed while this lane was reading. The two results are complementary and they agree where they touch, but the honest headline is that they do not yet overlap.

10.1 Where we agree

Lane Z, §6: "all three RNG entry points in its 750-node direct-call closure load [reg+0x16c]." I found three sites in a 754-node closure, all on S+0x16c, computed from an independently built call graph. Two lanes, two graphs, same three sites and the same generator. (The 750/754 difference is four functions and is not worth chasing; neither of us claims the closure is the whole truth — see §3.3 and lane Z's §7.)

10.2 Where we do not yet overlap, and that is the point

Lane Z, §7: "The combat resolver has still never run under an instrument. Every encounter this workload produced had the no-battle flag set, so ApplyEncounterResult was a no-op every time. Its measured 0 words says nothing whatever about combat's RNG cost."

That is exactly right, and it is the shape of the joint result: lane Z has a measurement with no mechanism for the 18–20 words it sees, and I have a mechanism with no measurement for the words I predict. Neither half is worth much alone.

• My §0 formula is untested. It predicts the cost of a battle, and no battle has occurred under an instrument. It is a hypothesis in exactly lane K's sense.
• Lane Z's 18–20 words are all inside ProcessTurn, and nothing models any of them. §0.1 offers a candidate mechanism for part of that gap that is not in anyone's model: FUN_004f7670 (84 B) and FUN_007aa240 (944 B) both contain inlined MT draws and both are in ProcessTurn's direct-call closure at depth 4. Any accounting built by scanning for calls to the four RNG primitives has never counted them. Reading those two is the cheapest way to convert part of lane Z's 18–20 into an explained number, and FUN_004f7670 is 84 bytes.

10.3 The workload that would test §0

Lane Z's instrument is already in place; what is missing is a save that reaches the resolver. From this lane's reading, the gates are known exactly, so the workload can be specified rather than guessed:

1. A real battle. ApplyEncounterResult is a whole-function no-op while res->+0x4 != 0, which lane Z measured as set on every encounter of ref-turn2. The resolver runs only on res->+0x4 == 0.
2. Then the resolver's own gates. A battle alone predicts zero words: R1 needs res->+0xa8 != +0xac (a node cannon actually flung something) and R2/R3 need at least one combatant with a non-zero salvage-stat slot and at least one candidate surviving FUN_0078f530.

So the first measurable prediction is the cheap one: a plain fleet battle with no node cannon and no salvageable wrecks should move the generator by exactly the same 18–20 words as a peaceful turn. If lane Z measures a battle turn costing more than a peaceful one without a node cannon or a back-engineering candidate present, §0 is wrong and the missing draw is somewhere in FUN_007d5a00's six unread callees (§8, tier 2) — reached, per §3.3, only through one of the 352 indirect call sites I did not resolve.

10.4 A correction to lane Z's §7

Lane Z carries the resolver as 7499 B, taken from lane K's brief. It is 7,641 bytes — 0x007d5af0..0x007d78c8. Ghidra's 7,499 ends mid-instruction (§1). Nothing in lane Z's result depends on the number; recorded so it stops propagating.

10.5 What lane Z settles for me

Two of its results remove uncertainty from this doc rather than adding it:

• The generator does not move outside the turn pipeline (§1.1: entry position equals the previous post-turn autosave position, exactly, three times). So any words §0 predicts will show up in the bracket and cannot be lost to a renderer or a UI poll.
• OnAllCombatDone_Tail runs on every End Turn (§3), which was lane K's labelled hypothesis. That makes the resolver's reachability per turn a settled fact and reduces §0 to a question purely about its gates.