​

Watch replays

Install on: the viewing server · Command: /reverseplayer · Permission: reverse.player.use Use /reverseplayer (or /reverseplayer gui) to open the standalone catalog, choose a recording, and select Watch. If you already have its ID, use /reverseplayer play <replay-id>. Use /reverseplayer help for the compact command guide, with syntax and examples on hover. Saved-replay commands use full UUIDs. Open /reverseplayer gui for the catalog, or use /reverseplayer list [page]: each page shows ten named recordings with UTC dates, durations and Watch/Prepare command actions. If no recordings are accessible to you, the GUI stays closed and a message is shown. UUIDs are available in details and hover text, so you do not normally type them. Names need not be unique and are never resolved as identifiers. Integrations control an active viewing session using its separate playback session UUID.

​

Standalone and network mode

The player has two modes, chosen at startup:

• Standalone (default, networking disabled): the player creates its own catalog GUI. Players use /reverseplayer gui to browse or /reverseplayer play <replay-id> to start directly.
• Network mode (availability enabled): the player acts as a replay worker for lobby handoffs. Its standalone GUI is not initialized — send players through the lobby catalog instead. Switching modes requires a restart.

​

How the viewing world works

The player opens recordings in a dedicated viewing world, named replay by default. Viewers see the saved scene there; the original gameplay world does not need to be loaded on the replay server. Viewers are placed in creative flight and protected from ordinary movement through the void-world viewing logic. Their playback inventory/UI is temporary. On a normal stop or leave, the service restores their previous state, inventory, and position. Verify compatibility with inventory, flight, teleport, and scoreboard plugins on your server. The world name identifies the viewing world, not the recorded world’s terrain. Changing it does not repair a missing terrain index.

​

Default hotbar

Hotbar slots are numbered 1–9 in layout.yml. Default intervals are 1, 5, 10, and 30 seconds. Default speeds are 0.25×, 0.5×, 1×, 2×, 4×, and 8×. Customize these in display settings.

​

Sessions, viewers, and time

A playback session has one cursor, pause state, and speed. If an integration starts a session for several viewers, one viewer’s pause, resume, seek and speed controls affect the shared session. Leaving removes only the viewer choosing to leave. Starting separate sessions of the same recording gives independent playback. There are two duration concepts:

• Recorded duration: elapsed wall-clock time while recording.
• Playback timeline: ticks through the final recorded event.

A long recording with a quiet tail can finish playback earlier than its wall-clock duration. The progress display distinguishes these values. At speed 2×, two replay ticks advance for each server tick; this is relative to server tick performance, not a replacement wall-clock scheduler. At the end, playback pauses with the final scene and controls still visible. You are not automatically returned to the lobby. Resume with the hotbar or /reverseplayer resume to restart from tick 0 for everyone in the session. If you seek backward first, resuming continues from that position instead.

​

Seeking

Use seeking to jump to the scene at a particular moment. This does not change the original gameplay world. Jumping ahead does not play every sound and animation from the skipped time. Developers adding their own controls can follow the playback integration guide.

​

Recorded nametags

New recordings include scoreboard teams: player-name prefixes, suffixes, colors, nametag visibility, and membership changes. These are restored when seeking or restarting, including teams that existed when recording began. Legacy color-only prefixes are preserved; legacy clients receive bounded text compatible with their protocol limits. The recorder follows one fixed player’s team perspective, rather than mixing personalized teams sent to different players. Team packets sent before the recorder was injected cannot be reconstructed unless they also exist in the Bukkit scoreboard. Leaving removes replay teams and restores the viewer’s current Bukkit teams; packet-only nametag plugins may need to resend their own personalized teams.

​

Stopping and returning

/reverseplayer stop and the default Stop watching item remove only you, restoring your previous state. Other viewers keep watching; the session is cleaned up when the last viewer leaves. When you arrived through a lobby handoff, the player remembers your origin server and attempts a return transfer after restoring you. The origin must still be a valid proxy server name. Standalone viewers remain on the same server. Integrations should use leavePlayback(sessionId, viewer) for an explicit individual exit with lobby-return handling. leaveSession remains the callback-free path for quitting, switching replays and internal cleanup. The API’s stopPlaying still stops the entire session. Plugin shutdown restores viewers without requesting lobby transfers.

​

Diagnosing an incomplete scene

Use /reverseplayer resend to resend stored chunks for the session. If ground is still missing, check the recording’s terrain storage or template. Resending cannot manufacture chunks that were not saved. All saved chunks are sent once when you enter playback. Moving around, including while paused, does not send them again automatically. If the client discards terrain when you leave an area, returning is not guaranteed to restore it; use the explicit resend command.

​

Make it yours

• Change the hotbar, HUD, sidebar, and messages in Hotbar, HUD, and messages.
• Restyle the catalog and details menus in Catalog menus.