Commit Graph

54 Commits

Author SHA1 Message Date
ef9596ce67 docs(bridge): EventsEnabled's comment says what it gates today
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 9s
The doc comment on PluginConfig.EventsEnabled still said it "gates
taking a lease only", which stopped being true at protocol 9 when it
began gating every world write (D94). It now lists what the switch
gates as of protocol 14 - a lease, every world write (zones, crates,
NPCs, world calls, Dangerous Treasures, Guarded Crate, raid bases,
console commands), a tally and a run's chat line, and paying coins -
what always works with it off, and that the website can set it without
a reload. Comment only; no behaviour change.

Found while writing the runicgateway.com Rust docs (its PLAN.md §16,
phase 15).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-22 15:29:34 -05:00
38f854d580 fix(bridge): the last fixes' bridge half (W3, W9, W12)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 14s
Stage 3 of docs/modules/rust/PLAN_LAST_FIXES.md.

- W3: a Travelling Vendor call while one is on the map answers world.error
  reason `already-out` instead of "called 1" with nothing spawned. Not
  counted against the run's budget and not kept under its key, so a retry
  looks again. Module-Rust#55 reads it as called 0.
- W9: a rolled-back RaidableBases profile write carries RaidableBases' own
  log entry for the file (its path and the exception's message, without the
  stack), read from the log since the write began, instead of the last 8 KB
  of the server log. Its other entries since the write stand in when none
  names the profile, and nothing when it said nothing.
- W12: raid.ended carries the base's id, and its runId and key, when a run
  made it, as PROTOCOL §20.12 says. A teardown takes the base off the record
  before its despawn raises Ended, so the live base keeps its run and key too.

No protocol change: W3's reason is a new value of an existing field, and W12
sends the fields PROTOCOL already lists.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-21 13:59:10 -05:00
e0d6c46850 feat(bridge): RaidableBases — raid.* events, raid.spawn, the raids helper (PLAN_REDESIGNS §11.4)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 11s
PLAN_REDESIGNS §11.4 (D202-D208, D386-D390), protocol 14. Spec: docs
rust-link/PROTOCOL.md §20.12.

- RunicGatewayRaids.cs, the raids helper (D168, D204-D207, D387), shipped
  beside the bridge and released with it. Harmony patches on RaidableBases'
  spawn queue Add, OpenEvent and each base's BypassUseOwners(): a run's base
  is tagged at birth, its PvP/NPCs/despawn/lock set on a member-by-member copy
  of its profile (Setup, NPC and DespawnOptions copied again, so the shared
  profile is never touched), PvP also set on the base after OpenEvent; a spot
  checked (own look, then the plugin's area check with its reason, rocks and
  cliffs a warning; then the ocean level, D388, D389) and pasted; one base
  despawned; profiles reloaded under watch. Both editions, every member found
  by name. rgr.status.
- Hello's integrations.raidableBases: edition, the paid spawn call (looked
  for by name, D348), CopyPaste, the plugin's own difficulties (D386), the
  helper, and with it the grid and the profiles.
- raid.started / raid.completed / raid.ended / raid.purchased / raid.locked
  from the lifecycle hooks; the unload trap's completions (no owner, no
  raiders) are neither sent nor counted. The tally's raidsCompleted (Warlord).
- map.live's raids layer, kept by the hooks and seeded from GetAllEvents().
- raid.spawn: with the helper the base is a world registry entry, so
  world.revert / world.owned / world.expired serve it (never-started after
  15 min, raidablebases-unloaded); without it the paid call or rbevent, not
  the run's. raid.check for the editor's advice (D208, D391).
- RaidableBases' profiles in the configuration editor (D205): a virtual
  @data/RaidableBases/Profiles/ path, all-profiles-or-none writes, reloaded by
  the helper and rolled back when a profile does not load.

Compiled on both rigs (Rust 25902425, Oxide 2.0.7830, Carbon 2.0.262) and
driven on both rigs with the paid 3.2.2 and the tier-3 pack through a
throwaway plugin: the pick and spot routes with every setting, a repeat key,
revert, expiry, and a good and a broken profile edit.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-16 19:29:02 -05:00
5104e0dbcd feat(bridge): keep a step's teardown with its key — teardownOf (D385)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 9s
Core records nothing for a step that failed or whose answer was lost, and
then reverts it with only the key: no server, no teardown. So a run request
now carries its `teardown`, stored in the key's record and never run with
it, and `{ key, teardownOf }` runs the teardown stored under `teardownOf`,
under its own key, at most once:

- only when something there may have run (some commands ran, or a reload
  cut the run off); otherwise answered with nothing run and nothing kept;
- `busy` while the run it is for is still going;
- a reward carries no teardown (refused `malformed`), and a teardown takes
  no placeholders.

Re-compiled and driven on both rigs (a failed run's teardown ran once, a
repeat ran nothing, nothing-ran and unknown keys ran nothing); rigs
restored to the protocol-13 bridge.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-16 02:36:49 -05:00
b52b8a8f80 feat(bridge): console commands as event steps — command.run (PLAN_REDESIGNS §16)
A `command.run` frame (protocol 14, PROTOCOL.md §20.11) runs the console
commands a step's author typed: once, or once per online recipient with
{steamid} and {name} filled in (the name quoted the way the game's own
BuildCommand quotes an argument). D382-D384: no allowlist; offline
recipients are skipped and named.

- At most once per key: the key is written to commands-run.json before
  anything runs; a repeat answers from the record, a repeat while running
  joins the running job, a record a reload interrupted answers
  `interrupted`. Kept 7 days, at most 500 records.
- Spread over frames: whole recipients per frame, up to 30 commands or 8 ms.
- unknown-command: ConsoleSystem.Run returns null both for an unknown command
  and for one that replies nothing, so the run listens to Unity's log for the
  game's own "Command '...' not found" line while each command runs (spiked
  on Oxide 2.0.7830 and Carbon 2.0.262, Rust 25902425). The same capture is
  the reply when Run returns nothing.
- rg.world shows commandKeys and commandsRunning.

