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

docs(rust): plan the end walk's in-game pass, with Steam sign-in

Browse Source 
PLAYER_WALK.md gains one section covering every row still owed after the
end walk's four passes (PLAN_REDESIGNS §9.1), plus Steam sign-in's live
walk (STEAM_SIGNIN §6). Steam comes first because linking A's Steam
account is also what makes A a linked Rust player (D392) for the reward
rows. Rows that already passed are left out. B-only rows and the phone
are split into their own parts, and AutoDoors 3.3.12 replaces
NightVision as the perk plugin.

PLAN_REDESIGNS §9.1 and STEAM_SIGNIN §8 point to the new section.
STEAM_SIGNIN §8 also records Module-Rust#53, the core pin moved to
#218's merge.

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-21 00:42:14 -05:00
parent 8f5a5b018b
commit c8501d0845
3 changed files with 101 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

94
rust-link/PLAYER_WALK.md
View File

@@ -441,3 +441,97 @@ unloaded (105 s and 90 s); a real code linked in under two seconds with the othe
read Bear, Wolf, Boar and Scientist. Two findings were fixed the same day and walked on the walk core: a
made-up code still waited one timeout on a stopped rig, 12 s (D186 — now 360 ms), and on Carbon a due audit
went out before the restarted world's hello was read (D187). Not walked: a player killed by another player.
## The end walk's in-game pass, with Steam sign-in (PLAN_REDESIGNS §9.1, STEAM_SIGNIN §6)
Added 2026-10-21. After the four passes in [`PLAN_REDESIGNS.md`](../modules/rust/PLAN_REDESIGNS.md)
§9.1, these are the only rows left, and every one needs a person. **A row that has passed is not walked
again** (the org lead, 2026-10-19), so nothing from §9.1's *Passed* list appears here. The Steam sign-in
live walk ([`STEAM_SIGNIN.md`](../website/STEAM_SIGNIN.md) §6) comes first because it also sets up
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.
**Before you start:**
1. **Both rigs on the latest builds.** Rust, Oxide and Carbon production builds are checked and
updated before the walk, and the builds are recorded with the results. Both rigs run `edge`'s bridge and
helpers with a protocol 14 sidecar.
2. **The plugins the rows need, on both rigs:** Economics, Backpacks, RaidableBases (the paid
edition), Dangerous Treasures, Guarded Crate with NpcSpawn, ZLevels, and **AutoDoors 3.3.12 with
*Use permissions* set to `true`**. AutoDoors is the perk plugin for §12.9's rows; NightVision 2.4.1
does not compile on the current Rust build.
3. **One walk site for everything:** website `edge` (MODULE_API 1.17.0, Steam sign-in) with
Module-Rust `edge`, on the walk database the four passes used. Open it at `127.0.0.1`, not
`localhost`, so its cookies stay apart from any other local core.
4. **Steam on the walk site.** A Steam Web API key from <https://steamcommunity.com/dev/apikey>. The
page asks for a domain name, but any value works, because the key is only used server to server. Steam
issues keys only to accounts that are not *limited*, which means at least US$5 spent on Steam. Paste it into Admin → Auth → Steam,
then enable Steam. The key is stored encrypted and is never shown again.
5. **Players.** **A** is the org lead's own Steam account, signed in to a player account on the walk
site (not staff). **B** is a second Steam account with its own player account. B is needed only for the rows
marked **B**; everything else needs A alone. A staff member at the website runs the steps.
6. **The phone** for Part 4: a build of the app from `Android-app` `edge`, connected to the walk site
(on a phone over USB or an emulator, `adb reverse` maps the site's port so the app can use
`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.
### Part 1 — Steam sign-in, on the web
| # | Do this | You should see |
|---|---|---|
| 1.1 | A, signed in with a password, opens the account page and presses ***Link Steam***, then approves on steamcommunity.com | Back on the account page, a Steam row with A's **persona name, avatar and SteamID64**. *Link Steam* is still offered, for another account |
| 1.2 | A opens the Rust account page | A's Steam account is listed as a linked Rust account, **linked just now** (D392). No `/link` code was used |
| 1.3 | A signs out, then on the player login presses ***Continue with Steam*** | A is signed in as A's own account. If A has two-factor sign-in on, the code is asked first |
| 1.4 | A presses ***Unlink*** on the Steam row | The Steam row goes. **The Rust link stays** on the Rust account page (D393) |
| 1.5 | Signed out, A tries *Continue with Steam* again | *"No account is linked"*, and no new account is made, even with SSO sign-up allowed (D395) |
| 1.6 | A links Steam again (1.1) | As 1.1. The Rust link is not doubled. Leave it linked for the rest of the walk |
| 1.7 | **B.** B links B's Steam account in game with `/link` and the code on the site. Then A presses *Link Steam* and signs in to steamcommunity.com **as B** | *"This Steam account is already linked to another account on this site"*. Nothing changes for A or B (D396) |
### Part 2 — in game, A alone (Oxide first, then Carbon where marked)
| # | 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.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.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* |
| 2.13 | **Guarded Crate:** one placed from a run near A, and A clears it | *"A cleared the guarded crate at M4"*, the `guardedwon` column, *Warden*, and a trigger on it fires |
| 2.14 | **ZLevels:** a run lends A `vip2`. A gathers before, during and after | The XP rate rises at once and goes back at the run's end |
### Part 3 — with B in game
| # | Do this | You should see |
|---|---|---|
| 3.1 | B is downed, and A revives B by hand (hold E) | Answers the open question from §5: whether a hand revive counts toward *Mender*'s `healed` |
| 3.2 | A bandages B | `healed` counts, once |
| 3.3 | A and B kill each other once (the identity walk's step 8) | `attackerType: "player"` with the attacker, weapon and distance; the killfeed shows it |
| 3.4 | The map walk ([above](#the-map-walk-phase-14-protocol-11)) steps 1–6, then 1 and 6 on Carbon | As written there |
| 3.5 | Events walk step 7, a `core.lease` on `spawn.max_rate` with several players on | As written there. It decides whether the two `spawn.max_*` keys join the allowlist |
### Part 4 — the phone (A)
| # | Do this | You should see |
|---|---|---|
| 4.1 | Signed out of the app, A opens the sign-in sheet and picks **Steam** | steamcommunity.com opens. After approving, A is signed in to the app as A |
| 4.2 | A opens the account screen | *Steam: &lt;name&gt;* with the SteamID64. With two Steam accounts linked, unlinking one removes only that one |
| 4.3 | A opens the Rust account screen | The Economics balance from 2.4 and A's own backpack from 2.6; a request for another player's is refused |
| 4.4 | The account walk on a phone ([above](#the-account-walk-on-a-phone-phase-8-android-leg-b)) and the map and events on a phone ([above](#the-map-and-events-on-a-phone-phase-15-android-leg-d)) | As written there. Rows 1 and 3 of the latter need B |
### 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.
**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,
lent and credited by every plugin the module integrates, online and on the next wake, on both frameworks.