docs(modules): module-rust supports Carbon too, and ships a Pterodactyl egg
Three new decisions of record, and a new reference for the second modding framework. R19 - the bridge plugin is framework-agnostic from now, not ported later. Carbon is not a fork of Oxide but a separate loader shipping an Oxide compatibility layer, so one .cs in the Oxide.Plugins namespace serves both, with #if CARBON only where the APIs genuinely differ. Three existing decisions take an amendment and none is reversed: R18's config walk roots at Interface.Oxide.ConfigDirectory rather than a literal oxide/config (Carbon uses carbon/configs AND lets an operator relocate every directory from the command line); R2's permission store is Protobuf or SQLite on Carbon, which permanently closes the file-reading shortcut it never planned to take, while the PermissionExists pre-check survives because Carbon's bool return is the one thing we cannot read portably; R4's doctor asks which framework rather than whether Oxide, and gets a weaker "current enough" claim because Carbon ships rolling release tags. R20 - a Pterodactyl egg is a third supported deployment path beside the installer and the hand install, derived from the community "Rust Autowipe" egg, which already carries a FRAMEWORK variable offering vanilla/carbon/oxide. The sidecar runs inside the game's container, which is what lets D2 stand unchanged: a container's 127.0.0.1 is genuinely private, so the game link stays loopback and stays unauthenticated. Lands in phase 18 beside the installer. R21 - both rigs move to the Pterodactyl panel, because Oxide and Carbon cannot coexist in one install and so a single server cannot prove R19. Also retires the wipe-day maintenance that dominated section 4, and makes the rig Linux where every prior finding came from Windows and Mono. New: modules/rust/CARBON.md, the difference list - file layout, the permission store, the c. commands, 30 Carbon-only hooks, and 13 uMod names Carbon's catalogue omits (at least two of which look like renames). Sourced from Carbon's own published metadata and source at main, and labelled throughout as not yet proven on a live Carbon server. One outstanding request, recorded in section 3: the panel token on disk is an application key and Pterodactyl puts files, power and console on the client API, so iteration needs a ptlc_ key only the account holder can mint. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
This commit is contained in:
@@ -1,10 +1,13 @@
|
||||
# Rust — the Oxide/uMod ecosystem reference
|
||||
# Rust — the modding-framework reference
|
||||
|
||||
Reference material for the **upcoming `module-rust`**: a mirror of the uMod/Oxide documentation —
|
||||
the Rust game API *and* the game-independent plugin framework around it — captured here so the
|
||||
module can be designed and built against it without a round trip to umod.org on every question.
|
||||
Reference material for **`module-rust`**: a mirror of the uMod/Oxide documentation — the Rust game
|
||||
API *and* the game-independent plugin framework around it — captured here so the module can be
|
||||
designed and built against it without a round trip to umod.org on every question.
|
||||
|
||||
Everything below was **scraped verbatim from uMod on 2026-09-15**.
|
||||
The mirrored material was **scraped verbatim from uMod on 2026-09-15**. One file,
|
||||
[`CARBON.md`](CARBON.md), covers the *other* framework modded Rust servers run: PLAN.md **R19**
|
||||
commits this module to supporting Oxide and Carbon both, and that file records only where the two
|
||||
differ.
|
||||
|
||||
## The mirror
|
||||
|
||||
@@ -15,6 +18,7 @@ Everything below was **scraped verbatim from uMod on 2026-09-15**.
|
||||
| [`DEFINITIONS.md`](DEFINITIONS.md) | **What things are called.** 678 items (short name, id, display name) and 2,590 workshop skin ids across 104 items. |
|
||||
| [`OPERATING.md`](OPERATING.md) | **How it gets run.** The 6 operator pages — installing Oxide on a server, then installing, configuring and permissioning plugins. |
|
||||
| [`agent/`](agent/README.md) | The same facts in **machine shape** — TSV and JSONL, ~46% of the tokens. Generated in the same pass, so it cannot drift. |
|
||||
| [`CARBON.md`](CARBON.md) | **The other framework.** Where Carbon diverges from Oxide and nowhere else — file layout, the permission store, the `c.` commands, 30 Carbon-only hooks and 13 uMod names its catalogue omits. Sourced from Carbon's own metadata and source, **not yet proven on a live Carbon server.** |
|
||||
|
||||
**The one file here that is ours:** [`PLAN.md`](PLAN.md) — the schedule and the decisions of record
|
||||
for actually building `module-rust`. Everything else in this directory is copied from uMod; that one
|
||||
@@ -40,8 +44,12 @@ The dry run's central structural fact is the thing this reference serves:
|
||||
|
||||
> A ServUO shard is C# **source** the operator compiles into their own server, so our bridge plugin
|
||||
> can be anything we want. **A Rust server is a binary nobody outside Facepunch patches.** The only
|
||||
> way in is a mod — specifically an **Oxide plugin**, since Oxide/uMod is what modded Rust servers
|
||||
> run — hooking the game's own events.
|
||||
> way in is a mod — hooking the game's own events through a modding framework.
|
||||
|
||||
The dry run named that framework as Oxide, and **R19 corrected it: there are two.** Carbon runs an
|
||||
Oxide compatibility layer, so one plugin serves both and the ceiling below is the same ceiling —
|
||||
but *which* framework an operator installed is their choice, not ours. [`CARBON.md`](CARBON.md) is
|
||||
the difference list.
|
||||
|
||||
Two consequences, and they are the two halves of this directory:
|
||||
|
||||
@@ -50,8 +58,8 @@ Two consequences, and they are the two halves of this directory:
|
||||
those 477 hooks (or from a game type one of them hands you), the bridge cannot report it. That
|
||||
makes it the input to the Rust sidecar's event catalogue — the analogue of
|
||||
[`docs/link/PLAN.md`](../../link/PLAN.md) §5 on the UO side.
|
||||
2. **We are a guest in someone else's plugin framework.** Our plugin is compiled, loaded, permissioned
|
||||
and configured by Oxide, on Oxide's terms. [`OXIDE_API.md`](OXIDE_API.md) is that rulebook, and
|
||||
2. **We are a guest in someone else's plugin framework** — and we do not get to pick which one. Our
|
||||
plugin is compiled, loaded, permissioned and configured by Oxide or by Carbon, on its terms. [`OXIDE_API.md`](OXIDE_API.md) is that rulebook, and
|
||||
[`OPERATING.md`](OPERATING.md) is what the server owner has to do — which is the surface our
|
||||
deployment story has to sit on, the way
|
||||
[`installer/INSTALL.md`](../../installer/INSTALL.md) sits on top of ServUO.
|
||||
|
||||
Reference in New Issue
Block a user