sots-re/findings/subsystems/multiplayer-combat.md

# Multiplayer combat, run on the real game: two humans, one battle, lockstep

- **Type:** subsystem (live verification)
- **Status:** **verified** — a player-versus-player battle was fought inside a two-player LAN game
  with no GameSpy service of any kind, and the whole run was captured outside the guest
- **Confidence:** high on everything below; every claim is a screenshot, a socket table, or a packet
- **Owner / date:** lane L2 · 2026-09-08 · guest **VM141** (`sots-re-win10-b`)
- **Predictions, committed before the run:** `sots-engine/docs/L2-predictions.md`
- **Builds on:** `multiplayer-tier0-verified.md` (lane W2) and `multiplayer-gamespy.md` (lane G2)

---

## 0. The headline

**Combat multiplayer works, and it needs no GameSpy either.** Two human players in one LAN-mode
game fought a battle at a contested colony: both got the encounter query, both chose *Fight
Manually*, both loaded the tactical combat screen, and both ran the same battle off **one shared
lockstep clock**. Over the whole session — lobby, twelve strategic turns, the encounter query and
the battle — the capture on the host side of the guest's NIC shows **zero** packets to UDP 27900,
UDP 27901, TCP 28910, TCP 28900, TCP 6667 or TCP 6500, and **zero** DNS lookups for any
`*.gamespy.com` name.

W2 closed Tier 0 with the words "the most likely place for the direct path to still be broken".
It is not broken. **The multiplayer revival is complete end to end: create, join, launch, play,
and fight.**

**And the one prediction that failed is the most interesting result.** `CombatHostPort` **3370 is
never bound — not at lobby time, not at turn time, and not during the battle.** G2 read the default
out of `Game_LoadNetworkConfig` (`0x005a0610`) correctly, and W2 correctly reported it unbound at
lobby time and inferred "it must be opened later, when a combat starts". That inference is wrong on
this arm: the combat ran to a shared clock over the **already-open strategy connection**, with the
socket table unchanged from the moment the lobby opened. See §4 — this matters for anyone writing
port-forwarding instructions, and it corrects the community advice.

---

## 1. What was run

One Windows guest (VM141), GOG 1.8.1, two instances of the shipped executable, `hooks=off` — **the
instrument was removed** (method rule 19). The guest was cloned from VM140 with lane W3's
`hooks=trace` shim config in place; that was replaced with `hooks=off` before the game was launched
(§8).

- **Instance A**, pid 2256 — host. Launched by the `SOTS` scheduled task with no arguments.
- **Instance B**, pid 6620 — joiner. `"C:\SOTS\Sword of the Stars.exe" /concurrent /join 127.0.0.1:3369`
  via the `SOTSB` scheduled task. **W2's P5 reconfirmed on a second guest**: two instances, two
  windows, two main loops.

Game: *Host Multi-Player* → **Custom** + **LAN**, 28 stars, **Distance 5 ly** (the minimum), 2
players, **Initial Colonies 10**, **Random Encounters 100%**, Strategic Turn Length *Unlimited*,
Combat Turn Length *240 s*. Slot 2 was switched from *Computer* to **Open** before B joined — a
clone of VM140 comes up with slot 2 set to AI, and a joiner cannot take an AI slot.

Three instruments, all outside the game process:

1. `tcpdump -i tap141i0` on **spicy**, rotating into `/root/l2cap/` — the host side of the guest's
   tap device, outside the guest entirely.
2. `Get-NetUDPEndpoint` / `Get-NetTCPConnection` filtered to the two SOTS pids, polled over SSH from
   a separate process (`C:\SOTS\l2\socks.ps1`).
3. `qm monitor 141 screendump` for the screen, via `tools/vmshot.py` — reads the QEMU framebuffer,
   nothing inside the guest.

**Blind spot, stated up front, same as W2's:** both instances talk over 127.0.0.1, so the game's own
3369 traffic never reaches the tap. §5 turns that into a *control* rather than a hole.

## 2. Provoking a battle — what it actually took

This is worth recording because it cost most of the lane and the next lane should not re-derive it.

