PinWright
Recorder & journal
The recorder captures a Play-In-Editor session as a timeline of variables and events, Afterward you ask your assistant questions about it: what was the state at this moment, what changed over this stretch, where did the errors happen. You debug a play session without playing it again.
What it is
It has two halves. While you play in the editor, the session is recorded to a file. Afterward your assistant reads it back to answer your questions. A recording holds variables (values per object over time, stored only when they change, so long sessions stay small) and events (named moments with a time and a severity).
What you need to set up
Out of the box, PinWright records when a session starts and stops. To record gameplay data (positions, throttle, race events, errors), add a few lightweight log calls to your game code with the recorder's logging API. Without them, a session has little to look at. Treat this as an advanced feature: PinWright records and answers questions, and you decide what your game reports.Capture a session
- Configure it under Edit → Editor Preferences → Plugins → PinWright → Journal: the journal is on by default; set how many recent sessions to keep and the output subfolder (default
Saved/PinWright/Recordings). - A session file opens automatically when you start Play-In-Editor and closes when you stop. Files are named
session-<date>-<time>-<id>.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 it does nothing when no session is open or in shipping builds.
Ask about a session
Ask your assistant in plain language. Start broad, then narrow down. For example:
| You ask | What you get |
|---|---|
| “Which sessions did I record today?” | A list of recent recordings. |
| “What’s in the last session?” | What was recorded: objects, variables with their units, the time range and how many events. A good first question. |
| “What was the drone’s speed at 42 seconds?” | The value of an object’s variables at that moment. |
| “How did throttle change between 30 and 60 seconds?” | The net change, minimum, maximum and average over that stretch, and when the extremes happened. |
| “Show me altitude over the first lap.” | How one value changed over time, thinned out to a readable size. |
| “Where are the first errors?” | The matching events, filtered by name, severity or object. The fastest way to find the moment something went wrong. |
| “Split the session into rounds.” | The timeline grouped into labeled stretches you can ask about one at a time. |
| A question none of the above covers | Your assistant can run a short Python query over the recording. |
Answers come back in small pieces, so your assistant can work through a session several minutes long without losing track of your project.
Limitations
- Editor and Play-In-Editor only. No capture in packaged or shipping builds.
- Recording gameplay data needs log calls in your game (see What you need to set up). Out of the box, only session start and stop are recorded.
- 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.
- Your assistant reads finished sessions. It can't ask about a session that is still running.
- Each answer is capped at a couple thousand rows, so a question about a very long stretch comes back cut short. Narrow the time window and ask again.