https://gitlab.synchro.net/main/sbbs/-/commit/39aeecbc95d186a70ce76291
Added Files:
src/doors/syncduke/syncduke_net.c
Modified Files:
src/doors/syncduke/CMakeLists.txt syncduke_stubs.c
Log Message:
syncduke: LAN co-op Ä fill the mmulti seam with a UDP transport

The vendored Build/Duke netcode (game.c getpackets() + the move-FIFO
lockstep) was intact; only the mmulti transport seam was stubbed
single-player. syncduke_net.c fills it for 2-player LAN co-op:

- getpacket/sendpacket carry raw game packets between two door
instances over UDP, reporting the sender's player index from the
source address (broadcast when other<0).
- initmultiplayers does a tiny master/join handshake to set the
mmulti globals (numplayers / myconnectindex / the connect list)
before the engine reads them.
- env-configured, single-player-safe when unset:
SYNCDUKE_NET=master SYNCDUKE_NET_PORT=<port> -> player 0
SYNCDUKE_NET=join SYNCDUKE_NET_PEER=host:port -> player 1
- own UDP (no new dep): Chocolate-Duke's ENet mmulti is the protocol
oracle but the ENet lib was removed from the tree; this matches
SyncDOOM's from-scratch transport.

Validated end-to-end with two live instances on the loopback driven
into a shared E1L1 cooperative level (slash warp args /v1 /l1 /c2 --
the engine's parser only honors '/' options, not '-'): the full Duke
netgame negotiation flows bidirectionally (weapon order, version/CRC
match, names), both pass every waitforeverybody() sync barrier, both
complete enterlevel() (ready2send=1), and the move-FIFO lockstep then
pumps -- ~320 per-tic sync/input packets each way with the simulation
stepping in lockstep (ototalclock advancing tic for tic on both).

Sampled packet logging (first 16 then every 64th, gated on
SYNCDUKE_LOG) is left in as netplay bring-up diagnostics.
genericmultifunction stays a no-op stub.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net