> ## Documentation Index
> Fetch the complete documentation index at: https://docs.marioded.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Record gameplay

> Capture gameplay, choose who owns the recording, and understand the save result.

# Record gameplay

**Install on:** the gameplay server · **Command:** `/reverserecorder` · **Permission:** `reverse.admin`

Use the recorder to capture the world where a match happens. Start with a named recording, stop it when the scene is finished, and wait for the saved replay ID.

```text theme={null}
/reverserecorder start --name "Arena final"
/reverserecorder stop
```

## How a recording starts

Install the recorder on the gameplay server. A recording starts through `/reverserecorder start` or an API call from another plugin. Reverse does not automatically know when your minigame starts or ends: integrate those match lifecycle events using the [recording API](https://docs.marioded.com/api/recording.md).

Each session has its own UUID, start tick, owner list, event stream, and terrain identity. Recording the same world twice creates separate recordings rather than overwriting the first one.

## Capture scope

The command records the current world. API integrations can additionally specify:

* A spatial bounding box, to isolate an arena within a larger world.
* A set of participant UUIDs, to select players without using ownership as a capture filter.
* Independent concurrent sessions in one world.

In the API, `participantIds: null` selects all in-scope players; an empty set selects no players. Nonplayer entities are selected spatially rather than by that UUID set. Bounds and participant selection are immutable session settings, not fields persisted in the replay. The command uses whole-world capture with all in-scope players.

> [!NOTE]
>
> **Owners are viewers, not a capture filter.** Add owners to grant access to the finished replay. Use the API's participant selection when you need to choose which players are recorded.

Bounded capture and participant selection are API features; there are no corresponding command flags in the current recorder command.

## Initial scene and terrain

Reverse saves the starting scene along with the recorded actions. The chunk capture radius defaults to 4. Only terrain currently loaded by the server can be captured; Reverse does not generate a whole world for the recording.

What this means in practice:

* Start while the relevant arena chunks are loaded.
* Test the scene you expect a viewer to see, including locations away from players.
* Raising the radius cannot recover terrain that was never loaded or captured.
* A spatially bounded recording can still contain full-height chunk payloads for horizontally intersecting columns.

See [terrain](https://docs.marioded.com/owners/terrain.md) for the separation between initial chunks and timeline block changes.

## Templates

Use `--template arena` only when `arena` is a template that the playback terrain provider can serve. An explicit template bypasses runtime terrain capture and points the recording at that template's terrain identifier.

Template names are trimmed; blank means no template. They are not inferred from the live world's name. Do not add `template:` or `slime:` prefixes. For SWM, make the exact template available through a configured loader on the replay server too.

Changing template terrain later changes the base scene available to replays that reference it. Treat published templates as versioned assets operationally, for example `arena-season-2`, rather than overwriting a template name used by old replays.

## Clips

A recording retains its complete event history from tick zero, so **any** live session can export a clip. There is no recording-mode switch or rolling-buffer window. A **clip** is a standalone replay of the last N seconds or a chosen interval, exported while the source session keeps recording:

```text theme={null}
/reverserecorder clip 10
/reverserecorder clip 10 --name "Ace" --description "Point-winning play"
/reverserecorder clip --from 30 --to 45
/reverserecorder clip --to 10
```

`clip 10` above captures the last 10 seconds, or all available history if the recording is younger. `--from` and `--to` bound an explicit interval instead, in whole seconds from the start of the recording: `--to 10` alone captures from the start through second 10, `--from 30 --to 45` captures seconds 30 through 45, and `--from 30` alone runs from second 30 to now. Both interval endpoints are inclusive and clamp to the current tick; a start beyond the current tick selects that final tick alone. Negative bounds, reversed intervals, and nonpositive durations are rejected.

The interval command form acts on your own session; only the duration form exposes an optional session id after its duration. Give either the duration or at least one of `--from`/`--to`, never both. The export cutoff is frozen when requested, and the source recording keeps running.

`--name` and `--description` rename the exported replay. Either flag may be omitted, and the omitted field is copied from the source session's own text, so a clip that supplies neither carries the recording's name and description unchanged. Both are validated exactly like `start`.

A clip is a normal replay: it gets its own replay UUID, rebases its first retained tick to zero, and includes the durable entity/block state already present before that interval. It copies the available base terrain under its own terrain identifier, including when the source used a template. A successful terrain copy therefore survives the source's stop or deletion without depending on the source template. Content-addressed payloads may still be deduplicated by storage. Terrain-copy failures produce a degraded clip; event-save failures fail the export.

Game plugins can use the [recording API](https://docs.marioded.com/api/recording.md) to export recent or explicit intervals from a specific live session.

## Saving and failure outcomes

`stop` unregisters the live session and saves asynchronously. Every normal stop saves the complete recorded event stream, even if clips were exported earlier. Clips do not trim that history or replace the final full replay.

There are three important outcomes:

| Outcome | What it means |
| - | - |
| Saved | Events and usable terrain/template reference are available. |
| Degraded | Events were saved, but terrain capture/finalization failed. The replay may load without its base world. |
| Save failed | Event persistence failed; do not advertise the recording as available. |

Remember: the "stopped" message is not the same as "saved". Match integrations should publish a "watch replay" link only after save completion, and handle degraded terrain explicitly.

## Supported content and practical limits

Recordings include supported player/entity movement, equipment and animations, block changes, chat, and visual effects. The exact result depends on your game and supported Minecraft version.

Sounds are **not** captured automatically. Reverse never inspects clientbound sound packets, because such a packet does not reveal whether the sound was emitted for the whole world or for one player. Your integration declares world sounds explicitly through `recordWorldSound`/`recordSessionSound`, which means only the sounds you declare end up in the replay, and sounds sent to a single player are never recorded by the plugin.

Reverse is not a video recorder. Custom plugin screens, resource-pack animations, and vanilla sounds the server emits on its own may not appear in a replay. Make a short test recording of your game's important mechanics before relying on it for match reviews.

## Recommended match workflow

1. Load/prepare the arena.
2. Determine participant UUIDs and replay owners separately.
3. Start recording before the first meaningful game event.
4. Store the returned session ID in your match object.
5. Stop that exact session on match end, cancellation, and plugin shutdown paths.
6. Wait for save completion before exposing the replay ID.
7. Keep failure logs with the replay ID for support.

## Next steps

* [Find every recorder command](https://docs.marioded.com/owners/commands.md).
* [Watch and control a saved replay](https://docs.marioded.com/owners/player.md).
* [Start recordings automatically from your minigame](https://docs.marioded.com/api/recording.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.