docs(book): a mod is a plugin too, and RCON is not the Rust answer #7

wtclaude · 2026-08-19T09:11:18Z

wtclaude commented

2026-08-19 09:11:18 +00:00

The reader-facing half of RunicGateway/docs#170. The kit was teaching, to an audience outside this org, that Rust needs "no game-side plugin to write at all" because it ships RCON. Overruled: the Rust dry run reaches the game through an Oxide plugin — C# loaded by the mod framework a modded Rust server already runs, hooking events and dialling out, exactly as the ServUO overlay does.

Chapter 3 kept its question and lost its example, which improved 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: it tells you what you asked about, when you ask. 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".

The thin-sidecar answer is unchanged for a game that genuinely does deliver events. What changed is that Rust is now the counter-example rather than the example, and it carries the finding 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.

And a second question a reader has to answer: how many sidecars. Rust pairs one sidecar to one game server, on that server's own host, because those servers sit on separate machines and a shared sidecar would be reached across a network by plugins meant to talk to it over loopback. The general form is in chapter 3 now: that question is answered by where the loopback boundary is, not by how many processes you would rather run — and a module holding several clients is the cheaper end of the trade, with core never learning there is more than one.

Chapter 4 and the README

Chapter 4 opened by telling a reader they may not need it if their game speaks a remote-control protocol, and framed its worked example as 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 an Oxide plugin in a closed server. The README's one-line version of the same claim goes with it.

Checks

checkLinks · checkChapterPaths · checkRenameSites — all green. No template or code changes.

AI disclosure

Written with Claude Code (Opus 5). Commits carry the Co-Authored-By trailer.

The reader-facing half of `RunicGateway/docs#170`. The kit was teaching, to an audience outside this org, that Rust needs *"no game-side plugin to write at all"* because it ships RCON. **Overruled: the Rust dry run reaches the game through an Oxide plugin** — C# loaded by the mod framework a modded Rust server already runs, hooking events and dialling out, exactly as the ServUO overlay does. ### Chapter 3 kept its question and lost its example, which improved 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: it tells you what you asked about, when you ask. 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"*. The thin-sidecar answer is unchanged for a game that genuinely does deliver events. What changed is that **Rust is now the counter-example rather than the example**, and it carries the finding 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. **And a second question a reader has to answer: how many sidecars.** Rust pairs one sidecar to one game server, on that server's own host, because those servers sit on separate machines and a shared sidecar would be reached across a network by plugins meant to talk to it over loopback. The general form is in chapter 3 now: that question is answered by **where the loopback boundary is**, not by how many processes you would rather run — and a module holding several clients is the cheaper end of the trade, with core never learning there is more than one. ### Chapter 4 and the README Chapter 4 opened by telling a reader they may not need it if their game speaks a remote-control protocol, and framed its worked example as 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 an Oxide plugin in a closed server. The README's one-line version of the same claim goes with it. ### Checks `checkLinks` · `checkChapterPaths` · `checkRenameSites` — all green. No template or code changes. ### AI disclosure Written with Claude Code (Opus 5). Commits carry the `Co-Authored-By` trailer.

wtclaude added 1 commit 2026-08-19 09:11:20 +00:00

docs(book): a mod is a plugin too, and RCON is not the Rust answer

PR Checks / prose (pull_request) Successful in 7s

Details

PR Checks / template (pull_request) Successful in -28s

Details

744e5b7944

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>

wtclaude added 1 commit 2026-08-19 09:16:54 +00:00

docs(book): name Oxide, and the question "how many sidecars" answers

PR Checks / prose (pull_request) Successful in 8s

Details

PR Checks / template (pull_request) Successful in 28s

Details

d497a3b09a

Follows the org lead's two corrections on docs#170. The Rust example is an OXIDE
plugin - naming the framework is the difference between a design a reader can
start from and one they have to go and choose for themselves - and the
architecture pairs one sidecar to one game server, on that server's own host.

Chapter 3 gains the general form of that second one, since it is the chapter
where a reader decides what to build: if your game runs as a fleet, "how many
sidecars" is answered by where the loopback boundary is, not by how many
processes you would rather run. Your module holding several clients is the
cheaper end of that trade, and core never learns there is more than one.

Co-Authored-By: Claude <noreply@anthropic.com>

whitlocktech merged commit 67aff992a4 into main

2026-08-19 11:15:34 +00:00

whitlocktech deleted branch docs/no-rcon-example

2026-08-19 11:15:35 +00:00

whitlocktech referenced this issue from a commit

2026-08-19 11:15:37 +00:00

Merge pull request 'docs(book): a mod is a plugin too, and RCON is not the Rust answer' (#7) from docs/no-rcon-example into main

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/Integration-kit#7