**Random encounters at 100% do not fire on a static empire.** Eight strategic turns were played with
Random Encounters at maximum, 20 colonies between the two players, and **no encounter at all**.
The reason is visible in the system banner: `DE 00 CR 00 DN 00`. With *Initial Colonies 10* and
*Initial Technologies 0*, **neither player starts with a single ship** — so "Manage Fleets", "Move"
and "Special" are greyed out on every system, and there is nothing for an encounter to happen to.

So a battle needs, in order:

1. **Build warships.** *Build* → Destroyer → `Armor` → *Add To Queue*. At 16 M treasury and 17 k
   industrial output a batch of four destroyers completes in **2 turns**.
2. **Order a fleet somewhere hostile.** Select the fleet row in *Fleets at <system>*, press
   *Move*, then click the destination **star** (not its banner, and not where the tooltip appears).
3. Because both players were Human, node travel applies: targeting a system off the node network
   raises *"Alpha Fleet cannot reach <X> using nodes. Do you want to plot a sublight course?"*
   Accepting gives a **sublight** course — here 28 turns to Nu Ophiuchi at Speed 4.00 / 0.2 sublight.
4. **The sublight leg is what produced the battle**, and faster than the nominal ETA: on turn 12 the
   fleet drifted into **Avalon**, a colony belonging to the *other* player, and the encounter fired.

**Three UI traps, each of which cost a run here:**

- **The starmap needs real mouse motion.** `SetCursorPos` alone does not move the game's cursor —
  the move-mode arrow and the destination tooltip never update. The driver must follow the warp with
  an actual `mouse_event(MOUSEEVENTF_MOVE, …)` relative jiggle. W2's `ui.ps1` has no such jiggle,
  which is why its recipe covers only fixed-position buttons and never the map.
- **The banner is not the star.** System banners sit up and to the left of their star with a short
  leader stem, and a neighbouring banner will cover the star underneath it. Clicking the banner does
  nothing; clicking where the hover tooltip is drawn does nothing. Zoom in (mouse wheel) until the
  banners separate, then click the star itself.
- **A modal move-warning dialog silently stops the turn loop.** An unattended "end turn on both
  instances" loop ran four full cycles against a *"plot a sublight course?"* dialog and the turn
  number never moved. Any automated turn driver must screenshot and check before clicking.

`tools/vmshot.py --one 141` plus a PIL crop is the whole read-back loop; the game's own text is
legible at 3–7× upscale and that is how every reading below was taken.

## 3. The battle — P2, P5, and the lockstep result

**P5 — the encounter query reaches both players — confirmed.** Both instances raised the C1
*Encounter at Avalon* screen (`SNMDoEncounterQuery`), each showing **both** player cards: the
attacker `re(2)` with *Ships: 4 / DE: 4 / 4 DE Armor*, and the defender `re` with *No ships
available* (host's own view) / *No ships detected* (attacker's view). The action strip offered the
full `ENCACTION_*` set — *Fight Manually*, auto-resolve, fight-if, auto-resolve-peacefully, and on
the attacker's side the two surrender variants. **Both players independently chose *Fight
Manually*** and pressed *Done*.

**The combat launched.** Both instances showed the C2 loading screen — the `CL_*` versus backdrop
titled *Encounter at Avalon*, `re(2)` **VS** `re` — and then the C3 tactical HUD:

| | Instance A (pid 2256, host, defender) | Instance B (pid 6620, joiner, attacker) |
|---|---|---|
| Title | `Avalon` | `Avalon` |
| Own forces | none — planet only | `DE Armor (1)` selected, weapons panel, 3 gun groups |
| Player list | `re(2)` in the enemy colour | `re(2)` |
| Fleet Commands strip | present | present |
| Combat clock | running | running |

**P2 — combat resolves in lockstep — confirmed, and the clock is the proof.** The two instances
were sampled alternately, and the combat clock is a *single shared value*, not two independent
countdowns:

