feat: stage 3, the /rnpc commands in game #5

wtclaude · 2026-09-30T08:19:02Z

wtclaude commented

2026-09-30 08:19:02 +00:00

What

This is stage 3 of docs/runicnpc/PLAN.md: every verb of §5 as /rnpc <verb> in chat and rnpc.<verb> in a console, behind runicnpc.place and runicnpc.admin (admin includes place; the server console has both).

place / here take key=value options in any order (D242): count= respawn= mode=each|group move=wander|monument|route:<name> radius=. A placement made in game is named <profile>-<n> (D241), and rename renames it; the live NPCs keep their placement and move their owner with it.
remove [placement], near, info (the NPC you look at), profiles, tp, respawn <placement|all>, clear <owner>, and rnpc.profile create|show|set|delete for a standalone server. The last is console only, and is refused while the website manages profiles (D221).
path record / point / undo / save [loop|back] / cancel / list / delete (D240). Nothing is drawn on screen.
D239: a roamer may stand on a player-built floor, and the answer warns that it is one.

Behaviour the tests forced

Rust leaves an NPC standing in the air when its floor is destroyed. I measured this for 15 s; it never fell. The brain now checks every 2 s, and a roamer more than 2 m above the nearest navmesh is warped onto it. It was on the ground 2 s after the floor went. A placement whose spot is off the mesh at respawn spawns on the nearest navmesh (the placement's note says so) and returns to its spot once the floor is rebuilt.
path point refuses a point an NPC cannot walk to from the previous one, using Rust's own path query, and save loop refuses a loop that cannot close. The first test route climbed a hill a player can walk, and its first point sat on a navmesh island on a rock top: the patrol never moved.
RunicNpc_SetPlacement now refuses a roamer off the navmesh, as the command does. API.md is updated; the API stays at 2, which has not been released.
A fix to stage 2: Pos.V and Profile.IsSentry were being written into every JSON file and API answer. They are [JsonIgnore] now.
Rust's console args are StringView[] in the current build, so the console verbs read each one through GetString.

One addition for your call

The server console has no position, so there place, here and path point accept at=x,y,z (and yaw=). This is also how the harness drives them. In game, these options are refused.

Tested

The harness gains cmd (57 checks) and floor (7), including the chat path driven as a stand-in player: nothing happens without the permission, and here and remove work once it is granted.

	Oxide	Carbon
`rnt.run all` (stage 2's groups + cmd + floor)	134/134	134/134
RunicNPC reload → `rnt.after`	5/5	5/5
`server.save` + restart → `rnt.after`	5/5	5/5

node scripts/checkPlugin.js and its tests pass. Both rigs are cleaned: the harness and its data are removed, and RunicNPC's data is restored to empty and unmanaged. This build stays loaded, and the rnhrevolver test kit is still in Kits for the walk.

Still to do: the in-game walk, which needs a player. The checklist is in the docs PR (PLAN.md stage 3).

Checklist

AI-assisted: written with Claude Code (Claude Opus 5.5); the commit carries the trailer.

🤖 Generated with Claude Code

https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

## What This is stage 3 of `docs/runicnpc/PLAN.md`: every verb of §5 as `/rnpc <verb>` in chat and `rnpc.<verb>` in a console, behind `runicnpc.place` and `runicnpc.admin` (admin includes place; the server console has both). - **`place` / `here`** take `key=value` options in any order (D242): `count= respawn= mode=each|group move=wander|monument|route:<name> radius=`. A placement made in game is named `<profile>-<n>` (D241), and `rename` renames it; the live NPCs keep their placement and move their owner with it. - **`remove [placement]`, `near`, `info`** (the NPC you look at), **`profiles`, `tp`, `respawn <placement|all>`, `clear <owner>`**, and **`rnpc.profile create|show|set|delete`** for a standalone server. The last is console only, and is refused while the website manages profiles (D221). - **`path record / point / undo / save [loop|back] / cancel / list / delete`** (D240). Nothing is drawn on screen. - **D239:** a roamer may stand on a player-built floor, and the answer warns that it is one. ## Behaviour the tests forced - **Rust leaves an NPC standing in the air when its floor is destroyed.** I measured this for 15 s; it never fell. The brain now checks every 2 s, and a roamer more than 2 m above the nearest navmesh is warped onto it. It was on the ground 2 s after the floor went. A placement whose spot is off the mesh at respawn spawns on the nearest navmesh (the placement's `note` says so) and returns to its spot once the floor is rebuilt. - **`path point` refuses a point an NPC cannot walk to from the previous one**, using Rust's own path query, and `save loop` refuses a loop that cannot close. The first test route climbed a hill a player can walk, and its first point sat on a navmesh island on a rock top: the patrol never moved. - **`RunicNpc_SetPlacement` now refuses a roamer off the navmesh**, as the command does. API.md is updated; the API stays at 2, which has not been released. - **A fix to stage 2:** `Pos.V` and `Profile.IsSentry` were being written into every JSON file and API answer. They are `[JsonIgnore]` now. - Rust's console args are `StringView[]` in the current build, so the console verbs read each one through `GetString`. ## One addition for your call The server console has no position, so there `place`, `here` and `path point` accept `at=x,y,z` (and `yaw=`). This is also how the harness drives them. In game, these options are refused. ## Tested The harness gains `cmd` (57 checks) and `floor` (7), including the chat path driven as a stand-in player: nothing happens without the permission, and `here` and `remove` work once it is granted. | | Oxide | Carbon | |---|---|---| | `rnt.run all` (stage 2's groups + cmd + floor) | 134/134 | 134/134 | | RunicNPC reload → `rnt.after` | 5/5 | 5/5 | | `server.save` + restart → `rnt.after` | 5/5 | 5/5 | `node scripts/checkPlugin.js` and its tests pass. Both rigs are cleaned: the harness and its data are removed, and RunicNPC's data is restored to empty and unmanaged. This build stays loaded, and the `rnhrevolver` test kit is still in Kits for the walk. **Still to do: the in-game walk**, which needs a player. The checklist is in the docs PR (PLAN.md stage 3). ## Checklist - [x] AI-assisted: written with Claude Code (Claude Opus 5.5); the commit carries the trailer. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

wtclaude added 1 commit 2026-09-30 08:19:03 +00:00

feat: stage 3, the /rnpc commands in game

PR Checks / plugin-checks (pull_request) Successful in 7s

Details

0a57d783ca

The chat command /rnpc and the same verbs as rnpc.<verb> in a console
(PLAN.md §5), behind runicnpc.place and runicnpc.admin:

- place / here with key=value options in any order (D242); placements
  made in game are named <profile>-<n> and renamable (D241).
- remove, rename, near, info (the NPC you look at), profiles, tp,
  respawn, clear, and rnpc.profile create|show|set|delete for a
  standalone server (refused while the site manages profiles, D221).
- path record / point / undo / save [loop|back] / cancel / list /
  delete (D240). A point an NPC cannot walk to from the last one is
  refused, as is a loop that cannot close: Rust's path query says so.
- A roamer may stand on a player-built floor, with a warning (D239).
  If the floor is destroyed under a live NPC, Rust leaves it standing
  in the air, so the brain puts it on the nearest navmesh within 2 s;
  a placement whose spot is off the mesh respawns on the nearest.
- The API's SetPlacement now refuses a roamer off the navmesh, as the
  command does; placements report a note while they fall back.
- Pos.V and Profile.IsSentry no longer leak into the JSON files.

The harness gains the cmd and floor groups. Both rigs: 134/134 in one
rnt.run all, rnpc reload 5/5, server restart 5/5.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

whitlocktech merged commit 9c366ab5b5 into edge

2026-09-30 08:20:18 +00:00

whitlocktech deleted branch feat/stage-3-in-game

2026-09-30 08:20:19 +00:00

whitlocktech referenced this issue from a commit

2026-09-30 08:20:20 +00:00

Merge pull request 'feat: stage 3, the /rnpc commands in game' (#5) from feat/stage-3-in-game into edge

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/runicnpc-rust#5