wtclaude
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>
The book
Four chapters, in the order the work happens.
Read the dry run before any of them — a complete module designed on paper for a second game, and the shortest honest picture of the whole job.
| # | Chapter | What it covers |
|---|---|---|
| 1 | Your first module in twenty minutes | Copy the template, rename it, build it, install it, see a page. No theory. |
| 2 | The website module | The bulk of the work: module.json, register(ctx, api), the schema fragment, the client chunk, packaging, and what a module must never do. |
| 3 | The sidecar | Why the website never talks to a game server, what "persist before you forward" means, and what a thin sidecar is. |
| 4 | The game-side plugin | The least code and the highest stakes: never block the game thread. |
Chapters 1 and 2 quote template/, which CI builds against a pinned core, so their
code is a tree that is proved rather than prose that looks like one. Chapters 3 and
4 cite uo-link and servuo-plugins by file and identifier rather than by line, on
purpose: those repositories move for their own reasons and a line number in a book
is wrong the moment they do.
What is normative, and what is here
Nothing in these chapters is. Where a chapter and one of these disagree, the document is right and the chapter has a bug — say so:
| Authority | For |
|---|---|
MODULE_API.md |
Everything a module may do. |
MODULE_SYSTEM.md |
Why the module system is shaped this way, and how a module is installed and removed. |
link/PLAN.md + INTEGRATION.md |
The game↔sidecar wire protocol, as one real sidecar implements it. |
The chapters teach: the order to do things in, the reasoning, and the mistakes that cost this project time.