RunicGateway/docs
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(rust): the last fixes' docs (N1 N2 W20 W22 W23) and stage 4's core docs

Browse Source 
Stage 5 of PLAN_LAST_FIXES (docs#366).

- OPERATING.md: a RaidableBases section. Change its config with a
  restart, never a reload (N2); switching to the free edition rewrites
  a paid pack's profiles (N1).
- PLAN_REDESIGNS 14.3.4: no manual retry for Dangerous Treasures (Q39,
  W20); 11.4: which hook rbevent setowner raises (W23); 9.1 status.
- PLAYER_WALK: rows 2.2, 2.8 and 2.9, Before you start item 8 (BetterChat
  and the four title rules), Carbon's share trimmed to 2.11 (W22, W23).
- PROTOCOL: 20.5 world.error already-out (W3), 20.12 the rollback's log
  is RaidableBases' own (W9) and setowner's two hooks (W23).
- Core, from website#219: MODULE_SYSTEM 2.5 and MODULE_API 4.2 (one
  module at boot, W19), MODULE_API and EVENTS L (a resource's until read
  at reconcile, W1), EVENTS D/I/K and BACKEND_DESIGN (a draft's dry run
  carried by fingerprint, W5), EVENTS observability (W2's words).
- PLAN_LAST_FIXES: status, Q37-Q40 answers, 7 updated, 8 what was built.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
This commit is contained in:
claude
2026-10-22 01:36:57 -05:00
parent 27dd1f8d80
commit 20518ca816
9 changed files with 177 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
rust-link/PLAYER_WALK.md
View File

@@ -451,6 +451,12 @@ live walk ([`STEAM_SIGNIN.md`](../website/STEAM_SIGNIN.md) §6) comes first beca
the rest. Linking A's Steam account on the site makes it A's Rust link (D392), and every reward row
below needs a linked account.
> **Walked 2026-10-21** with A, on Rust 25902425, Oxide 2.0.7830 and Carbon 2.0.262. The rows A could walk
> alone passed, except that 4.1 stopped at steamcommunity.com by choice and 4.4 was not run. The results, and
> what is still owed with B, are in
> [`PLAN_LAST_FIXES.md`](../modules/rust/PLAN_LAST_FIXES.md) §1 and §6. Rows 2.2, 2.8 and 2.9 and *Before you
> start* item 8 were corrected afterwards (W22, W23), so they read as the game behaves.
**Before you start:**
1. **Both rigs on the latest builds.** Rust, Oxide and Carbon production builds are checked and
@@ -475,6 +481,11 @@ below needs a linked account.
`127.0.0.1`).
7. **For row 2.5:** A's Steam name changed for the length of that row to one with a space and a quote, such as
`Walk "Q" A`. Rust reads the name at connect, so A rejoins after changing it.
8. **Titles in chat, for rows 2.1, 2.4, 2.12 and 2.13.** **BetterChat** 5.2.15 on both rigs, because titles
reach chat only through it (PROTOCOL §18). On the walk site, a title rule on each server for the four columns
those rows read: raids (*Warlord*), the richest (*Magnate*), `treasureswon` (*Treasure Hunter*) and
`guardedwon` (*Warden*). *(Added 2026-10-22, W22: the first copy of this list named neither, and the Oxide
rig's BetterChat and the title rules were set up during the walk.)*
### Part 1 — Steam sign-in, on the web
@@ -493,14 +504,14 @@ below needs a linked account.
| # | Do this | You should see |
|---|---|---|
| 2.1 | **RaidableBases.** Staff spawn a raid base from a run near A. A raids it to completion | The feed names A, the raids column counts it, and *Warlord* is earned |
| 2.2 | A buys a base with RaidableBases' buy command, then staff lock one to A (`rbevent setowner A`) | A feed line for the purchase and one for the lock (D390) |
| 2.2 | A buys a base with RaidableBases' buy command, then staff lock one to A (`rbevent setowner A lockout`) | A feed line for the purchase and one for the lock (D390). Without `lockout`, `rbevent setowner A` reads as a second purchase, not a lock (W23) |
| 2.3 | Staff spawn a base from a run with PvP off, a set NPC count, and locked to A. A raids it | Each setting holds in the game: no PvP damage, that many NPCs, and nobody but A can raid it |
| 2.4 | **Economics.** A pay step pays the top three of a tally. A is one of the three (the other two are stand-ins) and is **offline** at the payout. A then joins | A popup on waking with the amount. A's balance shows on the Rust account page. Once A is the richest above the starting balance, *Magnate* shows in chat |
| 2.5 | **Command reward**, online: a *Reward by console command* step with `{steamid}` and `{name}` to A, under the name from item 7 | The command runs with A's id and the whole name, quote included, and A gets the reward |
| 2.6 | **Backpacks.** A fills a backpack and a second page. Staff open the staff view | Both pages, full |
| 2.7 | A opens their own backpack on the Rust account page, then requests a stand-in's | A's own shows. Another player's is refused |
| 2.8 | A *Bigger backpack* step for A. A puts items on the extra page, and the run ends. Repeat with A's inventory full | First the items move to A's inventory, then they land on the ground |
| 2.9 | **Permission rewards (§12.9, D333).** A *Permissions until the event ends* step with `autodoors.use`, A online. Repeat with A offline at the grant, then A joins | The message in chat and as a popup, online and on the next wake. Doors close by themselves while the run lasts and stop when it ends |
| 2.8 | A *Bigger backpack* step for A. A puts items on the extra page, and the run ends. Repeat with A's inventory full | Backpacks first moves the items into free slots on the pages A keeps. Only what does not fit there goes to A's inventory, and with the inventory full it lands on the ground. To see the inventory and the ground, fill the pages A keeps first (W22) |
| 2.9 | **Permission rewards (§12.9, D333).** A *Permissions until the event ends* step with `autodoors.use`, A online. Repeat with A offline at the grant, then A joins | The message, online and on the next wake. It comes in chat **or** as a popup, whichever the step chose, not both (W22); run it once each way to see both. Doors close by themselves while the run lasts and stop when it ends |
| 2.10 | Staff grant A `autodoors.use` for good first, then repeat 2.9 | At the run's end A **keeps** it (one already held is kept) |
| 2.11 | **Carbon:** A joins the Carbon rig once, then a *Bigger backpack* step and a §12.9 lend and give to A | All three **land** in the game. A Steam id Carbon has never seen cannot get them (§29.8, W17), which is why stand-ins could not prove this |
| 2.12 | **Dangerous Treasures:** a chest started from a run, and A wins it | The feed line, the `treasureswon` column, *Treasure Hunter* |
@@ -528,9 +539,11 @@ below needs a linked account.
### Carbon's share of the first player walks
[`PLAN_FIXES.md`](../modules/rust/PLAN_FIXES.md) §8 asks for the Carbon subset of the walks above. What RunicNPC's
9d and the step-2 walk already covered is left out. That leaves: the events walk's steps 1–5, and the rewards walk's
steps 1, 3 and 6, on Carbon with A. The map walk's Carbon steps are in 3.4.
**On Carbon, only row 2.11 is walked** (the org lead, 2026-10-21). The bridge file is the same on both
frameworks, and Carbon's halves of every integration passed without a player on 2026-10-19
([`PLAN_REDESIGNS.md`](../modules/rust/PLAN_REDESIGNS.md) §9.1), so the rest of the Carbon subset that
[`PLAN_FIXES.md`](../modules/rust/PLAN_FIXES.md) §8 asked for (the events walk's steps 1–5 and the rewards walk's
steps 1, 3 and 6) was dropped. The map walk's Carbon steps are still in 3.4, which needs B.
**What counts as a pass:** a Steam account linked on the site signs its owner in and is their Rust link, an
unlinked one signs nobody in, and someone else's Rust link cannot be taken. A real player is paid, rewarded,

22
rust-link/PROTOCOL.md
View File

@@ -2989,8 +2989,12 @@ credit block. A protocol-13 plugin still sends them, and the site still adds the
**`EventsMaxWorldCalls`** (config, default and ceiling 10) world events per run, counted over every call the
run made; behind `EventsEnabled`. A count the game partly ran answers `called` below `count`.
- Refusals are `world.error`: `not-ready`, `events-disabled`, `malformed` (no key or run, or a key over 128
characters), `bad-event`, `bad-count`, `not-placeable`, `too-many`, §15's location refusals, and `refused`
(the game had nothing to run).
characters), `bad-event`, `bad-count`, `not-placeable`, `too-many`, §15's location refusals, `refused`
(the game had nothing to run), and **`already-out`**: a `travelling_vendor` call while a Travelling Vendor is
already out. The game runs one at a time, so nothing is called, counted toward `EventsMaxWorldCalls` or kept
(W3, Rust PLAN_LAST_FIXES; before, the call answered `called: 1` and spawned nothing). Module-Rust reads it as
a success that called 0, and the step's note says *"a Travelling Vendor is already out on Main, and the game
runs one at a time; nothing new was called"*.
- `world.monuments` gains `maxWorldCalls`.
**Hello and status gain `console`: `{ "plugins": true | false }` (D363).** Whether this framework runs a plugin's
@@ -3568,8 +3572,11 @@ the old assembly, and the helper patches again. `rgr.status` prints its state.
- **The unload trap (§11.4.2):** a RaidableBases unload raises `Completed` for every live base with no owner
and no raiders. **Such a completion is neither sent nor counted.**
- `raid.purchased` and `raid.locked` come from the paid edition's `OnRaidableBasePurchased` and
`OnRaidableBaseLocked`: a player bought a base, or an admin ran `rbevent setowner` (D390). **Lockouts have no
hook in either edition and are not sent.**
`OnRaidableBaseLocked` (D390). A player buying a base raises `raid.purchased`. An admin's
**`rbevent setowner <player> lockout`** raises `raid.locked`. **The plain `rbevent setowner <player>` raises
`raid.purchased`**, as if the player had bought it, because RaidableBases' `TrySetPayLock` takes
`paylock = !args.Contains("lockout")` (W23, found in the end walk). **Lockouts** (the per-player cooldown
after a raid) **have no hook in either edition and are not sent.**
- `despawnAt` is the plugin's despawn time, in unix milliseconds.
- **None is sent while the world is not live** (§20.5's rule). A completion is still counted.
@@ -3666,7 +3673,12 @@ reloads the profiles as `rb.reloadprofiles` does**, and the reply is `pending` a
(§19.1). The `config.outcome` (`reload: "RaidableBases"`) settles when the helper's reload finishes: every
written profile in the plugin's table is `reloaded`; one that is not is **rolled back** and the old file
reloaded. Thirty seconds without a finished reload rolls back too. RaidableBases rewrites every profile file as
it reloads, so the outcome carries each file's version as it is on disk afterwards.
it reloads, so the outcome carries each file's version as it is on disk afterwards. **A rollback's log is
RaidableBases' own** (W9, Rust PLAN_LAST_FIXES): the bridge marks the server log's position when the job
starts, and reads back only RaidableBases' entries written since (tagged `[RaidableBases]`, which is how it
logs on both frameworks, or its title), without their stacks. When the failed profiles are named, only the
entries that name them are kept. When RaidableBases said nothing, there is no log, and the reason line stands
alone. Before, the outcome carried the tail of the server log, which is mostly other plugins' lines.
**Hooks.** `OnRaidableBaseStarted`, `OnRaidableBaseEnded`, `OnRaidableBaseCompleted`, `OnRaidableBasePurchased`
and `OnRaidableBaseLocked` join `rg.hooks`' list.