Keep Reverse running smoothly
Start with the short checklist below. The later sections explain what needs a restart, what affects performance, and what information helps when a problem occurs.Your routine checklist
- Check save failures and degraded-terrain warnings, not just command success messages.
- Monitor free disk space or database size, heap use, server tick performance, and backend latency.
- Keep role jars and API integrations on matching builds.
- Verify that gameplay, lobby, and player nodes actually use the intended storage backend.
- On networks, verify both replay-node heartbeats and real proxy transfers.
Reload versus restart
Use the role-specific commands for text, display, menus, open-access policy, and recorder radius. These update a selected subset of runtime state. They do not reconstruct SQL pools, switch the recordings folder, swap storage providers, rename an existing playback world, or reconnect availability using new settings. Perform a clean server restart for infrastructure changes. Do not use a generic plugin hot-reloader to unload and replace these runtimes while sessions, packet listeners, or downloads are active. Configuration preparation may reject invalid input. Correct the reported field, retain a backup of your previous working configuration, and reload again. Treat success as “the supported live settings were applied,” not “every YAML field now changed the running process.”Stop gracefully
For planned maintenance:- Prevent new matches/recordings and new viewing requests.
- Stop active recordings using their session IDs and wait for save completion.
- Stop playback sessions or allow them to finish.
- Stop the server cleanly.
- Back up the storage dataset before upgrades or backend changes.
Capture cost
Capture cost grows with loaded terrain, entities, activity, and the number of independent recording sessions. A radius ofr describes (2r+1)² horizontal chunk columns around a capture center, before overlap and actual chunk availability.
Ways to keep capture bounded:
- Use a dedicated arena world instead of a huge always-loaded lobby.
- Use recording bounds and participant sets through your minigame integration.
- Avoid unnecessarily large loaded areas before starting.
- Do not create duplicate sessions for the same match unless you need independent recordings.
Playback cost
Recordings take memory while being watched, and the loaded scene can be much larger than its saved file. Long or very busy recordings can make seeking slower. Test realistic matches before deciding how many simultaneous viewers your server can comfortably support. Every viewer in one session shares the playback cursor. Starting separate sessions gives independence but adds session state, scene resynchronization, and packet work. High speed can process more replay ticks per server tick and should be load-tested with realistic recordings.Database and cache tuning
Leave database connection limits at their defaults unless you are investigating a measured database bottleneck. Increasing them does not fix an unreachable database or incorrect settings. Cache count settings are not memory quotas. Increase loaded-replay caching cautiously; large event streams can dominate heap usage. There is no owner-facing setting promising an overall memory cap for the entire plugin.Access administration
Keepopen-access: false for private recordings and assign owners correctly at recording start. Enabling open access makes everyone a catalog administrator, including management actions offered by menus/commands.
Use separate test accounts for owners, nonowners, and administrators. Verify permissions on lobby and player independently; a permission granted on a gameplay server is not automatically synchronized to a replay server.