docs(modules): the Rust dry run reaches the game through an Oxide plugin, not RCON #170

wtclaude · 2026-08-19T09:09:59Z

wtclaude commented

2026-08-19 09:09:59 +00:00

Overruled by the org lead: RCON is not used. Rust gets the same three parts UO has — a plugin inside the game that dials out, a sidecar that persists before it forwards, a module that talks only to the sidecar — and the plugin is an Oxide plugin, since Oxide is what modded Rust servers run.

And the architecture is one server, one sidecar (second correction), not one sidecar fronting a community's several servers — which is exactly the arrangement a UO-shaped reading reaches for, and which this document had. Rust servers sit on separate VMs in practice, so a shared sidecar would be reached across a network by plugins that are supposed to talk to it over loopback: that trades the invariant making the design safe for a saving in process count. Recorded as a reevaluable assumption, not a principle.

RCON was this document's premise, so the correction reaches further than the transport paragraph:

The reason Rust is a good second game changes. It was "its server speaks a protocol nobody has to write". It is now "its server is a binary" — the opposite of ServUO, which is source a shard owner compiles — so the way in is a published hook API, and the shard-dials-out invariant has to survive that change of footing. It does, unchanged, which is a stronger result than the one the document originally claimed.
The announce leg asks each server's sidecar to send a command down the socket its plugin already holds. Note the plural: a news post reaches every configured server and the leg's classify answers for the set.
The Team provider refuses when no plugin is connected, not when RCON is unreachable — and one-to-one is what makes its complete answerable rather than vague: "every team there is" means every team on this server. Five of six sidecars reachable is complete left off, and core adds and updates without archiving.
Two hooks answer questions UO had to work for: a wipe arrives as an event, and membership is real-time. So this module's Team provider is event-driven with a baseline on connect rather than sweep-driven — and the provider contract does not change by a line, which is the part worth keeping: core never needed to know how the data arrives.
Finding 2 ("one module, one game" is not "one module, one server") gets stronger: the module holds several sidecar clients and core never learns there is more than one.

The 2026-08-12 correction block stays and a second one sits beside it rather than the history being edited out — this document's own convention. It also records what the change costs: this project no longer has a worked example of "a game that already speaks a remote-control protocol, so its sidecar is thin".

Companion

RunicGateway/Integration-kit#7 — chapter 3, chapter 4 and the README, which repeated the RCON claim to the outside audience.

AI disclosure

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

**Overruled by the org lead: RCON is not used.** Rust gets the same three parts UO has — a plugin inside the game that dials out, a sidecar that persists before it forwards, a module that talks only to the sidecar — and the plugin is an **Oxide plugin**, since Oxide is what modded Rust servers run. **And the architecture is one server, one sidecar** (second correction), not one sidecar fronting a community's several servers — which is exactly the arrangement a UO-shaped reading reaches for, and which this document had. Rust servers sit on separate VMs in practice, so a shared sidecar would be reached across a network by plugins that are supposed to talk to it over loopback: that trades the invariant making the design safe for a saving in process count. Recorded as a **reevaluable assumption**, not a principle. RCON was this document's premise, so the correction reaches further than the transport paragraph: - **The reason Rust is a good second game changes.** It was *"its server speaks a protocol nobody has to write"*. It is now *"its server is a **binary**"* — the opposite of ServUO, which is source a shard owner compiles — so the way in is a published hook API, and the shard-dials-out invariant has to survive that change of footing. **It does, unchanged**, which is a stronger result than the one the document originally claimed. - The announce leg asks each server's sidecar to send a command down the socket its plugin already holds. Note the plural: a news post reaches every configured server and the leg's `classify` answers for the set. - The Team provider refuses when **no plugin is connected**, not when RCON is unreachable — and one-to-one is what makes its `complete` answerable rather than vague: *"every team there is"* means every team on **this** server. Five of six sidecars reachable is `complete` left off, and core adds and updates without archiving. - **Two hooks answer questions UO had to work for**: a wipe arrives as an event, and membership is real-time. So this module's Team provider is **event-driven with a baseline on connect** rather than sweep-driven — and the provider contract does not change by a line, which is the part worth keeping: core never needed to know how the data arrives. - Finding 2 (*"one module, one game" is not "one module, one server"*) gets stronger: the module holds several sidecar clients and core never learns there is more than one. The 2026-08-12 correction block stays and a second one sits beside it rather than the history being edited out — this document's own convention. It also records what the change **costs**: this project no longer has a worked example of *"a game that already speaks a remote-control protocol, so its sidecar is thin"*. ### Companion `RunicGateway/Integration-kit#7` — chapter 3, chapter 4 and the README, which repeated the RCON claim to the outside audience. ### AI disclosure Written with Claude Code (Opus 5). Commits carry the `Co-Authored-By` trailer.

