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

docs(rust): protocol 13 — the reload as the rigs showed it (W1-W5, D180)

Browse Source 
PROTOCOL.md §19.1: how the reload is asked for (Carbon: c.reload on the
server console), which log is read (Carbon.Core.log on Carbon), the pinned
failure lines on both frameworks, a load confirmed by a log read, and the
compiler's give-up retried once. PLAYER_WALK.md: the Carbon reload path and
failure words as walked. PLAN_FIXES.md: D180.

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-09-26 20:21:26 -05:00
parent cfa37c44e3
commit b8d9740ed0
3 changed files with 48 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
rust-link/PLAYER_WALK.md
View File

@@ -218,9 +218,10 @@ other, which is the whole point of putting them in one container.
**Run it on both frameworks.** From phase 3, done means done on Oxide and on Carbon (R19/R21), and
this phase has two specific things to confirm rather than assume:
- **The reload path.** The plugin asks `Interface.Oxide` for `ReloadPlugin` by reflection and falls
back to a console command — `c.reload` on Carbon, `oxide.reload` on Oxide, chosen by looking for a
Carbon assembly at runtime. A wrong prefix on Carbon prints **nothing at all**, which looks
- **The reload path.** On Oxide the plugin asks `Interface.Oxide` for `ReloadPlugin` by reflection
and falls back to `oxide.reload`; on Carbon it runs `c.reload` on the server console, because
Carbon's Oxide-compatible `ReloadPlugin` unloaded Kits and never brought it back on the 2026-09-26
walk (W3, PROTOCOL.md §19.1). A wrong prefix on Carbon prints **nothing at all**, which looks
exactly like a command that worked (`CARBON.md` §5), so the proof is `OnPluginLoaded` arriving,
not the command being accepted.
- **`OnPluginLoaded` / `OnPluginUnloaded` firing at all.** They are the rollback's only evidence. If
@@ -228,8 +229,11 @@ this phase has two specific things to confirm rather than assume:
plugin then has to judge by whether the target is loaded (PROTOCOL.md §19.1). `rg.hooks` at the console is the standing answer:
both names are in `ExpectedHooks`, so a framework that never raises one shows a zero.
- **The failure words.** Since protocol 13 a broken reload is recognised by the framework's log line
(PROTOCOL.md §19.1). Step 4 on Carbon is what pins Carbon's wording: if it waits the full 30 seconds
before rolling back, the line Carbon printed is not on the list yet.
(PROTOCOL.md §19.1), read from `Carbon.Core.log` on Carbon — `rg.config` prints the file (`log=`).
Step 4 pinned Carbon 2.0.259's wording on 2026-09-26: `[Kits] Failed ILoadConfig (…)`, after which
Carbon loads the plugin **anyway**, broken. The rollback must still happen and the reason must quote
that line; if a save waits the full 30 seconds before rolling back, the line Carbon printed is not on
the list.
**What counts as a pass:** a setting typed on the website changes what the running game does; a
deliberately broken config leaves the plugin loaded and the operator holding the reason; and no file