Compiled on both rigs and driven through a throwaway plugin (repeat key,
unknown command, offline recipients, malformed requests); rigs restored to
the protocol-13 bridge.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-16 02:30:59 -05:00
454ce53937 feat(bridge): ZLevels Remastered in hello (PLAN_REDESIGNS §14.3.6)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in -2m7s
Stage 7 of the §14.3 integration plan (D374): hello's integrations gains
zLevels { loaded, version }, sent again when ZLevels loads or unloads,
and rg.world prints zLevels=. No level is read or sent; its XP boosts
are permissions a run already lends.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-15 18:27:54 -05:00
4e83def0dd feat(bridge): Guarded Crate on protocol 14 (PLAN_REDESIGNS §14.3.5)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 9s
Stage 6 of the §14.3 integration plan. Spec: docs rust-link/PROTOCOL.md §20.9.

- gc.started, gc.ended (the clearer, or nobody) and gc.failed from Guarded
  Crate's three hooks; the start's key joins exactly, inside the call.
- gc.place { key, event, location as a world call } runs `<command> position
  <event> x,y,z`; refuses npcspawn-missing itself, since Guarded Crate's
  `position` does not check and the crate would land unguarded (D364).
- The running set is checked against Guarded Crate's private list (by
  reflection): the hotload seed, `stop all` (no hook), and which event ended.
- Hello's integrations.guardedCrate with npcSpawn and the events from its data
  file; the tally's guardedWon (Warden); map.live's guarded rows; rg.world.
- Guarded Crate's cargo plane no longer says airdrop.called.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-15 12:26:36 -05:00
72f51c3d9e feat(bridge): Dangerous Treasures on protocol 14 (PLAN_REDESIGNS §14.3.4)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 14s
Stage 5 of the §14.3 integration plan (docs rust-link/PROTOCOL.md §20.8).

- Three events from DT's own hooks: dt.started { x, z, key? },
  dt.won { steamId, name, invaders (max 32), invaderCount, x, z } and
  dt.ended { x, z }. None while the world is not live; a win still counts.
- The start hook fires inside the call that opens the chest, so the key a
  dt.start is running joins its start exactly, not by a ten-second window.
