Subj : src/doors/syncduke/Game/src/game.c src/doors/syncduke/syncduke_door.c
To   : Git commit to main/sbbs/master
From : Rob Swindell (on Debian Linux)
Date : Fri Jun 26 2026 17:57:47

https://gitlab.synchro.net/main/sbbs/-/commit/8fb1ed22fe35eb429e310167
Modified Files:
	src/doors/syncduke/Game/src/game.c src/doors/syncduke/syncduke_door.c
Log Message:
syncduke: strip door args before the engine's command-line parser

A sysop reported SyncDuke dumping the Duke3D command-line help to syslog and
never starting.  The vendored engine's DOS-era checkcommandline() treats any
argv element beginning with '/' as a "/option" and, on an unrecognized one,
prints comlinehelp() and exits.  On a Unix host the DOOR32.SYS drop-file path
(Synchronet's %f) and the -home/-grpdir values are ABSOLUTE paths starting
with '/', so the engine misreads them -- e.g. "/home/.../door32.sys" parses as
option '/h' -> unknown -> help+exit.

It only "worked" when the install path's first letter happened to be a handled
option letter (e.g. /sbbs -> 's', which is the skill flag and survives -- as a
side effect forcing player skill 0).  And it surfaced only once the user had a
GRP: GRP init runs before checkcommandline and exits early when no GRP is
present, so a GRP-less install hits the GRP error first, masking this.

Fix: syncduke_sanitize_cmdline() compacts argv to remove the door's own args
(DOOR32.SYS path, -home, -grpdir, -s<fd>) just before checkcommandline, handing
the engine an engine-only argv.  All of these are already consumed by the
pre-main constructors, so stripping them is safe.  Path-independent, and it
also eliminates the incidental skill-0 side effect.

Reproduced (GRP present, /home launch path -> help dump) and verified fixed
(loads the GRP, proceeds into init, no help dump); /sbbs path unregressed.

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

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

.