https://gitlab.synchro.net/main/sbbs/-/commit/72b55dd0acebbe590e503eba
Modified Files:
src/doors/syncdoom/README.md syncdoom.c
Log Message:
syncdoom: the door-directory defaults have to work without syncdoom.ini

A BBS-agnostic install is the executable and the WADs in one directory, and on that install a bare -iwad doom2.wad resolved against the current directory -- the BBS's, not the door's. read_syncdoom_ini() returns early when it cannot open the ini, and the [wads] block that resolves "blank = the door's own dir", exports DOOMWADDIR and fills g_wads_dir sits after that return, so the documented default applied only to the installs that had the file documenting it. The resolution moves into resolve_wads_dir(), called from both paths.

A drop file the door cannot open was as quiet: read_door32() returned on the failed read and the door fell through to stdio, drawing to a console nobody sees and reading keys nobody pressed. It now names the file and the errno --
a node macro the BBS never expanded shows up there as a directory that does
not exist. That complaint and the existing "no use to this door" one go
through dlog() instead of stderr, because on Windows a socket door's stderr
is a throwaway console and the log file is the only sink that reaches the sysop; they are held until read_syncdoom_ini() has named it.

The spaced -door32 <path> form read the drop file twice: the pre-scan took argv[i + 1] as the value without advancing i, so the next iteration matched that same path through the bare-door32.sys arm. Invisible while the failure
was silent, and the new message printed twice.

-door32 leaves the usage banner and the README, which document the drop file the way every sibling door takes it: a plain argument, recognized by its filename. The flag is still parsed, for the command lines that spell it. The README gains an install section for the BBSes that need any of this.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

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

https://gitlab.synchro.net/main/sbbs/-/commit/fad3deb2b8a734a3668546c8
Modified Files:
src/doors/syncdoom/README.md syncdoom.c
Log Message:
syncdoom: take the player's name from the drop file

DOOR32.SYS line 7 is the caller's alias, and the sibling doors read it. SyncDOOM never has: its own drop-file parser knew the comm type, the socket handle and the time limit, and the alias only came into existence when the
five copies were replaced by one in termgfx, 19901be145 (genre-4-turned, 2026-07-11) -- at which point the doors already reading line 7 were wired to the new field and this one had nothing to wire.

Nothing surfaced it because xtrn/syncdoom/lobby.js passes -name %a on every launch, so on the path that actually gets exercised the name arrives by
another route. An xtrn entry that runs the door directly, or any BBS with no lobby, got "Player".

The drop file now supplies the name, and an explicit -name still overrides it whatever the argument order -- the pre-scan that reads the drop file runs before the argument loop. SyncDuke resolves the same conflict the same way. SyncMOO1 deliberately does the opposite, letting the drop file outrank -name, but there -name exists only for the drop-file-less dev path; here it is a documented setting the lobby depends on.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

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