All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 6s
A developer plugin, never shipped, that measured the six questions stage 2 depends on (docs/runicnpc/PLAN.md §9, stage 1) on both rigs: the subclass swap, saving across a hard kill, what Rust's brain honours, navmesh coverage, the cost of 1/10/100 idle and fighting, and the death screen and bridge frames. It spawns stand-in players (player.prefab, a made-up user id, IsNpc false) as targets, at the org lead's suggestion. It needs a hidden Kits kit, rnhrevolver. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
83 lines
3.6 KiB
Markdown
83 lines
3.6 KiB
Markdown
# RunicNPC
|
|
|
|
Runic Gateway's own NPC plugin for [Rust](https://rust.facepunch.com/), on **Oxide and Carbon**.
|
|
|
|
Other plugins drive it through an API, and admins use it directly in game through chat commands. It
|
|
works on its own, and on a [Runic Gateway](https://gitea.whitlocktech.com/RunicGateway) server the
|
|
website authors its NPC profiles and events use its NPCs. The plan of record, stage by stage, is
|
|
[`docs/runicnpc/PLAN.md`](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/runicnpc/PLAN.md).
|
|
|
|
> **Status: stage 0.** The plugin loads, answers its API version, and reports on itself. It spawns
|
|
> nothing yet. Stage 1 is a measuring spike; the NPC and its API arrive in stage 2.
|
|
|
|
## Requirements
|
|
|
|
- **[Kits](https://umod.org/plugins/kits)** — required. A profile names kits, and that is how every
|
|
RunicNPC NPC is equipped (D217). The plugin declares `// Requires: Kits`, so neither framework
|
|
loads it without Kits.
|
|
- Oxide **2.0.7726** or Carbon **2.0.259**, or newer: the builds it has been loaded on
|
|
(`plugin.toml`).
|
|
|
|
## Installing it
|
|
|
|
On a Runic Gateway server, the [installer](https://gitea.whitlocktech.com/RunicGateway/installer)
|
|
and the Pterodactyl egg will install it from the Rust bundle, pinned and checksummed (D224, from
|
|
stage 4). Until then, and on any other server:
|
|
|
|
1. Download `runicnpc-<version>.tar.gz` and `SHA256SUMS` from this repository's
|
|
[releases](https://gitea.whitlocktech.com/RunicGateway/runicnpc-rust/releases), and check the
|
|
tarball against it (`sha256sum -c SHA256SUMS`).
|
|
2. Copy `runicnpc/RunicNPC.cs` into `oxide/plugins/` or `carbon/plugins/`. The framework compiles
|
|
and loads it on the write.
|
|
|
|
`runicnpc/manifest.json`, beside it, states the release's version, commit, API version, framework
|
|
floors, required plugins, and the sha256 of every file it ships.
|
|
|
|
## Checking it
|
|
|
|
```
|
|
rnpc.status
|
|
```
|
|
|
|
Answers at the server console and over RCON: the version, the API version, and which of the
|
|
plugin's hooks have fired. A hook that never fires is the first sign a Rust or framework update has
|
|
renamed it, because neither framework reports a hook that matches nothing.
|
|
|
|
## For other plugins
|
|
|
|
Every call is prefixed `RunicNpc_` and reached through `Call`:
|
|
|
|
```csharp
|
|
[PluginReference] private Plugin RunicNPC;
|
|
|
|
int api = RunicNPC?.Call<int>("RunicNpc_ApiVersion") ?? 0;
|
|
```
|
|
|
|
Stage 0 has only `RunicNpc_ApiVersion()`. The full API is planned in PLAN.md §4 and will be
|
|
documented as `docs/runicnpc/API.md` in stage 2. The API version moves when a call or a raised hook
|
|
changes shape, not on every release.
|
|
|
|
## Repository layout
|
|
|
|
| Path | What |
|
|
|---|---|
|
|
| `plugin/RunicNPC.cs` | The plugin. The only file a server gets. |
|
|
| `plugin.toml` | Its declarations: API version, framework floors, required plugins. The release copies them into the manifest. |
|
|
| `scripts/checkPlugin.js` | The static checks run on every pull request and again before a release (see its header). |
|
|
| `tools/` | Developer scaffolding for the test rigs, never shipped: the panel scripts (see `tools/rigs.example.json`) and `RunicNpcHarness.cs`, the stage 1 measurement plugin (`docs/runicnpc/PLAN.md` §9). |
|
|
|
|
## Releases
|
|
|
|
Work lands on `edge` and is cut over to `main`; every releasable push to `main` tags and publishes a
|
|
release (`.gitea/workflows/release.yml`). The version comes from Conventional Commits since the
|
|
last tag. `v1.0.0` is stage 9's release, the one `module-rust` then requires.
|
|
|
|
## Contributing
|
|
|
|
See [CONTRIBUTING.md](CONTRIBUTING.md) — including the AI-disclosure rule — and report security
|
|
problems privately as [SECURITY.md](SECURITY.md) describes.
|
|
|
|
## License
|
|
|
|
GPL-3.0-or-later — see [LICENSE.md](LICENSE.md).
|