https://gitlab.synchro.net/main/sbbs/-/commit/19ebfd3e8d467edf4eff0d97
Modified Files:
src/doors/syncdoom/syncdoom.c xtrn/syncdoom/syncdoom.example.ini
Log Message:
syncdoom: end the game when the player has stopped playing
The fourth door to adopt the shared idle-user clock. Same reasoning as the siblings: the BBS's own "Maximum Inactivity" cannot see a DSR-paced door,
since that counter is reset by any socket read and frame pacing makes the terminal answer ~10x/second on its own. Presence has to be judged on real input, which only the door can tell apart from its own pace-acks.
Warn-then-terminate, countdown on the status row, same wording as the
siblings, 10-minute default. Configured by -i<seconds> or the door's own
[idle] section; the argument wins when given, so a launcher can pass -i0 to excuse an exempt user. Unset is NOT off, which the shipped template now
says.
-i IS MATCHED ON AN ALL-DIGIT SUFFIX, not by prefix like this door's other flags. Every one of those uses strncmp(argv[i], "-x", 2), and the same shape for "-i" would also match DOOM's own -iwad and swallow the WAD selection.
The digit-suffix rule cannot: -i600 is ours, -iwad is the engine's. Parse
and strip share the rule, so the engine's argv keeps -iwad untouched.
The activity hook goes in TWO places, and deliberately not in the obvious
one. key_seen() (the legacy-byte path) and key_dispatch() (the native kitty/evdev path) are hooked separately; their common keyq_push() is not, because expire_keys() synthesizes key-ups through it -- that would forge activity for a player who has already walked away. Mouse events count too, since -mouse steer/follow lets someone drive for a long stretch with no keystroke.
Input that answers the countdown is consumed rather than delivered: in DOOM every key does something and Escape opens the menu, so "press any key" must
not also press it at the game.
The countdown does not get its own writer. It becomes emit_overlay()'s
content while it is showing, so it lands on the row that function already
owns and inherits its existing "the fresh frame painted over the reserved
row -> redraw" handling for free. Two consequences worth naming: the row is drawn even when the player never pressed Ctrl-S (both call sites now open
the gate for it), and when the countdown clears with no stats strip to put back, the row is wiped and a full repaint forced -- in the bitmap tiers that row is part of the picture, and a bare wipe would leave a black band,
exactly the trap the sibling door hit.
Arming needs no special ordering here: read_syncdoom_ini() already runs
before the argument loop, so a single init after that loop sees both
sources.
Verified offline (-i fires to the millisecond, -i0 never does, the countdown ticks down on the wire with correct plurals, the ini alone works with no -i,
an explicit -i overrides it, and -iwad still selects the WAD), and on a live node for the warning, the countdown and the termination.
Co-Authored-By: Claude Opus 4.8 (1M context) <
noreply@anthropic.com>
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)