| Wall clock | Instance sampled | Combat clock |
|---|---|---|
| 18:00:39 | B (attacker) | 3:51 |
| 18:01:48 | A (defender) | 3:31 |
| 18:04:33 | B (attacker) | 2:42 |
| 18:05:59 | B (attacker) | 2:18 |

Those four readings lie on one line at **≈ 0.29 × real time** regardless of which instance is
sampled — 240 s of combat took roughly 14 minutes of wall clock on a guest running two copies of a
D3D9 game through DXVK on llvmpipe. A defender sampled at 18:01:48 sitting exactly on the line drawn
by attacker samples at 18:00:39 and 18:04:33 is what lockstep looks like from the outside: **one
simulation, two views, neither free-running.** No `@SYNC ERROR` appeared on either instance.

**The sim does not stall when a window loses focus.** Instance B advanced 69 s of combat time during
a stretch when instance A held the foreground continuously. This matters for anyone automating the
lab: the two-instance configuration is not a focus-ping-pong problem.

**The battle ended cleanly and both players came out of it together.** The 240 s combat timer ran to
`0:00` and the round expired (`CombatExpiredFunctor`); both instances raised the C4 end dialog
**"Round draw."** — the `COMBAT_*` string for an expired round. Dismissing it returned **both**
instances to the strategy screen on **Turn 13** (the encounter fired on turn 12), each with its own
empire intact: the attacker on Nunki with its fleet detached at Avalon, the defender on Regulus with
its own two-destroyer Alpha Fleet. `SNMAllCombatDone` → `SNMResumePlaying` did what
`ui-screen-map.md` §2.2 step 6 says it does.

Neither instance hung at `COMBAT_WAITINGFORPLAYER` or `COMBAT_WAITINGFORSERVER`, neither crashed,
neither showed a sync error, and the two turn counters never diverged. **P2 confirmed in full.**

## 4. P1 — `CombatHostPort` 3370 — **falsified**

This was the prediction with a number attached, and it failed cleanly.

The UDP socket table for the two SOTS pids was polled continuously — every 700 ms inside the guest
from lobby creation to turn 12, then every 2 s from outside across the whole battle (18:01:24 to
18:16, covering combat load, the full 240 s of tactical combat, the round-draw dialog and the return
to the strategy screen). **Both logs contain exactly one line each.** The socket table never changed:

```
UDP pid=2256 0.0.0.0:3369     <- host, HostPort
UDP pid=2256 0.0.0.0:50020    <- host, ephemeral
UDP pid=6620 0.0.0.0:50021    <- joiner, ephemeral
```

There is **no TCP at all** for either process at any point, confirming G2's import-table reading
(`bind`/`sendto`/`recvfrom` but no `listen`, no `accept`) on a second workload.

**3370 was never bound**: not when the lobby opened, not across twelve strategic turns, not at the
encounter query, not during combat loading, and not while the tactical simulation was running with
both players in it. W2 observed it unbound at lobby time and wrote "it must be opened later, when a
combat starts". On the direct-join arm, with the strategy host also hosting the battle, **it is not**.

The straightforward reading is that the combat lockstep is carried over the **already-established
strategy connection** — the host's 3369 socket and the two ephemeral sockets that carried
`SNMEndTurn` and `SNMDoEncounterQuery` also carry the `CNM*` combat messages. `CombatHostPort` is
presumably for the case the ini key exists to serve: a **separate** combat host, i.e. the
`SNMHostCombat` → `SNMHostCombatReply` handshake electing a *different* player (or a dedicated
server) to host the battle, which cannot happen in a two-player game where the strategy host is
already a participant.

**Consequences.**

- **Port-forwarding advice should say 3369 and only 3369.** PCGamingWiki and the community threads
  G2 quotes say "LAN mode + forward port 3369", and that is exactly right; nothing here supports
  adding 3370, at least for two players over a direct join.
- **Not generalised.** This is one battle, two players, one guest, with the strategy host as a
  combatant. Three or more players, a battle between two *clients* with the host merely relaying, or
  `sots_server.exe` as a dedicated host, could each elect a different combat host and bind 3370.
  That is the obvious next experiment and it is **not run** here.
