https://gitlab.synchro.net/main/sbbs/-/commit/fd1ea6a2720e6052067c6695
Added Files:
xtrn/syncmoo1/syncmoo1.example.ini
Modified Files:
src/doors/syncmoo1/README.md xtrn/syncmoo1/install-xtrn.ini
Removed Files:
src/doors/syncmoo1/syncmoo1.example.ini
Log Message:
syncmoo1: ship the config the door actually needs, and install it

With no syncmoo1.ini the door runs on 1oom's stock defaults, and MoO1's copy protection is ARMED: after year 40, on a random turn,
ui_copyprotection_check()
demands a ship name printed in the boxed manual and ends the game after three wrong answers. A BBS player has no manual. Every sysop who installed this door was handing their players a game that destroys itself around turn 40.

Nothing seeded the config, either. install-xtrn.ini registered the door and fetched the LBX data but never created syncmoo1.ini, and the README told the sysop to copy the example by hand -- an instruction aimed at a file that was sitting in src/doors/, a directory no sysop reads.

So: move syncmoo1.example.ini into the door directory beside install-xtrn.ini and getdata.js, which is also the door's launch directory and therefore where sm_config_read_ini() looks for it. Copy it to syncmoo1.ini from the installer, via the same [copy:] section SyncDuke and SyncDOOM use (it prompts before overwriting an edited config).

Its [1oom] block is 1oom's own "1oom" preset -- the Options -> Preset -> 1oom button, ui_extra_toggle_preset() -- with two departures for a door. ui.mouse_warp_disabled is left out: upstream disables warp because on a
desktop
it yanks the player's physical pointer, but over a terminal warping is the
only
way the game's hand cursor can follow a keyboard hotkey. And ui.copy_protection_disabled is added, which the preset does not touch.

Drop -name from the installed command line. DOOR32.SYS line 7 already carries the alias, and the door now treats the drop file as authoritative, so passing both merely invites the question of which one wins.

The README claimed a text tier "comes along for free from termgfx" -- it does not; sixel is the only present path this door has, and a terminal without it gets no picture. It also still listed audio as deferred, and showed a typical invocation using the -name this commit removes. Fixed, and given the audio section it never had.

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

https://gitlab.synchro.net/main/sbbs/-/commit/632d3019f656ed1689bea0cc
Modified Files:
xtrn/syncmoo1/syncmoo1.example.ini
Log Message:
syncmoo1: document why the picture stops growing in a large terminal

The image is drawn at a whole multiple of the game's native 320x200 and
never more than 2x, so it tops out at 640x400 however large the terminal
is -- visibly smaller than the sibling doors that scale to fit. Nothing in
the shipped ini or the README said so, or said that it is deliberate, which leaves "MoO1 is tiny in my big terminal" an unanswerable question.

Whole multiples are what keep the interface readable. The horizontal
resample is nearest-neighbour, so an image narrower than 320 source columns does not soften, it deletes columns -- and MoO1's interface font draws
1-pixel strokes, which go with them: "SFX volume 100" renders as "SFX
volume 00". SyncDOOM and SyncDuke expose a [video] scale_max instead,
because a fractional scale costs them only sharpness, not characters.

Comment only: no key, no behavior change.

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

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