Fgtape

From FlightGear wiki
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.

1rightarrow.png See Instant Replay for the main article about this subject.

So called Fgtape[1] files are PropertyList-encoded XML files created by the FlightGear flight recorder subsystem, they contain serialized FlightGear properties for replaying flight data/flights.

The whole system is XML-configurable, so that custom/aircraft-specific properties can be easily supported, while generic/common properties are typically included from a shared location in $FG_ROOT: http://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Aircraft/Generic/flightrecorder/

The configuration reference can be found in $FG_ROOT/Docs/README.flightrecorder: http://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.flightrecorder


Cquote1.png fgtape = $FG_ROOT/Docs/README.flightrecorder: http://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.flightrecorder (what used to be the old "instant replay" system, but ended up getting generalied by ThorstenB to become a generic "Property Recorder" subsystem.The system could be useful for doing both 1) creating repeatable benchmark situations that override end-user configuration, but also for 2) sharing end-user created flights for reproducing certain issues.The case we've been discussing here is to use the flight recorder subsystem (fgtape) to create/save a "benchmark flight" into $FG_ROOT, so that end-users can use that to "play" the flight, while a few lines of Nasal would sample a handful of properties to determine the impact on frame rate/spacing.The alternative would have been to use Nasal for creating the situation/flight in a scripted fashion, but that is probably not such a good idea, especially because Nasal may very well add to the CPU overhead anywayRight now, fgtapes are all about aircraft-specific properties: http://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Aircraft/Generic/flightrecorder/
Cquote2.png

File format

Use Cases

Saving/Loading flights

For reproducible bug reports

For benchmarking

Regression testing

Cquote1.png For starters, you will need a reproducible test case - e.g. a startup profile, or a saved flight (fgtape) and then play with different startup/runtime settings (location/aircraft, enabled/disabled features) to see if/how the bug can be reproduced.
— Hooray (Aug 17th, 2015). Re: 32bit and low memory systems, read this.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Once there is a handful of different test cases, those could be used for regression testing purposes - e.g. to compare FG 3.2 RAM/VRAM (memory) occupancy against 3.6 and 3.8. Equally, that would mean, that it would become easier for people to spot serious bugs/regressions, such as an aircraft (or Nasal script) suddenly utiliing much more resources.
Cquote2.png
Cquote1.png deally, people doing such flights regularly would provide a corresponding "fgtape" file using a standard aircraft and get this committed to $FG_ROOT into some kind of "Tests" directory containing pre-recorded flights for doing regression testing in an automated fashion. The thing to keep in mind here is that those among us able (and willing) to troubleshoot such issues are most unlikely to ever actually use FlightGear like this, which certainly includes Zakalawe. Thorsten recently also mentioned that he'll typically just start up FlightGear a few doen of times using a simple aircraft to test things, without really doing any "real" flying at all. So there are certainly a number of use-cases that aren't getting much attention unfortunately.Which is why it would be a good idea for people to provide flight recorder tapes covering use-cases they care about, and get those committed to fgroot (fgdata) - so that we can grow a library of useful flights to do regression testing - as long as those flights are using standard aircraft and features, they should also be useful for people entirely new to FlightGear.While developers, and power users, could use those flights to run FG in an unattended fashion, without having to be overly familiar with aircraft internals (think aircraft startup procedures, IAPs, STARs and other VA stuff) - we could even use accelerated sim-time to complete whole flights in a fraction of the time normally required, while stress-testing a bunch of underlying systems, including the route manager, autopilot, and FDM. Many of those don't necessarily require any "rendering" - which is touching on the whole "headless" effort that James has been working towards independently: FlightGear Headless
— Hooray (Feb 26th, 2015). Re: 3.4 and the pain begins ....
(powered by Instant-Cquotes)
Cquote2.png

Pre-release testing

Cquote1.png At some point, this could then even be done in an automated fashion on the build server directly - but we will need people to provide fgtape files covering different use-cases to exercise different code paths, without core developers necessarily having to spend hours doing transcontinental flights in a twin-engine turbprop, you know xD But I guess that is something that should be better discussed on the devel list, once we have people offering to provide a few pre-recoreded fgtape files to get this started ...
— Hooray (Feb 26th, 2015). Re: 3.4 and the pain begins ....
(powered by Instant-Cquotes)
Cquote2.png

Flight analysis

Cquote1.png I got FGTape file of a recorded flight how could I get the parameters in excel format
— ali.6361 (Aug 1st, 2014).  file in excel.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png What FlightGear is writing to those files is not actual "visual" stuff at all, it's just "gibberish" in the sense of properties that are only meaningful to FlightGear itself, and its features, most properties are in fact aircraft specific. Imagine those files to be containers for binary FlightGear properties, i.e. things like altitude, longitude, latitude - but also engine settings, flap settings, gear status etc.So there's really just numbers stored there, nothing visual that would make sense to visually re-interpret outside a flight simulator environment like FlightGear.To actually replay even just a single aircraft specific animation in FlightGear, you would have to write a python script that 1) loads the aircraft, 2) looks up the 3D objects, 3) maps the properties to animations - and completely ignore anything related to scenery, because it's typically just aircraft specific stuff that is recorded.
— Hooray (Apr 21st, 2014). Re: Replay Conversion.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png the format is basically seralied FlightGear properties, please see $FG_ROOT/Docs/flightrecorder.README - these are all just "numbers", the format is determined by FlightGear, and these numbers do not mean ANYTHING outside FlightGear, and even inside FlightGear it's really just the flight recorder subsystem that is able to open/process those files, read in the numbers and map them to the corresponding FlightGear properties - which in turn allows things to be animated/replayed over time JUST VIA FlightGear.
— Hooray (Apr 21st, 2014). Re: Replay Conversion.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png i would like to use the flight data recorded during the flight in the .fgtape format. However, i don't want to watch the replay but compare the recordednumbers of the replay with i.e. an ideal flight curve. For this reason, i'd like to extract the data from the file to work with it. How can i proceed? Is it already implemented in a way?
— CasJanM (Feb 9th, 2015). Extracting flight data from recorded flights.
(powered by Instant-Cquotes)
Cquote2.png