# Flightgear recordings Recording files generally have a `.fgtape` suffix. As of 2020-12-22, there are three kinds of recordings: * Normal * Continuous * Recovery Normal recordings are compressed and contain frames at varying intervals with more recent frames being closer together in time. They are generated from the in-memory recording that Flightgear always maintains. They may contain multiplayer information. Continuous recordings are uncompressed and written directly to a file while Flightgear runs, giving high resolution with near unlimited recording time. They may contain multiplayer information. As of 2020-12-23 they may contain information about extra properties, allowing replay of views and main window position/size. Recovery recordings are essentially single-frame Continuous recordings. When enabled, Flightgear creates them periodically to allow recovery of a session if Flightgear crashes. ## Properties * `/sim/replay/tape-directory` - where to save recordings. * `/sim/replay/record-multiplayer` - if true, we include multiplayer information in Normal and Continuous recordings. * Normal recordings: * `/sim/replay/buffer/high-res-time` - period for high resolution recording. * `/sim/replay/buffer/medium-res-time` - period for medium resolution. * `/sim/replay/buffer/low-res-time` - period for low resolution. * `/sim/replay/buffer/medium-res-sample-dt` - sample period for medium resolution. * `/sim/replay/buffer/low-res-sample-dt` - sample period for low resolution. * Continuous recordings: * `/sim/replay/record-continuous` - if true, do continuous record to file. * `/sim/replay/record-extra-properties` - if true, we include selected properties in recordings. * Recovery recordings: * `/sim/replay/record-recovery-period` - if non-zero, we update recovery recording in specified interval. ## Code The code that creates recordings is not particularly clean or easy to work with. It consists mainly of two source files: * `src/Aircraft/flightrecorder.cxx` * `src/Aircraft/replay.cxx` Despite their names these files are both involved with record and replay. `src/Aircraft/flightrecorder.cxx` is lower-level; it takes care of setting up data for each frame when recording (see `FGFlightRecorder::capture()`) and reading data when replaying (see `FGFlightRecorder::replay()`). `src/Aircraft/replay.cxx` is complicated and does various things. It maintains 3 in-memory buffers containing recording information at different temporal resolutions so that Flightgear can store any session in memory. For example only the most recent 60s is recorded at full frame rate. ## File format ### Normal recordings * Header: * A zero-terminated magic string: `FlightGear Flight Recorder Tape` (variable `FlightRecorderFileMagic`). * A Meta property tree containing a `meta` node with various child nodes. * A Config property tree containing information about what signals will be contained in each frame. Each signal is a property; signals are used for the main recorded information such as position and orientation of the user's aircraft, and positions of flight surfaces, gear up/down etc. Aircraft may define their own customised set of signals. The Meta and Config property trees are each written as `` where `` is a text representation of the properties. `` is terminated with a zero which is included in the `` field. * A series of frames, each containg the data in a `FGReplayData` instance, looking like: * Frame time as a binary double. * Signals information as described in the header's `Config` property tree, represented as a 64-bit length followed by binary data. All data after the header is in a single gzipped stream. ### Continuous recordings * Header: * A zero-terminated magic string: `FlightGear Flight Recorder Tape` (variable `FlightRecorderFileMagic`). * A property tree represented as a `uint32` length followed by zero-terminated text. This contains: * A `meta` node with various child nodes. * `data[]` nodes describing the data items in each frame in the order in which they occur. Supported values are: * `signals` - core information about the user's aircraft. * `multiplayer` - information about multiplayer aircraft. * `extra-properties` - information about extra properties. * A `signals` node containing layout information for signals, in the same format as for Normal recordings. The header is written by `FGReplay::continuousWriteHeader()`. * A series of frames, each containg the data in a `FGReplayData` instance, looking like: * Frame time as a binary double. * A list of ordered `` items as described by the `data[]` nodes in the header. This format allows Flightgear to skip data items that it doesn't understand if loading a recording that was created by a newer version. * For `signals`, `` is binary data for the core aircraft properties. * For `multiplayer`, `` is a list of `` items where `` is a multiplayer packet as received from the network. * For `extra-properties`, `` is a list of property changes, each one being: * `` - property has changed to ``. Removal of a property is encoded as `<0:16>`. Continuous recordings do not use compression, in order to simplify random access when replaying. ## Replay of Continuous recordings When a Continuous recording is loaded, `FGReplay::loadTape()` first steps through the entire file, building up a mapping in memory from frame times to offsets within the file, so that we can support the user jumping forwards and backwards in the recording. If the recording contains extra properties, we also build a cache of the locations of frames that have a non-empty extra-properties item, again to support jumping around in time. ## Multiplayer ### Recording while replaying: If the user replays part of their history while we are saving to a Continuous recording, and the Continuous recording includes multiplayer information, then we carry on receiving multiplayer information from the network and writing it to the Continuous recording. The user's aircraft is recorded as being stationary for the period when the user was replaying. ### Replaying When replaying a recording that contains multiplayer information, only recorded multiplayer information is displayed to the user. Chat messages are included in multiplayer recordings. When replaying, we attempt to hide recorded chat messages and only show live chat messages, but this is a little flakey, especially when jumping around in history. ### Details The way that Multiplayer data is handled is a little complex. When recording, we build up a buffer of multiplayer packets that we have received since the last time that we wrote out a frame of data, then write them all out in the next frame we write. When replaying, `FGFlightRecorder::replay()` sends replayed multiplayer messages into the low-level multiplayer packet-receiving code by calling `FGMultiplayMgr::pushMessageHistory()`.