RunicNpc_AddPlacement creates a placement and names it as /rnpc place does (D241, D246). A position without y is a map point: it is put on the ground there (terrain and rock, never a building or a tree, D245), then checked against the navmesh like an in-game placement. It answers the id, the grounded position, whether the spot is player-built, and the cost warning, or the in-game refusal sentence. RunicNpc_RenamePlacement and RunicNpc_RespawnPlacement do what rnpc rename and rnpc respawn do. OnRunicNpcPlacementChanged(id, change, previous) is raised on every set, remove and rename, from the API or in game, so the bridge can tell the site at once. rnpc place and here now share CreatePlacement with the API, so both give the same refusals. The test harness gains an api3 group; all 157 checks pass on the Oxide and Carbon rigs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
51 lines
2.9 KiB
TOML
51 lines
2.9 KiB
TOML
# Release metadata for RunicNPC.
|
|
#
|
|
# Consumed by the release workflow, which folds these values into the
|
|
# manifest.json shipped inside the release tarball. The Runic Gateway installer
|
|
# and the Pterodactyl egg read that manifest to decide what they are placing
|
|
# (docs/runicnpc/PLAN.md D224), and the bridge will read the same `api` at hello
|
|
# (stage 4).
|
|
#
|
|
# There is deliberately NO version key here. The release version is derived from
|
|
# git tags and conventional commits by the release workflow, so there is no bump
|
|
# commit to keep in sync and no way for this file to disagree with the tag.
|
|
|
|
# ── The API version other plugins call ───────────────────────────────────────
|
|
#
|
|
# The number a caller of `RunicNpc_*` relies on (PLAN.md §4). It MUST equal
|
|
# `ApiVersion` in plugin/RunicNPC.cs; `node scripts/checkPlugin.js` holds the two
|
|
# equal on every pull request. It moves when a call or a raised hook changes
|
|
# shape, not on every release.
|
|
#
|
|
# The plugin answers this at run time through `RunicNpc_ApiVersion()`, but only
|
|
# once a server has booted with it loaded — too late for an installer to refuse
|
|
# a RunicNPC too old for the bridge it is pairing with. Declaring it here is what
|
|
# lets a bundle check the pair BEFORE an operator installs it.
|
|
#
|
|
# 1 was stage 0's: `RunicNpc_ApiVersion()` and nothing else.
|
|
# 2 was stage 2's whole API, PLAN.md §4.
|
|
# Current: 3 — stage 4 (D249): RunicNpc_AddPlacement, _RenamePlacement, _RespawnPlacement and the
|
|
# OnRunicNpcPlacementChanged hook, documented in docs/runicnpc/API.md.
|
|
api = 3
|
|
|
|
# ── Framework floors ─────────────────────────────────────────────────────────
|
|
#
|
|
# The same file runs on Oxide and Carbon; the installer and the egg decide
|
|
# whether it lands in `oxide/plugins/` or `carbon/plugins/`. These are the builds
|
|
# it is known good on — the two rigs it was loaded on — not a measured minimum.
|
|
# (The bridge's Oxide floor is older, 2.0.7585; RunicNPC has never run on that.)
|
|
min_oxide_version = "2.0.7726"
|
|
min_carbon_version = "2.0.259"
|
|
|
|
# ── Plugins it cannot load without ───────────────────────────────────────────
|
|
#
|
|
# Kits is how every RunicNPC NPC is equipped, and it is required (D217). The
|
|
# plugin says so itself with `// Requires: Kits`, which stops either framework
|
|
# loading it without Kits; this list is the same fact for the installer's
|
|
# `doctor`, which reports a missing one rather than installing it. The PR check
|
|
# holds this list and the plugin's `// Requires:` lines equal.
|
|
#
|
|
# ZoneManager is NOT listed: a zone tether is optional (PLAN.md §6), and a
|
|
# profile that asks for one on a server without it is refused when it is saved.
|
|
requires_plugins = ["Kits"]
|