From e30b8c03911c05cf4db1b5121ac9f4b14f28b021 Mon Sep 17 00:00:00 2001 From: wtclaude Date: Mon, 5 Oct 2026 09:28:18 -0500 Subject: [PATCH] docs(runicnpc): stage 6 spike questions answered, D283-D284 D283: RunicNPC keeps "// Requires: Kits"; a Kits reload reloads it and its spawned NPCs are lost, so operators are told not to reload Kits during an event. D284: the four example kits are written only on the first install, behind a flag, and never restored or overwritten. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY --- runicnpc/PLAN.md | 46 +++++++++++++++++++++++----------------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/runicnpc/PLAN.md b/runicnpc/PLAN.md index cec5e98..7d9e5a2 100644 --- a/runicnpc/PLAN.md +++ b/runicnpc/PLAN.md @@ -10,7 +10,8 @@ design answered 2026-09-30** (D243–D252, §0), **built and walked 2026-09-30** design answered 2026-09-30 and 2026-10-01** (D253–D266, §0), **its spike measured 2026-10-01** on both rigs (§9), and **its build's own questions answered 2026-10-01** (D267–D272). **Stage 5 built and tested 2026-10-01, walked on the site 2026-10-05** on both rigs (§9); its API is [API.md](API.md) version 4. **Stage 6's design answered -2026-10-05** (D273–D282, §0). +2026-10-05** (D273–D282, §0), **its spike measured 2026-10-05** on both rigs, and **its two questions answered the +same day** (D283, D284, §9). RunicNPC is Runic Gateway's own NPC plugin for Rust servers, in its own repository, [`RunicGateway/runicnpc-rust`](https://gitea.whitlocktech.com/RunicGateway/runicnpc-rust). It runs on Oxide and @@ -102,6 +103,8 @@ architectural or design decision is implemented. | **D280** | **RunicNPC ships four example profiles, each with a kit that works on a fresh server:** a raider (roamer), a camp guard (guard), a sniper (sentry) and a boss (the "Juggernaut", with phases). Kits has no API that creates a kit, so **RunicNPC writes its example kits into Kits' own data file** and reloads Kits. Warden is not one of them (stage 6). | A profile with no kit wearing its Rust prefab's own gear (relaxing D217); item lists for the examples only; no examples; templates on the site that leave the kits to the admin. | | **D281** | **NPCs say no greet, hurt or kill lines.** A profile talks only through press E on a passive NPC (D278) and a boss's announcements (D277) (stage 6). | Lines on any profile; on passive NPCs and bosses only. | | **D282** | **Stage 6 is one stage, opening with a spike on both rigs, walked once end to end**, as stages 4 and 5 were (D248, D253) (stage 6). | 6a (bosses) and 6b (passive NPCs), each walked and merged before the next. | +| **D283** | **RunicNPC keeps `// Requires: Kits`.** A Kits reload reloads RunicNPC too, on both frameworks, and the NPCs it had spawned are lost (placements respawn; an event's do not). The operator documentation says not to reload Kits while an event runs (stage 6 spike, finding 6). | Kits still required, but checked in RunicNPC's own code, so its NPCs survive a Kits reload. | +| **D284** | **RunicNPC writes its four example kits only on its first install**, recorded by a flag in its data. A kit the admin deletes or edits is never brought back or overwritten. The kits are `rnpc_raider`, `rnpc_campguard`, `rnpc_sniper` and `rnpc_juggernaut`, each needing a permission nobody is granted (stage 6). | On every load, for any example kit that is missing; only on an admin's command. | **Borrowing, not copying.** NpcSpawn states no licence at all, so its source grants us nothing and is read only as a description of *what* can be done in Rust. HumanNPC is MIT on uMod, which is GPL-compatible, but §1.2 rules out its @@ -1213,30 +1216,27 @@ around it, each point snapped to the navmesh. - **One recovery trap on Carbon.** Unloading Kits and RunicNPC by hand with `c.unload`, then `c.load`, left both "requested for compilation" and never loaded. `c.reload` did the same. A restart of the server cleared it. -**What the answers leave open, for the org lead:** +**What the answers left open, and the org lead's answers (2026-10-05):** -1. **Should a Kits reload stop taking RunicNPC down?** For example: an event has placed 8 raiders, and an admin - edits a Kits kit and reloads Kits. Today all 8 vanish at once on both frameworks, and the event cannot get them - back. The choices: - - **Drop `// Requires: Kits` (proposed).** RunicNPC stays loaded through a Kits reload, and its NPCs keep the - gear they already have. For the 1–15 s that Kits is away, a spawn is refused with a warning. When Kits comes - back, RunicNPC checks the profiles' kits again. D217 still holds: with Kits not installed at all, RunicNPC - refuses every profile and says why. - - **Keep it**, and document "never reload Kits while an event runs". -2. **When are the example kits written (D280)?** For example: an admin installs RunicNPC, and its four kits are - written once and Kits reloads. Later the admin deletes `rnpc_raider`, or edits `rnpc_juggernaut`. What happens - at the next restart? - - **Only on the first install (proposed).** A flag in RunicNPC's data records that they were written, so a kit - the admin deleted stays deleted and an edit is never overwritten. - - **On every load, for any example kit that is missing.** - - **Only while the example profile that uses it still exists.** +1. **Should a Kits reload stop taking RunicNPC down? → D283: no. The `// Requires: Kits` line stays.** A Kits + reload keeps reloading RunicNPC on both frameworks. For example, an event has placed 8 raiders and an admin + reloads Kits: all 8 vanish, the event cannot get them back, and placements respawn about 5 s later. The + operator documentation (stage 9) says not to reload Kits while an event runs. + - The other choice was RunicNPC checking for Kits in its own code, which would have kept its NPCs through a + reload. +2. **When are the example kits written (D280)? → D284: only on the first install.** A flag in RunicNPC's data + records that they were written. A kit the admin later deletes stays deleted, and an edit is never overwritten. + - The other choices were every load (restoring any missing example kit), or only on an admin's command. - Proposed with it: - - the kits are named `rnpc_raider`, `rnpc_campguard`, `rnpc_sniper` and `rnpc_juggernaut`; - - they carry `RequiredPermission: runicnpc.examplekits`, which nobody is granted, so no player can claim one by - name (`IsHidden` alone does not stop that); - - on Oxide the one-time reload takes RunicNPC down and back once (finding 6) unless question 1 drops the - `Requires` line, so the kits are written before RunicNPC spawns anything. +What this adds to the build (D283, D284): + +- **The kits are named `rnpc_raider`, `rnpc_campguard`, `rnpc_sniper` and `rnpc_juggernaut`.** +- **Each carries `RequiredPermission: runicnpc.examplekits`**, which nobody is granted, so no player can claim one + by typing its name (`IsHidden` alone does not stop that). RunicNPC's `GiveKit` call ignores the permission. +- **The first install runs in this order:** write the kits, set the flag, reload Kits. + - Because of D283, the reload takes RunicNPC down and back once. + - On that second load the flag is already set, so nothing is written twice and nothing loops. + - RunicNPC writes the kits before it spawns anything, so no NPC is lost to that reload. **What this sets for the build, with nothing to decide:**