# Recording A recording is a per-tick snapshot stream of one player's state, saved to a single `.recap` file. --- ## What gets captured Every server tick the recorder writes: - **Movement** — position, rotation, velocity, on-ground flag. - **Pose & flags** — sneaking, sprinting, swimming, flying, on fire, invisible, glowing. - **Equipment** — main hand, off hand, 4 armor slots (delta-encoded). - **Full inventory** — all 41 slots (delta-encoded; only re-emitted when contents actually change). - **Combat events** — arm swing, item use, critical hits, enchanted-crit particles, damage taken, totem use, riptide. - **Block interactions** — place, break, mine progress, sign edits, container open/close. - **Vehicle** — enter / leave for any rideable entity. - **Sleeping** — bed enter / leave with position. - **Tracked mobs** — nearby entities within the surroundings radius: type, position, equipment, health, baby variant, variant data. Captured within `recording.capture-radius` (default 16 blocks) and overridable per-recording with `--radius <n>`. Set the radius to `0` for a player-only recording. - **Particles** — server-emitted particle packets. - **Captured packets** — allowlisted server→client packet types (sounds by default; plugins can add their own — see [[Recap/Developers/Packet Capture]]). - **Death** — vanilla death events. - **Player skin** — texture URL + signature stored once in the header so the NPC wears the same skin. - **Environment block changes** *(opt-in via `--environment`)* — world-driven block updates near the player such as pistons and redstone, so contraptions replay in sync. --- ## Starting a recording ``` /recap start <name> /recap start <name> @a ``` When recording multiple players, output files are named `<name>_<PlayerName>`. --- ## Flags | Flag | Shorthand | What it does | |---|---|---| | `--radius <n>` | `-r <n>` | Override the surroundings radius for this recording (default `recording.capture-radius`, 16; max 128): nearby mobs and a geometry snapshot cube. `--radius 0` makes it player-only. The cube replays viewer-only at the playback location. (World-driven block changes are a separate `--environment` opt-in; the radius scopes their range.) See [[Recap/Server Owners/Features/World Snapshots]]. | | `--scene <name>` | `-s <name>` | Auto-append each output recording to the named scene on stop. Scene must already exist. | | `--environment` | `--env` | Also record world-driven block changes near the player (pistons, redstone), **without** the mobs or snapshot cube of `--radius`. Default recordings stay player-driven. | | `--uncapped` | — | Lift the per-tick block-change limit for large/fast contraptions. Use with `--environment` or `--radius`. | Flags can combine in any order: ``` /recap start 300_fight @a --radius 32 -s big_battle ``` ### `--radius` example Recordings capture the player **and their surroundings** by default — every nearby mob and a cube of the surrounding scenery — out to `recording.capture-radius` (16 blocks). Widen it for a big arena: ``` /recap start arena_round1 --radius 24 ``` On playback the surroundings paint in client-side at the playback location, so an `arena_round1` recording made in one arena replays cleanly inside an empty one — no server blocks touched. Want just the player, no surroundings? Set the radius to `0`: ``` /recap start solo_clip --radius 0 ``` > Tip: bigger `n` = more blocks and mobs captured = larger files. The default 16 suits most scenes; only go higher (up to 128) for wide ones. To change the default for every recording, set `recording.capture-radius` in `config.yml`. --- ## Stopping ``` /recap stop # stop your own recording /recap stopall # stop every active recorder ``` Recordings save to `plugins/Recap/recordings/<name>.recap` immediately. --- ## Cancelling ``` /recap cancel # discard your in-flight recording /recap cancelall # discard all in-flight recordings ``` Cancelled recordings are not saved and not appended to any pending scene. --- ## Disk format Recordings are GZIP-compressed binary streams with delta encoding, bit-flag packing, and skip-tick compression. A typical 60-second recording is tens of KiB; a heavy combat clip with inventory churn is hundreds of KiB. If a recording grows unexpectedly large (megabytes), check for inventory NBT churn — items with random NBT components (mace attack data, etc.) used to inflate recordings before the byte-comparison delta fix in v0.1.4. --- ## See Also - [[Recap/Server Owners/Features/Playback]] — playing recordings back - [[Recap/Server Owners/Features/Scenes]] — composing recordings into scenes - [[Recap/Server Owners/Features/Hijack]] — interactive playback