- dt.start { key, level 0-2 } runs `dtevent <level>` through
  ConsoleSystem.Run and answers dt.opened { key, level, repeat, x, z }. A key
  already answered is answered again and opens nothing (kept seven days in
  dt-starts.json). Refusals: malformed, bad-level, dt-missing,
  console-unavailable (D363), dt-not-ready (nothing opened, DT's own "Manual
  Event Failed" reply, under fifteen minutes since DT loaded, D365),
  dt-no-spot (after), refused (anything else DT said).
- The tally gains treasuresWon (Treasure Hunter, D375); map.live's world gains
  kind "treasure" for each running chest, seeded at load from DT's chests in
  the world (DT has no API that lists them).
- Hello's integrations gain dangerousTreasures, sent again on DT's load and
  unload. rg.world prints dangerousTreasures, treasures, dtStarts and
  dtWarmingUp. README lists Dangerous Treasures.

checkPlugin: 81 hooks, every one void and listed; 18 tests. Compiled and
loaded on both rigs (Rust 25902425, Oxide 2.0.7830, Carbon 2.0.262);
rg.world read dangerousTreasures=False treasures=0, then both went back on
the protocol-13 bridge.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-15 06:45:25 -05:00
7c9c8bdacb feat(bridge): Dynamic PVP's zones on protocol 14 (PLAN_REDESIGNS §14.3.3)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in -2m8s
Stage 4 of the §14.3 integration plan, specified in docs
rust-link/PROTOCOL.md §20.7 and §17.3.

- pvp.zone.created { zoneId, event, x, z, radius, shape, durationSec } from
  OnCreatedDynamicPVP, and pvp.zone.deleted { zoneId, event } from
  OnDeletedDynamicPVP. Neither is sent while the world is not live.
- Size and place come from ZoneManager: a sphere's Radius, or half a cube's
  longer side (cargo's zone is a cube); the position is the zone's transform,
  so cargo's moves with the ship.
- map.live gains a `pvp` layer of the live zones, kept by the two hooks and
  seeded from Dynamic PVP's own AllDynamicPVPZones / GetEventName at world
  ready and when it loads; a zone ZoneManager no longer holds is dropped.
- hello's integrations.dynamicPvp, sent again when it loads or unloads;
  rg.world prints dynamicPvp= and pvpZones=; both hooks join rg.hooks.
- The bridge never makes, maps or erases one of Dynamic PVP's zones.

Compiled and loaded on both rigs (Rust 25902425, Oxide 2.0.7830, Carbon
2.0.262).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-15 06:12:05 -05:00
491760d817 feat(bridge): TruePVE in a zone on protocol 14 (PLAN_REDESIGNS §14.3.2)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 10s
Stage 3 of the §14.3 integration plan (D362, D368), specified in docs
rust-link/PROTOCOL.md §20.6.

- world.zone's optional truePve: {"exclude": true} or {"ruleset": "name"},
  exactly one, the name 1-64 characters. Malformed is `malformed`; TruePVE
  not loaded is `truepve-missing`.
- All or nothing: the zone (and its dome) is made, then AddOrUpdateMapping.
  A false erases both and answers `truepve-ruleset` with the name (or
  `refused` for exclude).
- The registry entry remembers its mapping, and every path that erases one
  of our zones calls RemoveMapping first: the deadline, world.revert, a zone
  world.owned finds gone, a new wipe. While TruePVE is away the id waits in
  data/RunicGateway/truepve.json, flushed at OnPluginLoaded(TruePVE) and at
  the bridge's own load.
- hello's integrations.truePve { loaded, version }, sent again when TruePVE
  loads or unloads. rg.world prints truePve= and truePveLeftover=.

Compiled and loaded on both rigs (Rust 25902425, Oxide 2.0.7830, Carbon
2.0.262, TruePVE 2.4.6).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-15 05:47:58 -05:00
8fdc374ab3 feat: TruePVE in the zone step (PLAN_REDESIGNS §14.3.2, WIP)
Stage 3 of the §14.3 integration plan (D362, D368): world.zone's optional
truePve ({exclude: true} or {ruleset}), all or nothing, unmapped on every
path that erases one of our zones, with truepve.json for erases while
TruePVE is away. Docs and PRs still to come.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-15 03:03:30 -05:00
adb9df6a2e feat(bridge): Rust's own world events on protocol 14 (PLAN_REDESIGNS §14.3.1)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in -1m55s
Stage 1 of the §14.3 integration plan: the patrol helicopter, Bradley, the
cargo ship, the Chinook, airdrops, locked crates, the Travelling Vendor, the
satellite and the Deep Sea, with no plugin (D349).

- `world.event`, one frame kind whose `event` names which of 24 types
  (PROTOCOL.md §20.5). The type is in `event`, never `type`: `type` is the
  envelope's, and the rig's sidecar dropped every world event as untyped when
  the plan's example put it there. Nothing is said before the world loads or
  while the server quits. Positions are x/z; the site works out the grid.
- Credit (D372, D379): a damage table for the patrol helicopter, the Chinook
  and Bradley; `heli.downed`, `chinook.downed` and `bradley.destroyed` carry
  every candidate (blow, last, most, damagers) and the plugin credits nobody.
  D174's `CreditVehicle` and the tally's apcKills/heliKills are gone.
- Locked crates told positively (oil rigs, cargo, ghost ship, a Chinook drop
  joined at the crate's landing); anything else says nothing. A Bradley's
  `where` comes from the game's spawners, not `RoadSpawned` (which defaults to
  true). `airdrop.called` comes from the cargo plane's spawn: `supply.call`
  raised neither OnAirdrop nor OnCargoPlaneSignaled.
- The tally gains cratesHacked and dropsLooted (Safecracker, Scavenger, D356).
- `world.call` (D354, D367, D378): one of a schedule's TriggeredEvents at
  random, without Trigger (which would reset its clock); satellite.random for
  the satellite. A position for the airdrop (InitDropPosition) and the patrol
  helicopter (SetInitialDestination) only, both set before the spawn, as the
  stage-1 spike measured (0-1 m and 10-54 m). Kept; the key is remembered seven
  days in world-calls.json; EventsMaxWorldCalls (default and ceiling 10) per run.
- Hello/status `console.plugins` (D363): the bridge runs its own rg.probe
  through ConsoleSystem.Run from a timer. Carbon 2.0.262 refuses plugin
  commands only inside a console command (or a NextTick one queued), which is
  how §14.2's spike tested; from a timer, and from the link reader's NextTick,
  it finds them. Reads true on both rigs.
- checkPlugin.js: the probe must name a [ConsoleCommand] the plugin declares.

Compiled and loaded on both rigs (Rust 25902425, Oxide 2.0.7830, Carbon
2.0.262); heli.arrived, cargo.arrived and airdrop.called read back from each
rig's sidecar store. Rigs restored. 18 check tests pass.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-15 00:39:00 -05:00
e3dc918400 feat(bridge): Backpacks on protocol 14 — read a backpack (PLAN_REDESIGNS §11.3)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 23s
WhiteThunder's Backpacks as an optional integration (D199), as §11.3.2 designs it.
Read, never write (R2):

- hello/status `integrations.backpacks` adds `sizes`: the N of every registered
  backpacks.size.N, ascending (dynamic-size profiles left out). Hello is resent
  when Backpacks loads or unloads.
- `backpacks.read {steamId}`: API_ReadBackpackContentsAsJson, and only when that
  answered a backpack, API_GetBackpackCapacityById — the backpack is loaded by
  then, so the capacity follows a later grant (§11.3.1's trap). Each stack is
  reduced to slot, shortname, display (the game's English name, D340), amount,
  skin and name when set; a blueprint carries its target as `blueprint` (D341);
  contents one level deep; `overflow` past the capacity. `pageSize` is
  Backpacks' "Max size per page" from its config, cached by mtime.
- Refusals: backpacks-missing, bad-id, unreadable.

The bigger backpack an event lends is a backpacks.size.N permission pushed by
perm.sync (D337), so it needs no code here. Still protocol 14 (D332).

Compiled on both rigs (Rust changeset 167584; Oxide 2.0.7826, Carbon 2.0.262),
then restored to the bridge they ran before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-12 14:35:54 -05:00
66fbbd6b57 feat(bridge): Economics on protocol 14 — pay, balances, adjust (PLAN_REDESIGNS §11.2)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 10s
Wulf's Economics as an optional integration (D199), as §11.2.2 designs it:

- hello/status `integrations.economics` adds startingBalance and wipesWithMap,
  read from Economics.json (cached by mtime) because its API has neither.
- `economics.pay`: coins from an event step, kept once paid (D335). One main-
  thread call for the list; each deposit measured as after - before, since
  Deposit answers true while rounding and clamping (`at-limit` otherwise).
  The key and its reply are kept in data/RunicGateway/payments.json for seven
  days, so a retry answers `repeat: true` and pays nobody. The optional
  message ({amount} = what landed) is told now if awake, else on wake.
- `economics.balances` (bounded by PermMaxOps) and staff `economics.adjust`
  (deposit / withdraw / set; a withdrawal above the balance is refused
  `insufficient` with the balance).
- `player.tally` gains `balance`, a value: read at connect (D336) and from
  OnEconomicsBalanceUpdated, offline players included.
- `economics.wiped` from OnEconomicsDataWiped(IPlayer), with `newSave`.

Amounts are boxed as double and only Steam ids are sent, per the spike.
Compiled on both rigs (Oxide 2.0.7826, Carbon 2.0.262), then restored.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-12 06:56:46 -05:00
6952fbf123 feat(bridge): protocol 14 — kits.uses and reward notices (PLAN_REDESIGNS §2)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 9s
Opens protocol 14 (D332):
- kits.uses {kit, steamIds} -> {kit, max, cooldown, asked, exhausted,
  onCooldown}: counts only, bounded by the sync's own bound (§2.6).
- perm.sync notices [{key, steamId, message, delivery}] (D333): the site's
  whole untold set. Told at once to a player who is awake, else on
  OnPlayerSleepEnded; popup where PopupNotifications is loaded and chosen,
  chat otherwise. Told keys persist in notices.json until the site stops
  sending them; the report lists noticesTold.

ProtocolVersion and overlay.toml 13 -> 14; OnPlayerSleepEnded joins
ExpectedHooks (checkPlugin: 55 hooks, all void).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-12 02:15:23 -05:00
e5f04e0c0c fix(bridge): Rust's animals and heals count toward titles again (runicnpc 9d)
- Animal kills: Rust's animals are now Rust.Ai.Gen2.BaseNPC2 (stag, boar, wolf,
  bears, big cats, crocodile, farm animals, critters, sea life), not BaseNpc, so
  no animal kill counted as an animal or an NPC kill. They count as both again;
  ScientistNPC2, the one person among them, counts as a human NPC kill.
- Heals: OnHealingItemUse is (tool, fromPlayer, toTarget). The bridge took two
  parameters, received the healer as the target, and dropped every heal as
  healing yourself. It now reads the target, and one act of help (a syringe
  revive raises both hooks, the heal first) counts once whichever hook comes
  first.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-07 13:41:57 -05:00
3117b0c349 feat(bridge): every NPC an event places needs RunicNPC (runicnpc stage 9, D310)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 6s
world.place of one of Rust's own NPC prefabs now needs RunicNPC loaded and
answering RunicNpcApiNeeded, as a profile placement does, so a module that
missed the hello cannot place NPCs on a server the site calls incomplete. The
refusal comes before anything spawns, with the existing reasons
runicnpc-missing and runicnpc-old; a profile placement now also refuses an old
RunicNPC up front (it was refused only when it carried orders). Crates are
unaffected. No message changes shape; protocol stays 13.

overlay.toml's runicnpc_api comment and rg.npc's line say RunicNPC is required.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-06 16:58:30 -05:00
74bcb0f895 feat(bridge): map.live names RunicNPC's NPCs, marks bosses and adds (runicnpc stage 8)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 11s
One RunicNpc_List per map.live ask, joined to the ledger by net id
(D302, D303):

- A ledgered NPC's row gains its name and the step key that placed it.
  A boss's row also gains `boss` and its `health` (0-1); the health is
  for the event page's progress line.
- A RunicNPC NPC owned by a run that no step ledgered is a boss's add.
  It joins the events layer under that run with `add: true`.
- Any other boss joins the world layer as `kind: "boss"` with its name.
- A placement's ordinary NPCs are not sent.

Protocol 13, still unreleased; the fields are additive.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-06 08:23:10 -05:00
1df3db57d3 feat(bridge): a Place NPCs step's "drop loot" switch (runicnpc stage 7)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 8s
world.place with a profile takes dropLoot (D296): false spawns the
NPCs with RunicNPC's {"loot":{"dropTable":false}} override, so they
keep their corpse's start but roll no table. Absent or true, as before.
runicnpc_api and RunicNpcApiNeeded are 6.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-05 22:36:29 -05:00
90f403422a feat(bridge): boss frames for the site's public triggers (runicnpc stage 6)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 8s
npc.boss.spawned, npc.boss.phase and npc.boss.died, from RunicNPC
API 5's boss hooks, for the site's spawned, phase and killed triggers
(D277). The death frame names the killer and counts the players who
hurt the boss; npc.died still carries every contributor.

A profile's `boss` and `use` blocks travel in the push unchanged.
runicnpc_api and RunicNpcApiNeeded are 5.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-05 10:48:28 -05:00
cf26b05abc feat(bridge): the faction table and an event's escort, ally and tether (runicnpc stage 5)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 19s
- npc.profiles answers with RunicNPC's faction table, and npc.profiles.set
  pushes one beside the profiles (RunicNpc_SetFactions), set first so the
  profiles are checked against it; a refused table comes back as
  factionsRefused and the old one is kept (D254);
- world.place with a profile takes escort (a Steam id; the player must be
  on, else escort-offline), ally ({kind: clan|player, id}) and tether (the
  run's own zone that holds the point, else no-zone), and gives each NPC
  its orders through RunicNpc_Escort, _Ally and _Tether. All or nothing:
  an order RunicNPC refuses removes every NPC the step placed (D269, D270,
  D272);
- the RunicNPC API the bridge needs is 4 (overlay.toml runicnpc_api = 4).

Compiled on the Oxide rig.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-01 07:58:16 -05:00
742e18ba0a feat(bridge): RunicNPC, the site's NPC profiles and placements (runicnpc stage 4)
Protocol 13 gains npc.profiles, npc.profiles.set, npc.placements and
npc.placement (add, set, remove, rename, respawn), each calling RunicNPC's
API 3; the frames npc.died, npc.health and npc.placement.changed from its
hooks; runicNpc in the integrations body; world.place with a profile; the
killfeed's attackerNpc and attackerProfile; and the tally's
npcProfileKills. rg.npc reports it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-30 04:21:50 -05:00
f7d5b4d691 Merge edge into feat/title-conditions: §3's zones and domes
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 6s
One conflict, ExpectedHooks: both phases' hooks are kept (48, all void).
Compiled and loaded on both rigs.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-29 11:34:26 -05:00
b30c6edd59 feat(bridge): a dome without a type is the full dome (D212)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 7s
ZoneDomes' Standard type is its one whole dome; the four colours show only
where they meet the ground or a building. Walked on both rigs 2026-09-29.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-29 09:42:17 -05:00
746523387e feat(bridge): a zone's ZoneManager options, its messages, and a ZoneDomes dome (PLAN_REDESIGNS §3)
world.zone gains flags, settings, enterMessage, leaveMessage, delivery,
format and dome (PROTOCOL §19.11). Flags are checked against the live
ZoneManager's own list, read through its API call ZoneFieldListRaw() (D211),
and refused bad-option rather than dropped; settings are an allowlist of
five with bounds. Both are kept on the registry entry and re-applied when
a zone is re-created.

The bridge says a zone's enter and leave messages itself (D193), as chat
or a popup (chat when PopupNotifications is missing), and stays quiet for
5 s after re-creating a zone.

RunicGatewayDomes.cs, a new helper, patches ZoneDomes so its API can be
called without a player, and raises OnRgDomesReady after ZoneDomes' own
start; the bridge puts its domes back only after it, so none is drawn
twice. Domes are removed before their zone at expiry and revert.

hello carries zoneManager { version, flags }, integrations.zoneDomes the
ZoneDomes and helper state, and hello is sent again when ZoneManager,
ZoneDomes or either helper loads or unloads. The release ships the new
helper beside the zone helper.

Not compiled or walked on a rig: the panel's file API was down on both.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-29 05:25:43 -05:00
f67f9e3b22 fix(bridge): the three members the rig corrected — crafter owner, mission assignee, heal target
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in -1m28s
Compiled on both rigs (2026-09-29): ItemCraftTask has no owner, so the crafter is ItemCrafter.owner; OnMissionSucceeded credits its third argument, the assignee, since MissionInstance has no accessor for it; OnHealingItemUse takes its target as object, because GiveEffectsTo now takes an IMedicalToolTarget, and counts only a player. GameObject.ToBaseEntity is not in scope for a plugin, so OnEntityBuilt asks GetComponent<BuildingBlock>().

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-29 02:07:29 -05:00
ff49f8f6ed feat(bridge): count the twenty-three chat-title conditions in player.tally (PLAN_REDESIGNS §5)
player.tally gains animalKills, weaponKills (by the killfeed's weapon
prefab name), headshots, bestPvpM/bestPveM (this interval's maximum),
apcKills, heliKills, crafted (by item category), built, repaired, healed,
rockets, explosives and missions. Every field is absent when nothing moved.

Ten new void hooks, all in ExpectedHooks: OnEntityTakeDamage (the last
player to hurt an APC or helicopter, for a crash that names nobody),
OnItemCraftFinished, OnEntityBuilt, OnStructureRepair (counted only when
the health rose by the next tick), OnHealingItemUse and OnPlayerRevive
(another player only; a syringe revive counts once), OnRocketLaunched,
OnExplosiveThrown/Dropped (a damaging TimedExplosive only) and
OnMissionSucceeded.

npcKills keeps counting animals too, so the public column does not change
meaning mid-wipe; the site takes human NPCs as the difference (D209).
WeaponOf and DistanceOf are split out of DescribeAttacker so the killfeed
and the tally read one name and one distance.

Not yet compiled on a rig: the rigs' storage is unmounted.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-28 23:32:58 -05:00
8b4b65249f feat(bridge): read the whole permission store (perm.inventory), and sync group parents
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 9s
The permission manager (PLAN_REDESIGNS section 1, D160): the site owns every
permission and group on the server, so the bridge now reads all of it.

- perm.inventory: every registered permission with the plugin that
  registered it (PermissionExists(name, plugin), public on both
  frameworks), every group with title, rank, parent and permissions,
  every holder's direct permissions and groups (not default), and the
  pairs event leases hold. Built a slice per tick, sent in pages under
  the 1 MiB line cap, paged from one snapshot. rg.inventory logs it.
- perm.sync sets an existing group's title and rank and every group's
  parent; an absent title or rank means "leave it" (the adopt policy's
  hold). The managed list and the foreign scan are gone: the site reads
  the store and decides.

Walked on both rigs: Oxide 85 permissions all owned, Carbon 104 with its
30 adminmodule.* unowned; ZoneManager owns ignoreflag.nokits.

Refs RunicGateway/Module-Rust#21

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-28 06:58:39 -05:00
586ad7ceba fix(bridge): protocol 13 step 2 — expiry, gathering, raids, plugin loads, and a ZoneManager helper (F1 F3 F4 F8 F12 F13)
The bridge's half of PLAN_FIXES §6 step 2 (decisions D181-D185, docs#288).

- F13: `world.expired` carries the entity's kind as `what`. It used to write
  it over the frame's own `kind`, so every expiry left filed as "zone".
- F1 (D159): `gathered` also counts OnDispenserBonus (the final-hit bonus),
  OnCollectiblePickup (hemp, mushrooms, stones off the ground) and
  OnGrowableGathered (farmed plants); all three are void and in ExpectedHooks.
- F3: taking down a building block you own, or one on a cupboard you are
  authorised on, no longer counts toward `structures`. The frame still goes.
- F4: every remaining UserIDString is SteamIdOf(userID), so a player another
  plugin spawned is never `steamId: null`.
- F8 (D184): `plugin.loaded` / `plugin.unloaded`, once the world is ready,
  with the permissions that plugin added or removed (a diff of the registered
  list, taken a tick after the hook).
- F12 (D181, D182): RunicGatewayZones.cs, a D168 helper shipped beside the
  bridge, Harmony-postfixes ZoneManager's Zone.InitializeZone and, a tick
  later, enters every connected player ZoneManager's own IsPositionInZone
  places inside, through ZoneManager's own OnPlayerEnterZone. Without it (or
  when it cannot find what it patches) the bridge scores its zones by
  IsPositionInZone. Hello reports `zoneHelper: { state, version?, reason? }`.
- release.yml stages every helper beside the bridge and lists each .cs with
  its sha256 in manifest.files; the installer and the egg place them all.

Not yet compiled: this is walked on both rigs before it merges.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-26 21:36:04 -05:00
616f4fbca8 fix(bridge): protocol 13 — a configuration reload that works on Carbon (W1-W5)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 9s
The step-1 rig walk (PLAYER_WALK configuration 2, 2b, 4 on both rigs) found:

- W3: Carbon's Oxide-compatible ReloadPlugin is not a reload. One call unloaded
  Kits and never compiled it again; the next did nothing. Carbon now reloads
  with `c.reload` on the server console (ConsoleSystem.Run), as an operator
  would at the panel. Oxide keeps ReloadPlugin, falling back to `oxide.reload`.
- W4: Carbon's log is carbon/logs/Carbon.Core.log, with no *.txt in the
  directory at all, so the log evidence never fired on Carbon. Chosen by name.
- W5: Carbon loads a plugin whose LoadConfig threw and raises Loaded in the
  same instant. OnPluginLoaded is now noted, and the job settles on the first
  log read a poll after it. Carbon's "Failed ILoadConfig" is on the word list.
- W2: Oxide's "Could not initialize plugin 'Kits v4.4.9' (JsonReaderException:
  ...)" is on the word list, so the outcome quotes the exception.
- W1: Oxide's idle compiler shutdown drops a queued reload with "Timed out
  waiting for plugin to be compiled: X". The reload is asked for once more;
  a second give-up settles at once by what is loaded.

rg.config prints the log file it follows (log=).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-26 20:21:06 -05:00
042727e5fe fix(bridge): protocol 13 opens — UTF-8 from the site, a reload that fails on evidence (F15, F9, F10)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 20s
F15: the read loop cast each byte to a char, decoding the site's UTF-8 as
Latin-1, so every non-ASCII announcement, title, kit name and saved config
file arrived mangled. Lines are now split as bytes and decoded whole, which
keeps a character that straddles two reads intact.

F9/F10 (D177, D178): config.write answers at once with pending, writeId and
ceilingMs, and the outcome follows as a config.outcome event. A pending
reload reads the framework log each second and rolls back the moment the
target fails to compile or initialise; a slow compile is waited for, under
a 30 s ceiling per phase. At the ceiling the plugin looks at what is loaded
before restoring anything, and a rollback waits for the restore's own
reload so the outcome says whether the plugin is back.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-26 17:04:41 -05:00
3e928bb2f6 fix(bridge): a backoff that holds against a sidecar that refuses (D155)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in -1m38s
The reconnect backoff waited on `Wake`, which `Emit` signals on every
frame, so it lasted only until the next hook fired. That was invisible
while a failed connect was silent; against a sidecar that now refuses a
plugin naming another server (D155) the phase 18 walk measured some 250
redials a second, each printing two console lines and rebuilding the
boards. It now waits on `_stopping`, the handle that already exists so a
CONNECT is not abandoned by `Emit`; Unload still ends the wait at once.

The backoff also resets only after a link has held for 10 s
(StableLinkMs). A connection closed on arrival used to reset it to 500 ms
on every accept, so a refusal loop never backed off at all.

Walked: a plugin aimed at another server's sidecar is refused every 5 s
(the ceiling), not continuously; a stable link whose sidecar restarts is
back in 0.49 s, as before; no Unload stall on reload.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-26 01:19:23 -05:00
04491e70af fix(bridge): read the config before the link thread dials (D154)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in -1m29s
Init() started LinkLoop before Loaded() read the config, so the thread's
first dial saw _config == null and used the 7799 fallback on both Oxide and
Carbon. One server per host made that its own sidecar by coincidence. With
two on a host (the installer's named instances, phase 18), the second
server dialled the FIRST server's sidecar, sat in its accept backlog, and
the moment the first server's plugin reloaded that sidecar took the second
server's connection: the website showed server "alpha" with beta's
hostname and wipe.

LoadConfigValues() now runs in Init() before the thread starts; Loaded()
keeps its log line and the lease/world/reward loads.

Walked on the phase 18 rig: three instances (two Oxide, one Carbon 7801),
each now dials its own port.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-26 01:07:41 -05:00
497b7c4f64 feat(bridge): server id from the environment, and the first release workflow (phase 18)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in -1m35s
Module-rust phase 18, step 3 of docs/modules/rust/PLAN.md §34.2.7.

The environment seam (D150): when the plugin writes its default config and
RUSTLINK_SERVER_ID holds a valid id (the site's ^[a-z0-9][a-z0-9-]{0,63}$),
the file's ServerId is that value. It is read nowhere else: after that write
the file is canonical and the site's lock applies. An invalid value is logged
and ignored. This is how the egg names a server; not a message change, so the
protocol stays at 12.

The release (D145, §34.2.1): release.yml reuses servuo-plugins' release engine
unchanged (tag-only, secrets preflighted, orphan tags recovered and swept, the
installer's bundle.yml dispatched at the end). The adapter re-runs
checkPlugin.js and packages runicgateway-rust-plugin-<version>.tar.gz with a
framework-neutral layout: RunicGateway.cs, its [Info] version stamped to the
release, and a manifest.json folding in overlay.toml.

overlay.toml gains min_carbon_version = "2.0.259", the build R19 was proven on.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-25 22:54:38 -05:00
5ff88610a5 fix(bridge): keep the chat titles across a reload (D144)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 22s
The walk found that a hot reload of this plugin emptied every title, and
the site never re-sent them: it re-sends on a new boot id or wipe id, and a
reload is neither, because the boot id names the server process. The set
is now written to titles.json with the wipe it was pushed on, and read at
OnServerInitialized only when that wipe is still the current one.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-25 18:23:28 -05:00
8c6146259e feat(bridge): protocol 12 — BetterChat and popups (phase 17)
- titles.set: a whole set of chat titles, swapped in by reference and read
  by a BetterChat third-party title getter (one lookup, no socket). The
  getter is registered at load and again whenever BetterChat loads.
- perm.sync: a group may carry its BetterChat style. Each field is written
  through API_SetGroupField only when the game still holds what the site
  last pushed (or BetterChat's default); anything else is reported as
  drift. One `chat group set` per touched group saves it, because the API
  never does (D143). A retired style removes the group with `chat group
  remove` (D139). The report gains `chat`.
- chat.say: delivery chat|popup and an optional voice format. A popup with
  PopupNotifications absent is refused `popup-unavailable`. Every line said
  is logged, since the game logs neither a broadcast nor a popup.
- server.hello/status carry `integrations`; `rg.titles [steamId]` prints
  what BetterChat would render for a player.
- overlay.toml: protocol 12; PopupNotifications leaves requires_plugins
  (D141).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-25 17:48:05 -05:00
ef78da8ce6 fix(bridge): rg.map re-reads the picture rather than printing the last answer
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in -1m35s
The walk emptied the Rust+ cache and rg.map still said `companion`: it
printed the picture the last map.info had seen. It now re-reads while the
world is ready.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-25 06:31:42 -05:00
de5f0928bd fix(bridge): map.live names a player by userID, not UserIDString
The phase 14 walk read `steamId: null` for every sleeper made on the
server: UserIDString is a cached string the game fills for a player it has
seen connect. An id the map cannot name is an own dot and a clan mate the
site can never match, so the map reads the id from userID itself.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-25 01:05:51 -05:00
210c35f904 feat(bridge): protocol 11 — the map (phase 14)
Four verbs (PLAN.md §30.2), all outside EventsEnabled because none of them
changes the world:

- map.info: the map key, the picture's source (the Rust+ cache, a render
  kept on disk, or none), its size, SHA-256 and slice count, the game's own
  grid, and the monuments the in-game map shows. The cache is read by
  reflection by name only, never enumerated (it holds the Rust+ secret).
  The hash is computed on the thread pool.
- map.fetch: one 512 KiB base64 slice, encoded on the thread pool, refused
  `stale` when the key or hash moved.
- map.render: the admin fallback (D109). Answers `accepted` at once and
  renders on a later frame, keeping the result in data/RunicGateway/map.jpg
  beside its key so a restart within the map does not render again.
- map.live: every layer at once (world events, event-owned zones/crates/NPCs,
  players and sleepers, TCs and player vending machines as positions only).
  The sets are kept by OnEntitySpawned/OnEntityKill and seeded by one sweep
  at OnServerInitialized. MapMaxSleepers/MapMaxBases bound the two layers.

Also fixes Grid() (D119): it used a 146.3 m cell, but the game fits whole
cells to the world (20 x 150 m on a 3000 map), so rows could be one off.
It now asks MapHelper.PositionToString, the in-game map's own labeller.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-25 00:33:51 -05:00
3d9998ce64 feat(bridge): protocol 10 — the tally, kit credits and chat (phase 13b)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 10s
- tally.open / .snapshot / .close: a run's participation tally, persisted
  in tallies.json. Presence accrues every 5 s from ZoneManager's own
  membership (or the whole server); kills are the last hit, gated by
  killsOf and the killer being inside the area (D98); the score is
  seconds, kills, or minutes + killWeight x kills (D99). Only a zone this
  run opened counts (D100). Gated by EventsEnabled (D107); forgotten
  seven days after opening (D108).
- kits.list: the kit source, from Kits' GetKitNames/GetKitInfo.
- perm.sync `credits`: one extra use of a kit per reward (D103), held in
  credits.json and spent LAST from OnKitRedeemed, because Kits'
  SetPlayerKitUses does nothing for a player with no usage record.
  Withdrawn when unredeemed; reset when Kits wipes its use counts.
- chat.say: one line to the server, remembered by key for 10 minutes.
- EventsMaxRecipients / EventsMaxTallies / EventsMaxChat bounds.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-24 07:00:44 -05:00
0a7ad570f7 fix(bridge): refuse world commands until the world has loaded
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in -1m29s
The link starts in Init, before the save loads. The phase 13a walk restarted
the rig mid-run: the website saw the new boot id at once, asked world.owned
into an empty world, and the plugin — finding no entity behind any net id —
pruned three live crates from its own registry. They stayed in the world,
owned by nothing, and a revert would have refused them.

world.owned, world.revert, world.monuments and every world write now answer
`not-ready` until OnServerInitialized, zones are not re-created before it,
and server.hello carries `worldReady` so the website can hold its reconcile
until the world it would be asking about exists.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-24 02:16:03 -05:00
bbaa7f346e feat(bridge): protocol 9 — the world verbs events place and give back (phase 13a)
world.monuments, world.zone, world.place, world.revert and world.owned
(PLAN.md §28, D86-D96):

- Zones through ZoneManager's temporary zones, owned by the bridge, with a
  required duration the plugin enforces itself (D96) and re-created from the
  bridge's own registry on every load and every ZoneManager reload (D92),
  because ZoneManager erases a plugin's zones when that plugin unloads.
- Crates and NPCs from a plugin-held allowlist (D88) at a monument by kind
  and instance, or at raw coordinates (D87, D93), bounded 25/20 per step (D95).
- A registry file keyed by the website's idempotency key, since this bridge
  has no at-most-once store: a repeat answers with the first call's ids.
- world.owned LOOKS by net id: crates survive a restart, NPCs do not, so a
  boot id proves nothing. A wipe drops the registry whole.
- EventsEnabled gates every world write; revert, owned and monuments never
  (D94). Revert refuses only a thing that exists and is not this run's.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-24 01:22:06 -05:00
c106ba826b fix(bridge): grant with a null owner and read every grant back (D85)
EnsureGrant and EnsureGroupPermission passed `this` as the owner. Given an
owner, Oxide first asks PermissionExists(perm, owner) — whether THAT plugin
registered the name — and returns silently when it did not, so every
site-authored grant of another plugin's permission was a no-op on Oxide that
the report counted as applied (PLAN.md §27.6).

Both now pass null and read the store back. A grant the store does not hold
afterwards is reported in the new `notLanded` list instead of counted.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-24 00:37:45 -05:00
594fc09141 feat(bridge): protocol 8 — the leases (PLAN.md §27)
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 20s
lease.list / lease.apply / lease.release and a lease.expired event. The plugin holds the allowlist (decay.scale, 18 populations, the two minimum spawn scalars, and group permissions), the seven-day ceiling (refused, never clamped) and the deadline, which it enforces on its own. Release is compare-and-set. Holds persist in the data directory with their boot: a restart ends a convar hold, while a group-permission hold survives it and is re-armed.

EventsEnabled (default off) gates apply only, and a write from the site's config editor now takes effect at once. The permission mirror defers to a leased pair: it is reported as leased, never foreign.

Grants pass a null owner: with an owner, Oxide silently refuses any permission another plugin registered.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-23 21:14:00 -05:00
77e9863e9b fix(bridge): the raid frame's attackerId comes from userID
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 9s
UserIDString is filled in only when a player connects, loads as a
sleeper, or is an engine bot. A player another plugin spawned has none,
and the phase-10 walk's raid arrived with attackerId null. The website
skips the raid alert when the attacker is authorised on the cupboard,
so a null would quietly defeat that exclusion.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-23 13:37:05 -05:00
272e9e0f65 feat(bridge): clan.disbanded carries the roster it ended
The website tells a disbanded clan's members, but the clan board that
follows the event (and, after an outage, precedes the backlog) has
already removed that roster from its store. The game walks Members to
drop each membership and never empties the list, so it is still whole
when OnClanDisbanded fires. Part of protocol 7.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-23 05:55:52 -05:00
a3899f336f feat(bridge): protocol 7 — a raid frame that names who lives there
entity.destroyed now covers doors, external walls and gates, and the
tool cupboard itself as well as building blocks. A door was never a
BuildingBlock, so a door-only raid reached nobody. The frame gains
`structure`, the cupboard's `buildingId`, and `authorized`: each Steam
id on the cupboard with whether they are online now, bounded at 64.
Both fields are absent when there is no cupboard. The structures tally
still counts building blocks only, so the leaderboard column keeps its
meaning.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-23 05:51:59 -05:00
568fc873b3 feat(bridge): protocol 6 — first-party clans, one board and five events
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 12s
The `clans` board carries every clan the game will list, with its roster
and roles, plus the facts the website needs to trust it: enabled,
backend, supported, truncated, and whether the optional uMod Clans
plugin is loaded. It is re-sent on connect and on the 60-second cadence,
and a few seconds after any membership change. The five events are
clan.created, clan.disbanded, clan.member.added, clan.member.left and
clan.member.kicked.

What the game's assemblies dictated:
- The game has no enumerate-all call. The clan leaderboard is the only
  listing, and the game clamps it to 100 clans. A board at that ceiling
  says `truncated`, as does one that would not fit in 768 KiB (the
  sidecar drops lines over 1 MiB).
- The local backend is synchronous behind ValueTask. A task that has not
  completed means another backend (Nexus), which is refused with a reason
  rather than waited on from the main thread.
- A clan id is not an identity, so every frame carries createdMs.
- OnClanMemberAdded hands over a bare id before the game's cache
  refreshes, so the clan is read back, with a fallback to the id alone.
- uMod Clans raises OnClanDisbanded(string, List<ulong>), which has the
  same name and arity as the game's hook, so the bridge types it exactly.

A member's LastSeen is never sent: it is presence (PLAN.md §23).
overlay.toml moves to protocol 6 and drops Clans from requires_plugins
(D47): Teams come from the game's own clans.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-09-23 05:14:18 -05:00
48eeb56300 feat(bridge): protocol 5 — configuration from the site, and the reload that undoes itself
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 10s
R18. Three request/reply verbs — `config.list`, `config.read`, `config.write` —
and the first command on this bridge that writes to the game host's filesystem.

The walk is rooted at `Interface.Oxide.ConfigDirectory`, never a literal, so it
is right on Oxide, on Carbon and on a server whose operator moved it; the data
directory is never walked, because it holds live state and both frameworks'
permission stores, which is protocol 4's mirror one directory over.

A write is resolved, version-checked and parse-checked before the first byte
lands, then backed up, written and reloaded — and the reload is WATCHED. If
`OnPluginLoaded` does not arrive within four seconds the whole set is restored,
reloaded again, and reported with the tail of the newest log file. Without that
this is a web form that takes a required plugin off a production server one typo
at a time.

Four seconds is arithmetic, not taste: the worst path is two windows while a
caller holds the sidecar's ten-second RPC budget.

This plugin will not reload itself — the reload would close the link carrying
the answer — and the site composes the file's bytes, so nothing here has an
opinion about content beyond "it parses".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMH6bw1jXMgbyF3ZWGEzSM
2026-09-22 08:53:45 -05:00
e041089080 feat(bridge): protocol 4 — the permission mirror, and the first command that writes
All checks were successful
PR Checks / plugin-checks (pull_request) Successful in 8s
R2, the game half. The website is the author of record for groups and grants;
this plugin makes the framework's own permission store match what it is sent.

**One verb, and the plugin does the diffing (D32).** `perm.sync` carries the
whole set the site authors for this server. The plugin compares it against the
live store and writes only what differs, then answers with a report: what it
applied, what was already right, the names it could not resolve, the memberships
waiting on a first connection, and every holder the site did not author.
`perm.catalogue` is the other half — a live read of what the loaded plugins have
registered, which is the option source the authoring form is built from.

**The first command whose work is unbounded, so it is drained rather than run.**
A community with two thousand linked players sends thousands of operations in one
frame, and applying them in the tick the frame arrives is a freeze an operator
will blame on the game. A sync compiles into a list of single-store operations
and drains two hundred at a time on a timer. That is §5's rule — nothing the far
side sends may cost the main thread an unbounded amount of work — applied to the
inbound half for the first time.

**The pre-check §12.2 rule 1 exists for.** `GrantUserPermission` returns void,
throws nothing and logs nothing for a name no plugin registered, so every grant
naming an unloaded plugin's permission would disappear without a trace. The plugin
checks `PermissionExists` first and reports the name as unresolved; it does NOT
register the name itself (D33), because that fabricates a permission the operator
never installed.

**`UserHasPermission` cannot answer the question the diff asks.** It is true for a
member of a group that carries the permission, so a direct grant would look
already applied the moment a group covered it — and a revoke already done.
`GetPermissionUsers` reads the user's own set, which is what a direct grant is.

Six permission hooks join the read path, all void, all in `ExpectedHooks`. They
are not the drift record — only the site's desired set can say whether a change is
foreign — they are a reason to reconcile sooner, and they are suppressed while
this plugin is writing, or every sync would announce itself as drift.

`rg.perms` reports the last report from the console, which is the fastest way to
tell "no plugin registered that name" from "the store has never seen that player".

Protocol bumped to 4 here and in overlay.toml, in the same change as the emitters.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMH6bw1jXMgbyF3ZWGEzSM
2026-09-21 18:27:08 -05:00