docs(book): a mod is a plugin too, and RCON is not the Rust answer
All checks were successful
PR Checks / prose (pull_request) Successful in 7s
PR Checks / template (pull_request) Successful in -28s

The kit taught, to an audience outside this org, that Rust needs "no game-side
plugin to write at all" because it ships RCON. That is overruled: the Rust dry
run reaches the game through a MOD - a plugin loaded by the server's own
framework, hooking events and dialling out - exactly as the ServUO overlay does
(docs#170).

Chapter 3's section kept its question and lost its example, which turned out to
improve it. The useful test is not "does my game expose a protocol" but "does it
DELIVER EVENTS": a remote-control channel is built for an operator typing
commands and tells you what you asked about, when you ask, and a website needs
what happened whether or not anyone was listening. A channel that answers
questions can only be polled, and polling turns "someone left the clan at 14:02"
into "the count was different at 14:03".

Rust now appears in that section as the counter-example rather than the example,
and carries the finding that is actually worth having: its server is a BINARY
where ServUO is source you compile, and the three-part shape survives that
unchanged. The plugin-dials-out arrangement is not a property of having source
access.

Chapter 4 said a game with a remote-control protocol may not need any of it, and
that its worked example is source you build. Both now say what is true - the
rules in that chapter are properties of being inside a game loop, and apply
identically to a mod in a closed server.

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
2026-08-19 04:11:03 -05:00
parent 622abe9ed5
commit 744e5b7944
3 changed files with 43 additions and 25 deletions

View File

@@ -132,28 +132,37 @@ forwarded, a lossy live feed, an authenticated read API with a version on it.
## "But my game already speaks a remote-control protocol"
Then your sidecar is **thin**, not absent.
Then your sidecar is **thin**, not absent — and be sure the surface you are
thinking of actually carries what your module needs, because that is where this
question usually goes wrong.
Rust — the survival game — is the worked example here, in
[`rust-dryrun.md`][dryrun]: a module designed on paper for a game chosen for how
little it shares with Ultima Online. Rust ships RCON over WebSocket, so a
`rust-link` has no protocol to invent and no game-side plugin to write at all. It
keeps:
A remote-control channel is built for an operator typing commands: it tells you
what you asked about, when you ask. What a website needs is what *happened*
every kill, every join, every departure, delivered whether or not anyone was
listening at that moment. Those are different products, and a channel that
answers the first can only approximate the second by polling it, which turns
"someone left the clan at 14:02" into "the count was different at 14:03".
- the RCON connection, its credentials and its reconnect loop, **out of an Express
process** — where the failure mode is a wedged request handler;
- a store, so the site is not blank whenever the game is restarting, which for that
genre is a daily scheduled event;
- an HTTP + WS API with a version on it, so the module talks to one shape of thing
regardless of what the game speaks.
So the honest test is not *does my game expose a protocol* but **does it deliver
events**. If it does, your sidecar keeps that connection, its credentials and its
reconnect loop out of an Express process, keeps a store so the site is not blank
whenever the game restarts, and presents your module one versioned HTTP + WS
shape. That is what thin means: less code, the same architecture.
It drops the bespoke wire protocol and the plugin. That is what "thin" means: less
code, not a different architecture.
**Rust is the worked example, and it is not that case.** The dry run in
[`rust-dryrun.md`][dryrun] designs a module for it precisely because it shares so
little with Ultima Online — and its answer is a **mod**: a plugin loaded by the
server's own mod framework, hooking the game's events and dialling out to a
sidecar, exactly as the ServUO overlay does. The Rust server is a *binary*, where
ServUO is source a shard owner compiles, so the way in is a published hook API
rather than a file you edit. **The three-part shape survives that unchanged**,
which is the more useful finding: the plugin-dials-out arrangement is not a
property of having source access.
That document originally concluded the opposite — "no sidecar, the module dials
RCON directly" — and it carries a dated correction saying so, rather than having
been quietly rewritten. The value of a dry run is the record of what it found,
including where it was overruled.
That document reached the game over RCON until 2026-08-19, and before that
concluded there should be **no sidecar at all**. It carries both corrections,
dated, rather than having been quietly rewritten — the value of a dry run is the
record of what it found, including where it was overruled.
## Building yours