diff --git a/modules/rust/PLAN.md b/modules/rust/PLAN.md index 73537c2..8948535 100644 --- a/modules/rust/PLAN.md +++ b/modules/rust/PLAN.md @@ -718,11 +718,12 @@ Three traps recorded here because each cost time before it was understood: original is kept at `start.bat.bak` and the path-only fix at `start.bat.broken-order-20260915`. With the ordering right, the run is a delta and takes minutes. -- **`app_update` silently un-Oxides the server.** Oxide ships a *patched* `Assembly-CSharp.dll`, and - a Steam update restores Facepunch's. It does not remove `Oxide.Core.dll` and friends, so the - install still *looks* Oxided — it simply loads no plugins and raises no hook. **Re-extract - `Oxide.Rust.zip` over the tree after every `app_update`, and check the size**: on build 25230300 - vanilla is 9,758,544 bytes and Oxide 2.0.7716's is 9,953,280. +- **Re-extract Oxide after every `app_update`.** Updating the server and re-installing Oxide together + is the standard operator routine, not a discovery — Oxide ships a *patched* `Assembly-CSharp.dll` + and a Steam update restores Facepunch's. Recorded here only for the mechanical detail: the update + does **not** remove `Oxide.Core.dll` and friends, so a half-done install still *looks* Oxided while + loading no plugins and raising no hook. Check the size rather than the directory — on build + 25230300 vanilla is 9,758,544 bytes and Oxide 2.0.7716's is 9,953,280. - **`C:\oxide_files` is a 2025-04-23 Oxide and must not be copied anywhere.** Oxide ships a patched `Assembly-CSharp.dll`; that bundle's is 6,842,880 bytes against the live 9,953,280, so copying it over a real install is a hard downgrade. `D:\rust` is already correct and needs nothing from it. @@ -1202,18 +1203,19 @@ skeleton can start from it. > line as if it were the reply and discards the real one. It cost two wrong readings before it was > spotted. Collect every frame in a window; do not correlate one reply per identifier. -### 12.1 The rig's own scripts were broken in a way the earlier diagnosis missed +### 12.1 The rig's own script was broken in a way the earlier diagnosis missed Recorded in §4. In short: `start.bat` put `+force_install_dir` **after** `+login`, steamcmd discarded it, and every update run in the rig's history errored out without updating anything. The 2026-09-15 -"fix" changed the path and left the order, so it fixed nothing. Separately, `app_update` reverts -Oxide's patched `Assembly-CSharp.dll` while leaving Oxide's own assemblies in place, which produces a -server that looks Oxided and loads no plugins. +"fix" changed the path and left the order, so it fixed nothing. -Both matter beyond this workstation: **phase 18's installer will hit the second one.** An -operator who updates their Rust server has silently uninstalled Oxide, and therefore our plugin. -`doctor` should check the `Assembly-CSharp.dll` against the Oxide build, not merely that `oxide/` -exists. +The Oxide re-install in §4 is **not** a finding — pairing a server update with an Oxide re-install is +the routine every Rust host already follows, and saying otherwise would be this plan talking down to +its own audience. One narrow consequence is still worth carrying to **phase 18**: because +`app_update` leaves `Oxide.Core.dll` and the rest in place, a `doctor` check that tests for `oxide/` +or for Oxide's assemblies **passes on a server that is mid-routine**. Compare the +`Assembly-CSharp.dll` against the Oxide build instead, so `doctor` reports the real state rather than +a directory listing. ### 12.2 Four rules the R2 permission push must obey