Data and Upgrades

Data, backups, and upgrades

Rivet stores generated state under plugins/Rivet/data/. These files belong to the plugin and are not routine settings.

Common data files

Files are created when a feature first has something to save.

File	Stored state
backpacks.yml	Up to 54 serialized item slots per player
breeders.yml	Breeder locations, animal type, food, eggs, experience, and counters
chat.yml	Persistent chat colors and social-spy state
daily.yml	Last claims and reward streaks
filters.yml	Pickup-filter mode, enabled state, and materials
graves.yml	Active graves, items, death locations, and /back timestamps
homes.yml	Named homes by player UUID
holograms.yml	Hologram definitions and properties
ignore.yml	Private-message ignore lists
kits.yml	Last kit use by player and kit
nicknames.yml	Persistent nicknames
notes.yml	Staff notes keyed by player UUID
permissions.yml	Local group assignments and direct grants
rtp.yml	Last successful RTP timestamps
spawn.yml	Rivet's server spawn
staff.yml	Persistent staff state, where enabled
teleports.yml	Shared successful-teleport cooldown timestamps
warps.yml	Public warp locations
worlds.yml	Tracked test-world names and types

Temporary session state, such as pending TPA requests, reply partners, active poses, vanish, flight, AFK reasons, boss bars, and toasts, is not persisted unless stated otherwise.

Safe editing

Stop the server before editing anything under data/. A running module may later save its in-memory state over a manual change.

Use spaces rather than tabs in YAML. Serialized Bukkit item sections are implementation data; change them only if you understand Paper's serialization format.

Save safety

Rivet avoids issuing valuable state before important saves complete. Examples include:

• graves are saved before normal death drops are cleared;
• grave claims are saved before items are returned;
• kit cooldowns are saved before kits are granted;
• daily claims are saved before rewards are issued;
• teleport cooldowns are written only after a successful teleport;
• hologram definitions keep the previous live state if saving fails.

Backups

A useful complete backup includes:

plugins/Rivet/
world/
world_nether/
world_the_end/
<tracked test worlds you want to preserve>

Back up while the server is stopped, or use a server-aware snapshot system that flushes plugin and world data first.

Automatic migrations

Migrations run before modules start. Supported old paths include:

Old location	Current location
chat.yml	settings/chat.yml
permissions/groups.yml	settings/permissions.yml
graves.yml	data/graves.yml
holograms.yml	data/holograms.yml
permissions/users.yml	data/permissions.yml

Old homes, warps, and auto-breeders sections in config.yml are copied to their data files. Existing destination values win.

Small gameplay settings formerly stored in settings/worlds.yml, a standalone settings/hoppers.yml, or a hoppers module switch are copied to settings/gameplay.yml. Legacy files and keys are deliberately left untouched for recovery, but the new grouped file becomes authoritative.

Missing module switches and missing settings keys are added without replacing existing values.

If both an old file and its new destination exist, Rivet uses the new file and leaves the old file untouched. The console reports the conflict.

Reload or restart

Use /rivet reload after ordinary settings changes. Restart after:

• changing modules.yml;
• editing generated data while the server was stopped;
• installing a new JAR;
• changing a setting whose feature is initialized only during startup.