- `LanScanPortRange` still covers **3369..3370** for the LAN browse broadcast, so 3370 is not dead
  in the binary — it is just not bound on this path.

## 5. P3 and P4 — GameSpy at combat time, and the control

**P3 — no GameSpy traffic at combat time — confirmed.** Across the whole run, sampled twice (once
mid-game and once with the battle in progress):

| Sample | Total packets on `tap141i0` | GameSpy ports | `*.gamespy.com` DNS |
|---|---|---|---|
| Through turn 9 | 42,381 | **0** | **0** |
| With the battle in progress | 82,470 | **0** | **0** |
| **Whole run, both capture files** | **101,835** | **0** | **0** |

Ports counted: UDP 27900, UDP 27901, TCP 28910, TCP 28900, TCP 6667, TCP 6500. This closes the
question G2 left open from the other direction: `GameSpy_NNBeginNegotiationWithSocket`
(`0x00412590`) has two call sites, the browser-mediated join and the host reporting path, and **the
combat host/join path is a third thing that reaches neither**. No `natneg1`/`natneg2` lookup ever
happened, at lobby time or at combat time.

The only names resolved in the combat window were Windows telemetry (`fd.api.iris.microsoft.com`,
`v10.events.data.microsoft.com`, `wpad.home.arpa`, …) plus exactly one
`www.kerberos-productions.com` — the MOTD fetch W2 documented, once per launch.

**P4 — combat traffic stays on loopback — confirmed, and it is the control.** Zero packets to or
from UDP 3369 or 3370 appeared on the tap, while 101,835 other packets did. The instrument is
demonstrably live and demonstrably blind to the game's own traffic, which is exactly the shape of
evidence that makes the zero in P3 mean something: **the capture cannot see SOTS's own packets, and
it still sees every other packet the guest emits — so a GameSpy packet would have been caught.**

It also settles a smaller question: **the combat host does not announce itself on the LAN.** Nothing
was broadcast to 3369 or 3370 when the battle started, so a combat session is not discoverable the
way a lobby is.

## 6. Adopting VM141 — what a ZFS clone of VM140 actually needed

Recorded because four more guests exist and this took under fifteen minutes.

The clone (`zfs clone rpool/data/vm-140-disk-0@clone-base`, fresh MAC `BC:24:11:8A:11:F0`) had **no
IPv4 address in any ARP table on spicy** and `qm agent` reported *"QEMU guest agent is not running"*
(none is installed on these guests). A 40-second `tcpdump -i tap141i0 -e "ether src <mac>"` caught
**one** packet — an IPv6 neighbour solicitation — and no DHCP at all, which looks exactly like a
clone whose inherited static IPv4 has been disabled for a duplicate-address conflict with its parent.

**It was none of those things. The guest was simply idle.** Driving the console with
`qm sendkey 141 …` into an elevated `cmd` and reading `ipconfig /all` off a `screendump` showed a
perfectly healthy **DHCP** lease, `192.168.10.143/16`, obtained at 16:36:40 — half an hour before
anyone looked. SSH with Alex's key worked on the first try.

**The lesson for the remaining guests: do not diagnose a cloned guest from ARP or from a short
packet capture.** An idle Windows box on a quiet LAN emits nothing for minutes at a time, and its
absence from the neighbour table only means nobody has talked to it. Take a `screendump` first.

Console driving via `qm sendkey` works and is worth knowing:

- `qm sendkey 141 meta_l` opens the Start menu; `meta_l-r` opens *Run* — but **key delivery lags by
  tens of seconds**, so a screendump taken 2 s after a keystroke will show the *previous* state.
  Send, wait, then shoot; a "nothing happened" screenshot is usually just early.
- Letters/digits map to their own names, and `shift-<key>` gives the shifted form; there is no
  string primitive, so a typing helper that expands a string into one `qm sendkey` per character
  (batched into a single SSH call) is the practical unit.
- The `re` account is a local administrator with UAC on: `cmd` + `ctrl-shift-ret` in *Run* raises the
  consent dialog, which `alt-y` accepts.

