Skip to main content

Recording a match

Runtime: recorder · Use it for: match start/end hooks Follow the recording guide for the lifecycle and selection rules behind this example. Declare depend: [reverse-recorder] in this integration’s plugin descriptor. Call startMatch and finishMatch from your own main-thread match lifecycle, and store the returned session UUID with your match. Adjust the bounds, owners, and participants to your arena. This example only publishes a normal replay-ready notification after event persistence and terrain have succeeded. A degraded save retains events but needs separate handling. exportRecentClip(sessionId) saves the trailing ten seconds without stopping capture. exportClip(sessionId, from, to) uses inclusive offsets from the recording’s start: pass Duration.ZERO to start at the beginning, or a null to to end at the accepted request’s current tick. For example, seconds 30–45 use Duration.ofSeconds(30) and Duration.ofSeconds(45). The exported replay has a fresh UUID, rebased events and copied terrain. All three methods require the main thread; each returns the same save-outcome contract. Handle synchronous invalid-duration failures in your command layer too. This example requires a nonnull participant set and snapshots it with Set.copyOf: empty means no players. To capture all in-scope players through the service, pass null instead. Owners still control access independently. Packet-recipient identity is not a participant filter.
Copy this class into your integration and connect its methods to your match lifecycle.