Redesigning the Replay System

This article is a stub. You can help the wiki by expanding it.

Also see Proposals:Replay related and Talk:Proposals:Replay related.

The Instant Replay system in its current form is not able to deal with many possible FlightGear use/case scenarios, among others it has currently the following known limitations:

• replaying environmental state (time, weather, visibility) is not yet supported
• replaying AI state (traffic, ATC) is not yet supported
• replaying flights with specific custom aircraft animations is not yet fully supported
• replaying flights done with aircraft that make use of Nasal scripts for some advanced features is not yet sufficiently supported (or standardized)

Also, the replay system is directly related to a number of other important use/case scenarios, such as:

• saving/loading whole flights (see prerecorded flights)
• saving/loading in-flight "situations"
• resuming flights at a particular position in time

While there are several other systems/techniques (such as the generic protocol or logging systems, or the ac-state.nas script to save aircraft state) being used to compensate for some of the shortcomings of the current replay system, it is still getting obvious that there needs to be an orchestrated effort to redesign the instant replay subsystem to make it become more flexible and configurable, so that it provides key functionality in a standardized fashion.

Current Implementation

Note: The latest source code of the replay subsystem can be found in $FG_SRC/Aircraft/replay.(c|h)xx

• 07/2003: "I have implimented a first stab at an instant replay system and have just commited it to CVS. The system continuously records your flight data and allows you to play back your flight."[1]

• 07/2003: "Saving flight data at full resolution can quickly burn up a lot of RAM, so at the moment, only the most recent 60 seconds is stored at full resolution."[2]

• 07/2003: "The next most recent 10 minutes is stored at a resolution of one snap shot every 0.5 seconds."[3]

• 07/2003: "The most recent hour of data is stored at a resolution of one snap shot every 5 seconds."[4]

• 07/2003: "(We might need/want to tune these values a bit as we use the system more.) However, this gives the most resolution to the most recent portion of the flight, and can save up to an hour's worth of flight data without using a huge amount of memory."[5]

• 07/2003: "Each snapshot is time stamped with the simulation time. During replay, the system finds the two snapshots that straddle the replay time and linearly interpolates between them. This way, we can record the data as best as is possible given the current rendering speed, even with varying frame rates with possible lost frames and aren't forced to take extraordinary measures to get a consistent sampling rate."[6]

• 07/2003: "Then when the data is replayed, this interpolation scheme gives us smooth playback even if the recorded frame rate is wildly (or slightly) different from the playback frame rate. This also gives us smooth interpolation for older data that is recorded at a slower rate. And we can play back the recorded flight at a rate that has a 1 to 1 match with "real" time."[7]

• 07/2003: "This scheme would also allow us to smoothly fast forward the replay, or replay in super smooth "Slo-Mo-Gear" (patent pending) :-) We could probably also rewind as well as fast forward if we really wanted to."[8]

• 07/2003: "The sim is put into "pause" mode while the buffer data is replayed. This has some side effects because many subsystems do not run when the simulator is paused. This needs to be looked at a bit more. Specifically some of the viewer code isn't run. You can switch views with the "v" series of keys, but you can't rotate a particular view with shift-number pad, and the chase views don't track quite right in replay mode"[9]

• 07/2003: "Also, I don't and can't and won't record "everything". This means things like AI or multiplayer traffic, weather conditions, and other things are beyond the scope of this system at this time."[10]

Community Feedback about Instant Replay Issues

• "Be warned that there are multiple bugs in the recording/playback system, including FG code, simgear code, and FG data. Some of the bugs have been found and fixed. Others have not."[11]
• "First off, what parameters are logged by it, or what defines if a parameter is logged by it? ie, thrust reverser use do not replay, but flaps do. This doesn't seem to be by model builder choice (?), unless Instant Replay is tied into multi-player parameters?"[12]

• 05/2010: "We recognized that to record hours of high resolution flight data would blow up the memory footprint of FlightGear on any PC. So we went for a balance"[13]

• 05/2010: "We record the most recent 60 seconds of data at full resolution, then the previous "n" minutes (I forget the exact number) is recorded at 1 second intervals. And then I think we go even further back recording at an even sparser interval. This way you get something as far back as you like, and you get high detail if you replay the last 60 seconds." [14]

• 05/2010: "Originally, the recorder got turned off during the replay. Now the recorder continues to record while you replay ... so you are recording the replay as you replay it and you sort of end up with a recursive infinite loop. This actually has a nice feature that when you replay a flight, it loops for ever until you quit the replay, but know that each time through you are replaying a recording of the previous replay, and losing resolution each time through the cycle. So that's a bug, it needs to be fixed, I haven't had a chance to dig into it." [15]

• 05/2010: "The problem with this particular bug is that because you are recording as you replay, you never actually get to see that 60 seconds of highly detailed data (assuming you replay more than 60 seconds which most people probably do.) So we are missing out on all the subtle nuances of your landing when you replay your landing for instance." [16]

• 05/2010: "One other thing. The data structure that is recorded is the FGNativeFDM structure defined in src/Network/native_fdm.hxx. You do bring up a good question: what values should be recorded every frame? Given that aircraft designers can make up their own properties and drive them with nasal or other means, we can't know in advance a fixed set of property names that cover every situation." [17]

• 05/2010: "So for the replay system we decided to go with a fixed, pre-defined binary structure ... and then you do live with a few replay warts if you are viewing an aircraft that uses "non-standard" properties ... and that's not a knock on the aircraft designer ... some airplanes have more than 4 engines, the AN-225 has like 185 landing gear assemblies, many aircraft have unique control systems and control surfaces ... and we can't take 20 minutes worth of snapshots of the entire property tree @ 60hz ... not on my PC anyway." [18]

• 05/2010: "So the 60 second marker you mention is interesting ... that could correspond with the system that records the most recent 60 seconds at a high data rate. There could be some boundary logic there that didn't take every possible situation into consideration." [19]