What the clone carried over correctly and did **not** need fixing: the game at `C:\SOTS`, DXVK, the
`SOTS`/`SOTSUI`/`SOTSUI2` scheduled tasks, the OpenSSH host keys and authorized keys, and — usefully
— **the Windows Defender Firewall rule for the game**, so the "has blocked some features of this
app" prompt W2 had to click through on VM140 never appeared here.

**One hazard found the hard way, and it will bite the next lane too: `pgrep -f tap141i0` matches
QEMU itself.** Stopping the capture with `pgrep -f "tap141i0" | xargs kill` on spicy killed the
guest — QEMU's command line contains `...,ifname=tap141i0,...`, so the VM's own process matched
alongside `tcpdump`, and the journal records `kvm: terminating on signal 15`. It cost nothing here
because every artefact was already off the guest, and the guest restarted clean (`fsutil dirty query
C:` → not dirty), but it is a plug-pull on someone's exclusive guest. **Kill the capture with
`pgrep -x tcpdump`, never with `-f` on the tap name.** The same trap catches `pkill -f "tcpdump -i
tap141i0"` run over SSH, where the pattern also matches the remote shell that is running it.

What it carried over that **had** to be fixed:

- **`shim.cfg` was lane W3's `hooks=trace`.** Any lane that wants the shipped game must overwrite it;
  `C:\SOTS\shim.cfg.l2backup` holds what was there.
- **The duplicate hostname.** Both guests answer to `SOTS-RE` and share a SID. It was left alone —
  SSH by IP is unaffected and nothing in this lane needed NetBIOS — but two machines with one name on
  one LAN is a latent trap for anything that resolves by name.
- **`C:\SOTS\launch-b.cmd` does not exist**, although `C:\SOTS\w2\sotsb.xml` invokes it and
  `C:\SOTS\w2\runB.txt` proves it ran on VM140. It has to be recreated (it reads the argument line
  from `C:\SOTS\w2\argsB.txt`); a copy is at `C:\SOTS\l2\` on VM141.
- **Slot 2 defaults to *Computer*.** A `/join` client cannot take an AI slot; click the small red
  cross at the slot card's top-right corner to set it *Open* before launching the joiner.

## 7. Files

- Capture: `verify/results/multiplayer/l2-combat.pcap` (on spicy at `/root/l2cap/`)
- Screenshots: `verify/results/multiplayer/l2-*.png`
- Socket-table log: `verify/results/multiplayer/l2-socks.log`
- Predictions, committed before the run: `sots-engine/docs/L2-predictions.md`
- Helper left on the guest: `C:\SOTS\l2\` (`ui.ps1` with wheel/jiggle support, `socks.ps1`,
  `poller.ps1`, `shim.cfg`, `l2ui.xml`); scheduled task **L2UI**; task **SOTSB** now registered.

## 8. What this run did NOT cover (rule 15)

- **One guest, loopback only.** No two-machine combat, no real network latency, no NAT, no packet
  loss. `CombatLatency` defaults to 1000 ms and was never stressed.
- **One battle, two players, and the strategy host was a combatant.** The `SNMHostCombat` /
  `SNMHostCombatReply` election never had a choice to make. Three-plus players, or a battle between
  two clients, is where 3370 might yet appear (§4).
- **Very lopsided.** Four destroyers against an undefended colony. No reinforcement waves, no
  reserves, no bombardment, no ceasefire negotiation, no surrender, no combat between fleets.
- **One combat round.** Multi-round battles, `SNMCombatTimeRemaining` extension, and the
  querying/combat/resume loop over several successive turns are untested.
- **No sync log.** `SyncCheckCombat` is on by default but `SyncLogCombat` is off, and it was left
  off; a desync would have shown as a symptom, not as a log.
- **`sots_server.exe` still not run.** The community's "the dedicated server does not seem to work"
  bug remains unreproduced, and it is now the cheapest remaining multiplayer item — and, per §4, the
  one most likely to be where `CombatHostPort` earns its name.
- **`hooks=off` throughout**, so nothing internal was observed: no `CNM*` message types, no wire
  format, no sync-check payload. Everything here is UI, sockets and packets.