LORD Setup

LORD — Legend of the Red Dragon by Seth Robinson, 1989 — is the
canonical door game. ANetBBS ships two ways to run it:

Bundled JS port (recommended, no DOS required) — Synchronet's
pure-JavaScript LORD rewrite, pre-installed at
anetbbs/games/sbbs_doors/lord/. Runs under Node.js via ANetBBS's
own compat shim — no Synchronet install required (see Path 1
below).
Original DOS under DOSBox + TCP nullmodem bridge — for
purists. Detailed below; see also DOS Door Recipe.

Path 1 — Bundled JavaScript LORD (works out of the box)

ANetBBS pre-seeds an active Game row for LORD on first install.
The game runs under Node.js via the Synchronet compat shim
(anetbbs/games/synchronet_compat.py) — no Synchronet install
required. The shim provides:

server/client/bbs/user/console globals so dorkit picks
its sbbs-mode console driver
Queue, strftime, scope-form require(), js.load_path_list,
js.on_exit(), js.exec(), etc.
A Node-friendly sbbs_input.js replacement that drives stdin
reads through dk.console.input_queue_callback instead of a
forked input thread
Full console.* API (clear, cleartoeol, gotoxy, right/left/up/down,
ctrlkey_passthru, …) wired to ANSI escape writes on stdout
Resolver priority that prefers <stubs_dir>/dorkit/ over the flat
<stubs_dir>/ so the dorkit-internal screen.js / graphic.js
win over older bare copies

Just play from /games/.

Path 1 fallback — install real Synchronet `jsexec` (optional)

If you want bit-perfect upstream behaviour or you're running another
door the compat shim doesn't cover, install Synchronet's jsexec.
The door_runner auto-detects it at standard paths
(/sbbs/exec/jsexec, /opt/synchronet/exec/jsexec,
/usr/local/sbbs/exec/jsexec, $PATH) and prefers it over the
Node shim when present.

git clone --depth 1 https://gitlab.synchro.net/main/sbbs.git /tmp/sbbs
# Synchronet's build needs siblings — start at the top:
cd /tmp/sbbs/src/sbbs3
make USE_DOSEMU=0 jsexec  || make CFLAGS_EXTRA="-I../conio" jsexec
sudo cp jsexec /usr/local/bin/

Or set SBBS_JSEXEC=/path/to/your/jsexec in the systemd unit's
environment.

Path 2 — Original DOS LORD under DOSBox

Prerequisites

DOSBox-staging (installed by install.sh/update.sh if you said
yes to that prompt)
xvfb-run (usually the xvfb package) if you want headless
operation — ANetBBS auto-wraps the DOSBox launch with it when found
on the system, no config needed
The LORD binaries (LORD.EXE, LORDCFG.EXE, LORD.DAT, etc.) in
a directory you own — <install>/doors/lord/

Registering the game

There's no DOSBox config file to hand-write — ANetBBS generates it
per launch. /admin/games/ → Add Game, type door_dos:

Executable Path: <install>/doors/lord/LORD.EXE
Working Directory: <install>/doors/lord/
Drop File Type: door.sys (or door32.sys)
Drop File Path: E:\ (see Door Setup's drive-layout table
— E: is always the per-node scratch drive on DOSBox)

At launch, ANetBBS mounts C: = your working directory, D: = its
bundled FOSSIL driver bundle, E: = a per-node scratch directory,
loads BNU.COM on COM1 automatically, copies the drop file from E:
into C: so LORD finds it in its own directory, then runs your
executable. See Door Setup for the full drive-letter table
(dosemu2 uses different letters than DOSBox for the same three
roles).

Bridge wiring

The BBS process opens a TCP connection to a bridge port it allocates
itself at launch time (no port to configure by hand) and ferries
bytes between the user's terminal writer and the socket. That's the
DosBridge class — see DosBridge.

LORDCFG gotchas

LORDCFG writes NODE1.DAT (or NODE<n>.DAT) into the working
dir. It's a binary config blob — leave it alone between runs.
DOOR.SYS COM0 means "carrier present"; set to COM1 for the
bridge to think it's on a real port. ANetBBS writes this
correctly out of the box.

Exit hangs

If LORD's exit doesn't release Xvfb cleanly, the watchdog needs a
waitpid on DOSBox plus an idle timeout — Xvfb can keep the PTY's
slave fd open past the actual door exit if not babysat. ANetBBS does
both. The fallback is Ctrl+]q which the bridge translates to
DOSBox's "kill emulator" sequence.