wtclaude added 1 commit 2026-08-19 09:10:01 +00:00

docs(modules): the Rust dry run reaches the game through a MOD, not RCON 4e98ed6bd5

Overruled by the org lead: RCON is not used. Rust gets the same three-part shape
UO has - a plugin inside the game that dials out, a sidecar that persists before
it forwards, a module that talks only to the sidecar - and the plugin is a mod
loaded by the server's mod framework, exposing data through hooks.

The document had RCON as its premise, so the correction reaches further than the
transport paragraph:

- The reason Rust is a good second game changes. It was "its server speaks a
  protocol nobody has to write". It is now "its server is a BINARY" - the
  opposite of ServUO, which is source a shard owner compiles - so the way in is
  a published mod API and the shard-dials-out invariant has to survive that
  change of footing. It does, unchanged, which is a stronger result than the
  one the document originally claimed.
- The announce leg sends a command down the socket the mod already holds,
  rather than calling rcon.say.
- The provider refuses when no mod is connected, not when RCON is unreachable.
- Two hooks answer questions UO had to work for: a wipe arrives as an event, and
  membership is real-time - so this module's Team provider is event-driven with
  a baseline on connect rather than sweep-driven. The provider contract does not
  change by a line, which is the part worth keeping: core never needed to know
  how the data arrives.

The 2026-08-12 correction block stays and a second one is added beside it rather
than editing the history out - this document's own convention, and the thing that
makes it worth reading twice. It also records what the correction COSTS: this
project no longer has a worked example of "a game that already speaks a
remote-control protocol, so its sidecar is thin".

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

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

docs(modules): name Oxide, and pair one sidecar to one server 11d20a9a17

Two corrections from the org lead on the transport rewrite.

It is an OXIDE plugin, not "a mod loaded by the server's mod framework". Oxide is
what modded Rust servers run, and naming it is the difference between a design a
reader can start from and one they have to go and pick a framework for.

And the architecture is ONE SERVER, ONE SIDECAR - not one sidecar fronting a
community's several servers, which is the arrangement a UO-shaped reading reaches
for and which this document had. Rust servers in practice sit on separate VMs, so
a shared sidecar would have to be reached across a network by plugins that are
supposed to talk to it over loopback: it trades the invariant that makes the
design safe for a saving in process count.

The cost lands on the module, which is the right place for it - it holds one
client per configured server rather than one client to an aggregator - and it
makes the Team provider's `complete` answerable rather than vague, since "every
team there is" now means every team on THIS server. Five of six sidecars
reachable is `complete` left off, and core adds and updates without archiving.

Recorded as a reevaluable assumption rather than a principle, because that is
what it is. Nothing in the contract objects either way: core is not in this
conversation at all, which finding 2 now says.

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

wtclaude changed title from ~~docs(modules): the Rust dry run reaches the game through a MOD, not RCON~~ to docs(modules): the Rust dry run reaches the game through an Oxide plugin, not RCON

2026-08-19 09:17:09 +00:00

whitlocktech merged commit e38792b21b into main

2026-08-19 11:16:33 +00:00

whitlocktech deleted branch docs/rust-dryrun-mod-transport

2026-08-19 11:16:33 +00:00

whitlocktech referenced this issue from a commit

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

Merge pull request 'docs(modules): the Rust dry run reaches the game through an Oxide plugin, not RCON' (#170) from docs/rust-dryrun-mod-transport into main

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/docs#170