https://gitlab.synchro.net/main/sbbs/-/commit/c504019e0f2b623f9d17a0a0
Modified Files:
src/doors/syncmoo1/README.md src/doors/syncretro/README.md src/doors/syncrpg/README.md src/doors/syncscumm/README.md
Log Message:
doors: drop internal "Mx" milestone jargon from the door READMEs

The door READMEs described status in terms of "M1/M2/M3..." milestones -- opaque shorthand that means nothing to a reader and, worse, is reused
across every door/lib/project to mean something different each time. A
user on IRC hit exactly this ("what is M5?"). READMEs and other user/sysop-facing docs should describe what works in plain terms.

- syncretro: "Status: M1 (video), M2 (input), M3 (multi-core), M4
(audio) and M6 (Windows) complete" -> named plainly; the "(M5: ...)"
remaining-work label reworded to "core options and save states".
- syncmoo1: "Status: M1 + audio" -> "playable, not yet polished"; dropped
"milestones" from the DESIGN.md pointer.
- syncrpg, syncscumm: dropped "milestones" from the See-also pointers.

Docs only. Internal design docs (DESIGN.md, plans/, the M#_*.md notes,
etc.) keep their milestone tracking -- that's legitimate developer-facing
use; this change is scoped to the user/sysop-facing READMEs. Prompted by Accession's question on IRC.

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

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

https://gitlab.synchro.net/main/sbbs/-/commit/bc7f7f0c8947435119ba6a85
Modified Files:
src/doors/syncmoo1/README.md syncmoo1.h syncmoo1_config.c syncmoo1_config.h syncmoo1_input.c syncmoo1_io.c xtrn/syncmoo1/syncmoo1.example.ini
Log Message:
syncmoo1: tell a text terminal why the game will not run

MoO1 is a picture and there is no text tier to fall back to, but the door
drew for whatever was on the other end. A terminal with neither sixel nor
JXL was sent the sixel stream anyway and sat on a black screen the player
could not abort out of.

Gate the present path on the shared verdict (termgfx/gfxgate.h): once the probes are out and before any encode, hold the first frames briefly for
the device-attributes reply, then either draw or turn the terminal away
with a notice and a clean exit. Holding first is what keeps a rejected
terminal from seeing a screenful of sixel before the explanation of why
it cannot have one.

The gate reads input only while undecided and latches as soon as a tier
is known, leaving the frame path untouched in steady state: reading
alongside a paced frame is the same race sm_io_vscale_probe() already
drains around. Silence is not a refusal -- a terminal that never answers device-attributes still gets to play.

Synchronet repaints its own menu the moment the door returns, so the
notice waits to be dismissed: a keypress, or [text] no_graphics_pause
seconds, whichever comes first. An unattended or already-dead client
cannot hold the node past that, and 0 disables the wait.

[text] no_graphics and no_graphics_file let the sysop word the notice. A relative path is pinned to the launch directory while cwd is still there,
since the gate reads the file long after the chdir into the per-user home
and would otherwise look for it beside that player's saves.

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

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