> For the complete documentation index, see [llms.txt](https://docs.marioded.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.marioded.com/use-reverse/player.md).

# Watching replays

Open a recording, use the playback controls, and return to your normal player state.

**Install on:** the viewing server · **Command:** `/reverseplayer` · **Permission:** `reverse.player.use`

Open the standalone catalog, choose a recording, and select **Watch**. If you already have its ID, use `/reverseplayer play <replay-id>`.

## Standalone and network mode

With availability disabled at startup, the player creates its own catalog GUI. Players use `/reverseplayer` to browse or `/reverseplayer play <replay-id>` to start directly.

With availability enabled, the player is a replay worker for lobby handoffs. Its standalone GUI is not initialized. Send players through the lobby catalog; changing this mode requires restart.

{% hint style="info" %}
**Using a network lobby?** Open the catalog there with `/reverseview`. The player server handles the replay after the lobby transfers the viewer.
{% endhint %}

## 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`.

| Slot | Default control | Left click    | Right click    |
| ---- | --------------- | ------------- | -------------- |
| 1    | Pause/resume    | Toggle pause  | Toggle pause   |
| 3    | Backwards arrow | Seek backward | Cycle interval |
| 5    | Forward arrow   | Seek forward  | Cycle interval |
| 6    | Speed feather   | Faster        | Slower         |
| 9    | Stop            | Stop session  | Stop session   |

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](/configure-and-customize/display.md).

## 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 controls affect the shared session. 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.

## 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](/api-how-to-guides/playback.md).

## Stopping and returning

`/reverseplayer stop` and the default Stop item stop the session. When the viewer arrived through a lobby handoff, the player remembers the origin server and attempts a return transfer after playback cleanup. The origin must still be a valid proxy server name.

An integration that wants just one viewer to leave a shared session should use `leaveSession`, not stop the entire session.

## 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.

## Make it yours

{% content-ref url="/pages/EKseS6aOS6kFuyAf4SA5" %}
[Hotbar, HUD, and messages](/configure-and-customize/display.md)
{% endcontent-ref %}

{% content-ref url="/pages/10GSIQyrKslaVLkYSrh5" %}
[Catalog menus](/configure-and-customize/menus.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.marioded.com/use-reverse/player.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
