Fgtape
Jump to navigation
Jump to search
| This article is a stub. You can help the wiki by expanding it. |
|
|
| Startup |
|---|
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
|
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/ — Hooray (Sep 22nd, 2015). Re: How to tell if you are CPU or GPU limited (split).
(powered by Instant-Cquotes) |
|
File format
Use Cases
Saving/Loading flights
For reproducible bug reports
For benchmarking
Regression testing
|
|
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. |
|
|
|
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. — Hooray (Aug 25th, 2015). Re: Looking for people with ATI/AMD GPUs building from sourc.
(powered by Instant-Cquotes) |
|
|
|
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 |
|
Pre-release testing
|
|
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 ... |
|
Flight analysis
|
|
I got FGTape file of a recorded flight how could I get the parameters in excel format |
|
|
|
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. |
|
|
|
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. |
|
|
|
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) |
|