|This article is a stub. You can help the wiki by|
See Instant Replay for the main article about this subject.
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)
For reproducible bug reports
|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
|I got FGTape file of a recorded flight how could I get the parameters in excel format