Door Setup

How to register a new door so users can run it from the menu.

1. Web doors

The simplest case — these live entirely in the browser.

/admin/games/ → Add Game. Type = builtin_web ("Built-in Web
Game" in the dropdown). Provide the HTML template path (relative to
anetbbs/templates/games/web/). That's it.

2. Remote rlogin doors (Synchronet game servers)

Most "play LORD on someone else's BBS" setups go through rlogin.

/admin/games/ → Add Game. Type = door_rlogin. Fields:

• Server (host:port) — the remote server, one field, e.g.
  game.example.com:513
• User-template PASSWORD [TERMINAL] — three space-separated
  values in one field: a template for what gets sent as the
  rlogin username (tokens: @USER@/@ALIAS@/%U/%u), the
  session password agreed with the remote, and an optional
  [TERMINAL] value (e.g. xtrn=LORD408) to drop straight into a
  specific door on servers that support it.
• BBS Tag (optional) — appends -TAG to your BBS's identifying
  string so the remote sysop can tell which BBS a caller came from.
  A separate field purely so you don't have to hand-assemble the
  combined string yourself.

⚠ Synchronet-flavored rlogin uses password first, username
second — opposite of RFC 1282. ANetBBS's outbound client
already does this; you don't need to flip anything, just fill in
the fields above in the order they're labeled.

3. DOS doors

The full setup — DOS exe + DOSBox/dosemu2 + TCP nullmodem bridge.
Detailed in DOS Door Recipe. Short version:

1. Install DOSBox-staging (or dosemu2, for the door_dosemu type).
2. Drop the door's files under <install>/doors/<door-name>/.
3. Register the game in the admin UI with type door_dos (or
   door_dosemu): Executable Path, Working Directory,
   Command Line Args, Drop File Type, Drop File Path.
   That's it — there's no bridge-port or raw DOSBox/dosemu2
   command-line field to fill in by hand. The bridge picks a free
   TCP port itself at launch, and the emulator invocation (including
   the serial1=nullmodem/mount setup) is built automatically from
   the fields above.
4. Test by playing it. Watch
   journalctl -u anetbbs -f for bridge bytes-in/out (telnet, SSH,
   and rlogin are one unified systemd service, not separate units).

DOS Door Recipe walks through LORD as a concrete example,
including the LORD Setup gotchas.

4. Native Linux doors

A bare door_native type — invoked with the dropfile path on
argv. Works for forks like lord-linux or any compliant
DOOR.SYS-aware binary.

5. Bundled Python doors

Some doors ship as pure Python and need no setup at all — type
builtin_python, run natively in the terminal process, no external
binary, DOSBox, dosemu2, or jsexec required. ANetCRAFT (ANetBBS's
own Minecraft-inspired 2D survival game) is the current example and
is pre-seeded active by default. Nothing to register — it's
already in /games/ on a fresh install.

This is a separate codebase from the standalone ANetCRAFT-Door
project (a C# .NET Minecraft-replica door with the same name) — don't
confuse the two when troubleshooting.

Per-door config tips

• Time limits: set on the Game row. The BBS enforces them with
  a watchdog that closes the user's writer when time runs out.
• Max nodes: how many users can be in the door simultaneously.
  Most classic DOS doors are single-user; set 1.
• Idle timeout: if the user's terminal goes silent for N
  minutes the watchdog kicks them. Useful for doors that don't
  detect carrier loss.

Debugging

• Launch the door yourself as a normal user (sysop account) from the
  Game Center — there's no separate admin-side test-launch button.
• The Game row has a Last error field that the bridge writes to
  on launch failure.
• For DOS doors, run DOSBox interactively to see what the bridge is
  feeding it — the DosBridge page has the recipe.