Recorder & telemetry

The recorder captures a Play-In-Editor session as a timeline of variables and events, then lets you (or your assistant) query it afterward: what was the state at this moment, what changed across this window, where did the errors happen. It is built for AI-assisted debugging of a play session without re-running it.

What it is

Two halves. A capture side records a session to a file while you play in the editor, and a query side (the recorder.* tools) reads a recorded session back in small, bounded answers. Recorded data is variables (per-object time series, stored as change points so long sessions stay small) and events (timestamped, named, severity-tagged).

Status, honestly. The recorder and its query tools are real, wired, and unit-tested. But what gets captured out of the box is limited: the plugin records the session lifecycle automatically, while capturing meaningful gameplay data (positions, throttle, race events, errors) requires you to add a few lightweight log calls in your own game code using the recorder's logging API. Without that instrumentation, a session holds the envelope but little gameplay data. Treat this as an advanced feature: the plugin is the recorder and the query engine; you decide what to feed it.

Capture a session

Enable it under Edit → Editor Preferences → Plugins → Editor Automation RPC Gateway → Telemetry: turn telemetry on, choose how many recent sessions to keep, and the output subfolder (default Saved/EditorAutomation/Recordings).
A session file opens automatically when you start Play-In-Editor and closes when you stop. Files are named session-<date>-<time>.ndjson.
To record gameplay data, add log calls in your game with the recorder API (log a variable value, log an event). Logging is cheap and is a no-op when no session is open and in shipping builds.

Query a session

All through your assistant (the recorder.* tools). Start broad, then drill down:

recorder.list_sessions: list recent recordings.
recorder.describe_session: the first call to make. Returns the catalog of recorded objects, the variables available (with units and kinds), the time range, and the event count, so you can discover what is in the session.
recorder.get_state: the value of an object's variables at a given time.
recorder.summarize_change: over a window, the net change, min, max, mean, and where the extremes happened. The workhorse.
recorder.get_series: the change points of one variable over a window, downsampled to a budget.
recorder.find_events: jump to events, filtered by name, severity, or object. The fastest way to find the moment something went wrong.
recorder.list_segments: group the timeline into labeled windows you can feed back into the other queries.
recorder.query: a Python escape hatch for ad-hoc questions the structured tools cannot express.

Every result is hard-capped and self-describing, so your assistant can analyze a multi-minute session without blowing its context.

Limitations

Editor and Play-In-Editor only. No capture in packaged or shipping builds.
Gameplay telemetry requires instrumenting your game (see Status above). Out of the box, only the session lifecycle is captured.
Only a generic editor-session segment ships by default. Grouping a timeline into your own segments (a race round, a match, a mission) requires registering those segment types from your game.
Queries read a finished session file. There is no live query of an in-progress session yet.
Results are capped (a couple thousand rows per query) by design, so an over-broad window comes back truncated rather than unbounded.

← Back to docs