• exec/load/syncretro_lobby.js src/doors/syncretro/main.c syncretro.h sy

    From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Thu Jul 23 00:08:00 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/185d73c468ba23574f01c1f3
    Modified Files:
    exec/load/syncretro_lobby.js src/doors/syncretro/main.c syncretro.h syncretro_config.c syncretro_door.c syncretro_input.c xtrn/syncarcade/syncretro.example.ini xtrn/syncivision/syncretro.example.ini xtrn/syncnes/syncretro.example.ini
    Log Message:
    syncretro: end the game when the player has stopped playing

    The BBS cannot do this for a graphical door. Synchronet's per-program "Maximum Inactivity" is enforced against a counter that any successful socket read resets, and this door's frame pacing makes the terminal answer roughly ten times a second on its own, so the counter never climbs. A sysop who sets that value sees it accepted and sees it do nothing.

    So the door judges presence itself, on the one signal the pacing cannot forge: a real keystroke. sr_key_apply() feeds the shared termgfx idle clock, and nothing else does -- deliberately not the CSI dispatcher, which also sees the terminal's pace-acks and capability replies, and would report a departed user as present forever.

    Once per frame the door polls the clock. Inside the warning window it paints a countdown toast on the bottom row, re-armed each second so it stays up; any
    key clears it and restarts the full threshold, with no penalty for having been warned. At the threshold it latches, and sr_door_should_exit() ends the
    session through the same path the -t time limit already used.

    The countdown says "terminating", not "disconnecting": this ends the GAME and hands the player back to the BBS, it does not drop the call. Once they are at
    a normal BBS prompt the BBS's own inactivity timer applies again -- and that one does work, because nothing is pacing the link with DSR any more.

    Two ways to configure it, and BOTH work with no JS anywhere in the path, because this door also runs under other BBS software via DOOR32.SYS:

    - -i<seconds> on the command line. The lobby passes it, having evaluated the
    exempt ARS (which needs a user record the door cannot see), and passes -i0
    explicitly for an exempt user so the exemption positively overrides the ini. - [idle] timeout / warn in the door's own syncretro.ini, which on a
    non-Synchronet install is the only mechanism there is.

    The argument wins when given, mirroring how -t beats the drop file.

    Two things worth knowing for the next door that adopts this:

    - The clock is armed after sr_config_apply(), not beside the -t deadline in
    sr_door_setup(). Setup runs before the ini is read, so arming there would
    read a threshold of zero and silently leave every no-lobby install with no
    timeout -- on exactly the path where the ini is the only way to set one.
    - -i gets a predicate beside the -s and -t ones rather than an inline test,
    because sr_door_sanitize_argv() has to strip precisely what the parse
    consumed. A second spelling of that rule is how the two drift apart, and an
    unstripped -i900 would reach the core's argv.

    Verified headlessly through capture mode against a real core: -i fires at its threshold to the second, -i0 never fires, the ini alone fires with no -i present, an explicit -i0 overrides an ini timeout, and a "5s" style duration parses. The countdown's on-screen behavior was confirmed on a live node, which capture mode cannot show -- it stubs the toast out.

    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)