Samuel LisonandClaude Opus 4.8
2e7bd69c2c
Owner feedback: synced the engine into a fresh place, couldn't find the admin plugin. Root cause is a docs gap — nothing told the reader that a plugin is installed separately from a place sync. - admin-plugin.md: lead the Install section with the key distinction (it's a Studio editor tool, not place content, so an engine sync does NOT install it); add per-OS plugins-folder paths (macOS / Windows); spell out the restart-once / hot-reload-after behaviour; and note the form needs a place with the engine synced (else the empty state), incl. the restart-drops-unsaved-sync caveat. - getting-started.md: link Survival Stats + the admin plugin from Next steps, flagging that the plugin installs separately from the engine. - README: add a "Tuning, no code" pointer to the admin plugin from the front page. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
4.7 KiB
Survival Stats admin plugin
A small Studio plugin that gives the experience owner a friendly form to tune the survival
stats — instead of hand-editing Attributes on the SurvivalStatsConfig instance in the Explorer.
It's the first slice of the Builder / Admin plugin.
Install
This is a Studio editor tool, not game content — so syncing the engine does not install it. A Rojo sync (or the drop-in
SurvivorCore.rbxm) populates a place'sReplicatedStorage. The plugin is different: it lives in Studio's local plugins folder and runs in the editor across every place you open. You install it once, separately from any place.
Build it straight into your local plugins folder:
rojo build plugin.project.json --plugin SurvivorCoreStatAdmin.rbxm
The --plugin flag writes the built model into Studio's plugins folder for you:
| OS | Plugins folder |
|---|---|
| macOS | ~/Documents/Roblox/Plugins/ |
| Windows | %LOCALAPPDATA%\Roblox\Plugins\ |
(Prefer to place it by hand? Build to a file instead — rojo build plugin.project.json -o SurvivorCoreStatAdmin.rbxm — and drop it into that folder, or open it from Studio → Plugins tab
→ Plugins Folder.)
Then restart Studio — a brand-new plugin's toolbar only registers when Studio loads it. (After
this first install, re-running the --plugin build hot-reloads the plugin live, no restart needed.)
A SurvivorCore › Survival Stats button then appears on the Plugins ribbon tab; click it to
toggle the dock widget.
Open a place that has the engine in it. The plugin tunes the stats of whatever place is open, reading the live roster from
ReplicatedStorage.SurvivorCore— so sync the engine (or drop inSurvivorCore.rbxm) first. With no engine present it opens to an instructional empty state and writes nothing. Note that restarting Studio drops an unsaved Rojo-synced place, so reconnect Rojo and re-sync (or save the place before restarting) to bring the engine back.
Using it
Each stat shows the seven tunable fields, each displaying its effective value (your override if you've set one, otherwise the live engine default):
- Rate / second — how fast the stat drifts (the headline knob).
- Max, Start, Warn at % — range, spawn value, warning threshold.
- Display — whether it shows on the HUD.
- Icon — the HUD icon asset id.
- Value format —
fraction(99/100) ·percent·value·none.
Edit a field (type a number / click to toggle or cycle) and it's applied immediately. The dot at the left of a row is filled + blue when that field is overridden, hollow when it's following the engine default. Click the dot to reset the field. Every edit is a single undo step.
It reads the stat roster + defaults live from the engine in the place, so it always reflects the version you're running. With no engine synced it shows an instructional empty state and writes nothing.
Why your tuning is "locked" — it survives re-syncs and engine updates
This is the important part. The engine resolves each stat as engine default → Config.override →
the SurvivalStatsConfig instance (highest priority), and it only ever seeds that instance
when it's missing — it never overwrites it. The plugin builds on that with a deltas-only rule:
- It writes an attribute only when you change a field from the engine default.
- Resetting a field (or typing the default back in) removes the attribute, so the field goes back to following the engine default.
So two good things hold across a SurvivorCore update:
- Your explicit overrides are never lost — they live on your instance, which the engine never overwrites.
- Fields you didn't touch keep following engine defaults — so a future release that improves a default rate reaches your game, instead of being frozen at today's value.
The plugin can tune only the seven owner-facing fields above. It deliberately cannot touch
Invert or DangerHigh — those are engine-owned stat semantics (which way a bar fills / which end
is dangerous); the engine ignores them on the instance, and a guardrail in the plugin makes it
impossible to write them.
Caveat — the engine's own demo. In this repo's demo,
SurvivalStatsConfigis Rojo-mounted, so arojo servere-sync reverts plugin edits there. That's a demo artifact: a real game seeds the instance once (install-if-absent, not Rojo-managed), so the plugin's edits persist across engine updates — which is the whole point.
See also: Survival Stats + HUD · Design Language.