• src/doors/syncmoo1/hw_sbb

    From Rob Swindell (on Debian L@VERT to Git commit to main/sbbs/m on Thursday, July 09, 2026 01:55:00
    https://gitlab.synchro.net/main/sbbs/-/commit/7504df3af17865306afe58a1
    Modified Files:
    src/doors/syncmoo1/hw_sbbs.c syncmoo1.h syncmoo1_input.c syncmoo1_io.c Log Message:
    syncmoo1: wire SFX audio into the 1oom hw backend

    hw_audio_sfx_* forward to syncmoo1_audio, the way hw_video_* forward to syncmoo1_io. The audio manager is created and probed at terminal enter, inbound bytes are fed to it from the input pump so it can resolve the capability reply, and hw_event_handle() drains the pending-store queue
    once the tier is known -- inside the engine's own "Preparing sounds"
    pause.

    Samples are Stored under moo1/sfx/s_<fnv1a8>, once each per session.
    A terminal without the audio APC (foot, xterm) never reaches tier 1, so
    nothing is uploaded and nothing plays: silent, not broken.

    Verified on the wire (harness2.py augmented to answer the audio
    capability probe, which it otherwise never does): every Store name is moo1/sfx/s_<hex>, no sample is Stored twice, and no Store precedes the capability reply. A DA1-only terminal (harness2.py's "foot" mode)
    receives zero Store/Load/Queue APCs. Live SyncTERM audibility (task
    Step 11) is a pending manual check.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian L@VERT to Git commit to main/sbbs/m on Friday, July 10, 2026 01:39:00
    https://gitlab.synchro.net/main/sbbs/-/commit/7a51a27620ab77ecfc75e83d
    Modified Files:
    src/doors/syncmoo1/hw_sbbs.c syncmoo1.h syncmoo1_config.c syncmoo1_door.c
    Log Message:
    syncmoo1: name the emperor after the player, and stop littering temp files

    Three small things the door owed its players.

    The new-game "your name" prompt invented a random emperor name for everyone. 1oom already had the hook -- "-ngn <player> <name>" (game.c) writes game_opt_new.pdata[player-1].playername, and ui_new_game_name() only generates a name when that string is empty -- so the door appends the option to argv after its own sanitize pass and the player sees their BBS handle, still free
    to edit it. Truncated to 11 characters, which is what uiobj_read_str() lets that screen edit, rather than to EMPEROR_NAME_LEN's 15. Player 1 is the human in every path a door can reach: the standard new-game flow prompts PLAYER_0, -new's HUMANS defaults to 1, and the custom game's is-AI digits default to 111110.

    That makes the drop file's alias load-bearing for the first time, so settle
    who wins. DOOR32.SYS line 7 is the BBS's own statement of who the user is; -name exists for the drop-file-less dev path (-s<fd>). Until now both wrote g_alias in one left-to-right argv pass, so a trailing -name silently outranked the drop file -- it only ever behaved because the installer happened to put %f last. The drop file is now authoritative in either order. The guard is a flag set by read_door32(), not a test for an empty g_alias: a drop file with an empty line 7 is the BBS saying "no alias", not "help yourself".

    hw_mouse_set_xy() was an empty stub. 1oom calls it to drag its own hand cursor onto a widget it has focused -- we cannot move a remote terminal's physical pointer, but the game draws its cursor from an internal position that syncmoo1_input.c already feeds, so writing the same state teleports it. The hand now follows a menu hotkey instead of sitting wherever the mouse was left. (Arrow-key navigation still does not fire; uiobj's directional search never requests a warp here. Separate problem, separate fix.)

    Finally, the base config snapshot is read back into memory and its temp file deleted in the same breath, rather than at prune time. The prune runs from atexit(), and a player who drops carrier exits through sm_door_hangup()'s _exit(), which skips atexit entirely -- so every disconnected session, the common way a BBS door ends, left a ~3KB syncmoo1_base.tmp in that player's directory. Verified on both exit paths: nothing survives either.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian L@VERT to Git commit to main/sbbs/m on Monday, July 13, 2026 00:36:00
    https://gitlab.synchro.net/main/sbbs/-/commit/203810878d92659a03d00e7d
    Modified Files:
    src/doors/syncmoo1/hw_sbbs.c syncmoo1_config.c syncmoo1_config.h xtrn/syncmoo1/syncmoo1.example.ini
    Log Message:
    syncmoo1: hide 1oom's hand cursor by default, add a [video] toggle

    Over a terminal the client already draws its own mouse pointer, and
    1oom's hand-shaped cursor doesn't line up with it -- so two cursors
    appear, the hand trailing the real pointer. Hide the game's hand by
    default and add a syncmoo1.ini [video] hand_cursor switch to bring it
    back for anyone who prefers the original MoO1 look.

    The hand reaches the terminal only through ui_cursor_draw1() in uiobj_finish_frame(), which is gated on ui_cursor_gfx_i != 0. The one
    seam this backend owns between the engine setting that sprite index (ui_cursor_update_gfx_i) and drawing it (ui_cursor_draw1) is hw_video_get_buf(), which the intervening ui_cursor_store_bg1() calls.
    So when the option is off, zero the index there: the draw becomes a
    no-op and the hand never composites. Mouse position and clicks
    (moouse_x/y) are untouched -- ui_cursor_gfx_i has no game-logic reader
    anywhere in 1oom, it only drives the cursor sprite -- so menus still
    work via the terminal's own pointer. The vendored 1oom tree is not
    touched.

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