Board index FlightGear Development New features

Possibility to Save a flight

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Possibility to Save a flight

Postby Upkeep » Fri Mar 11, 2011 2:38 pm

I am sure it has been mentioned before, but I wondered if there were any plans to have a 'save' function on FlightGear, so you can save a trip in mid flight and load it up again later in exactly the same position, etc. This sort of thing is available in other simulators and it would be very helpful to have it in FlightGear. Sometimes on long flights it is good to take a break!

Thanks very much.

Regards.

Upkeep.
Upkeep
 
Posts: 286
Joined: Sun Nov 22, 2009 5:21 pm

Re: Possibility to Save a flight

Postby redneck » Fri Mar 11, 2011 3:16 pm

There has indeed been talk about a save function. So far, there is one that works only if your plane is parked on the ground. I can't remember what the script was called. save_state.nas, maybe. I could never get it to work though; however, others managed to have success with it.
Call Signs: redneck, ATCredn (unspecified freq atc)
FGFSCopilot
FGFSCopilotATCEdition
System Specs
Model: Alienware M15x, OS: Windows 7 Professional 64-bit, RAM: 3 GB, CPU: Intel i3 quad core at 2.4 GHz, GPU: Nvidea GeForce GTX 460M 1.5 GB GDDR5
redneck
 
Posts: 3630
Joined: Mon Feb 02, 2009 2:17 am
Location: Pennsylvania, USA
Version: 240

Re: Possibility to Save a flight

Postby Upkeep » Fri Mar 11, 2011 3:50 pm

Thanks Redneck. You reminded me.

I do now seem to remember there was a 'save' function on 1.9 I think, but like you try as I might I could never get it to work, so promptly forgot about it. I notice it no longer exists in current versions which suggests it was not a great success. Incidentally, I am a keen user of Orbiter, which is a free space simulator, and there you can save a flight whenever you want and re-load it in exactly the same position. If you are flying to Mars and it takes nearly a year to get there it is clearly a good idea to have a save function!

Regards. Upkeep.
Upkeep
 
Posts: 286
Joined: Sun Nov 22, 2009 5:21 pm

Re: Possibility to Save a flight

Postby redneck » Fri Mar 11, 2011 5:36 pm

Oh yeah, I know what you mean. FSX can do it, so why not FG? Idk. Clearly the developers have run into some problem, and may or may not be trying to work around it at this time.
Call Signs: redneck, ATCredn (unspecified freq atc)
FGFSCopilot
FGFSCopilotATCEdition
System Specs
Model: Alienware M15x, OS: Windows 7 Professional 64-bit, RAM: 3 GB, CPU: Intel i3 quad core at 2.4 GHz, GPU: Nvidea GeForce GTX 460M 1.5 GB GDDR5
redneck
 
Posts: 3630
Joined: Mon Feb 02, 2009 2:17 am
Location: Pennsylvania, USA
Version: 240

Re: Possibility to Save a flight

Postby kyokoyama » Sun Mar 13, 2011 12:04 am

Positioning the plane and recording its headings etc. shouldn't be hard in theory, either....
...right? (I wouldn't know...)
Look for "B-BIRD" "N127KY" or "AVA0004" -that's me.

Despite having over 1700 posts here, I am not even close to being the most skilled guy here... I'm just words and bad drawing, not experience. :P
kyokoyama
 
Posts: 1988
Joined: Sun May 03, 2009 2:16 am
Location: Earth
Callsign: B-BIRD, N127KY
Version: 2.12.1
OS: Windows Vista

Re: Possibility to Save a flight

Postby Hooray » Sun Mar 13, 2011 1:36 pm

Upkeep wrote:...I wondered if there were any plans to have a 'save' function on FlightGear, so you can save a trip in mid flight and load it up again later in exactly the same position, etc. This sort of thing is available in other simulators and it would be very helpful to have it in FlightGear.


Agreed...
But I don't think anybody is working on adding support for this.
This is because it is VERY HARD TO DO RIGHT (I actually tried this a while ago, when we last talked about this issue here).

Such a "feature" (if done correctly) would basically touch/affect EVERY SINGLE SYSTEM in FlightGear.
So this is not something that can be done by a single person.

redneck wrote:There has indeed been talk about a save function.


redneck is right, there have been lots of discussions about this, on both the forums and the mailing lists.
The wiki also contains some more technical info.
So if you are interested in this, my suggestion is to search the forums, the mailing lists and the wiki for more info:

viewtopic.php?f=6&t=865#p94288
viewtopic.php?f=17&t=8982&p=88427#p88427
viewtopic.php?f=6&t=2916
viewtopic.php?f=2&t=6894
viewtopic.php?f=2&t=2897&p=25188
viewtopic.php?f=2&t=3246

redneck wrote:Oh yeah, I know what you mean. FSX can do it, so why not FG? Idk.


The short answer is: due to architectural issues in FlightGear, for a more detailed answer see below (or check out the links) ;-)

redneck wrote:Clearly the developers have run into some problem, and may or may not be trying to work around it at this time.


To my knowledge, the "save" facility never really worked successfully, it's a legacy feature that pre-dates many of the more recent features in FG, and thus was never able to work properly. Also, I don't think that anybody is actually working on fixing this. It's a lot of work for very little VISIBLE gain. Which is not to say that it wouldn't be a great thing for FlightGear.

But you really have to keep in mind that such a feature would affect MOST if not even ALL systems in FlightGear, so rather than hard-coding special cases into each component, it would be better to prepare the architecture accordingly, especially because such a feature would need to work with upcoming features, too.

Like you said, it's a standard feature that is provided by other simulators (or other software in general).
Not being able to save and reload state really is a serious issue. (it's like the difference between a type writer and a computer).

The original subsystem code in simgear does provide some building blocks for implementing this, but obviously this has never been a priority.


redneck wrote:So far, there is one that works only if your plane is parked on the ground. I can't remember what the script was called. save_state.nas, maybe. I could never get it to work though;


You are probably referring to ac_state.nas
It's a Nasal script that tries to save and reload certain settings, it works for some cases - but it cannot really work for everything.
See here: viewtopic.php?f=6&t=1791&p=16215

kyokoyama wrote:Positioning the plane and recording its headings etc. shouldn't be hard in theory, either....
...right? (I wouldn't know...)


Yes, you are sort of right: recording/storing these variables isn't really hard at all.

After all, many relevant variables are already exposed to the property tree (position, velocities, orientation etc).
So you would not even need to do any programming to store the property tree to an XML file, because this is already supported by FG.

However, the thing here is that FlightGear was never designed to know about how to RESTORE saved state in order to RESUME a previously saved flight.

This is much more tricky than you may think, obviously saving the state is the first requirement, but knowing what to do with it later on (and how to do it !) is much more complicated:

There are many "pieces" in FlightGear, called "subsystems" (graphics, scripting, sound, fdm, I/O etc) - some of those run in parallel, while others run
sequentially, i.e. are getting called by the previous component.

Many of those subsystems are getting invoked in a hard-coded fashion and order, where it is safe to make certain assumptions, but once you want to be able to save and load flights, you are opening another can of worms, because things may be getting invoked in a different fashion.

The way FlightGear has been (and is being) developed is to have one "hard-wired" initialization order, where things are sort of "kicked off" after start, but are not meant to be interrupted, stored to disk and then resumed later on. The main loop is a very static thing in FG.

Simply imagine FlightGear and its internal architecture like a team of about 20+ people (=subsystems) that need to work
together to create the desired output (visuals, audio, I/O etc).

Now imagine you were to coordinate a bunch of 20+ folks to work for you, towards a common goal (like e.g. building a house).

This in and of itself would already be very challenging, because you would need to do lots of coordination, synchronizing, planning things to ensure that all team members (subsystems) work together efficiently without blocking each other (=frame rate drops).

But once you add a new requirement that says that your team must be able to stop its work any time, and save all progress (state) in order to resume everything later on, things are getting much more complicated: You would need to establish rules and procedures for every single member of your team, so that it knows how to store its state (ALL of it!) and how to resume the work later on, without stepping on each others feet.

Without establishing such rules and procedures, processes could not be reliably resumed - which would end in chaos, and eventually crashes.


Another problem in FlightGear is, that it not all of its subsystems really use the subsystems "framework" that is provided by SimGear. This framework provides entry points (events/actions) for controlling and inspecting the state of subsystems. Some subsystems were added on top of others.
Such entry points make it for example possible to suspend, resume or reinitialize a system.

So you have parts of code in FlightGear that work like subsystems, but which do not implement the subsystem interface properly. This means for example that such "subsystems" cannot be controlled like true subsystems. Such special cases would need to be separated and ported first.

Also, many existing subsystems in FlightGear do not fully implement the complete functionality (the full abstract interface as provided by SGSubSystem). So you have lots of empty "dummy code" which doesn't really do what it was originally supposed to do, just to satisfy the compiler.

It is true that lots of state is readily available in the property tree and that it can be easily stored, but there are also lots of subsystems that depend on internal state which isn't yet exposed to the property tree, and which actually does not really belong into the property tree, or which may not even be easily represented as properties in the first place.
To address such issues, one would need to store things separately, or possibly introduce another property tree for "very internal" state.

A while ago, I actually looked into fixing some of these issues in a local branch, and to be honest: I think this is very complicated, and that it isn't easily achievable by a single person. I am pretty convinced that this is quite an effort, even for a team of professional full time software engineers.

My opinion is that even if the core design were to be properly fixed, that things would still be very complicated.
This is because of the way aircraft and scenery etc are being developed:

Basically, every aircraft features its own internal systems. These days, most aircraft make heavy use of dynamic features, like for example Nasal scripting.
For example, you have possibly hundreds or even thousands of lines of scripting code running within the simulator, forming another architectural layer.

And we are just talking about aircraft scripts here, but think about entire systems implemented in Nasal space, such as for example "local-weather" and "bombable", both of which were also designed to be loaded, initialized and run ONCE - there is no support available for re-initializing, reloading or resuming a previously saved state.

While I am not too familiar with the bombable script (flug), the local weather system (Thorsten) has the "advantage" that it makes fairly heavy use of the property tree for managing its own internal state. So it would probably be somewhat easier to add support for serializing and restoring state. On the other hand, the local weather system is more and more getting ported to favor use of Nasal data structures, due to performance benefits.

Bottom line being: You would need to re-implement the SGSubsystem interface in Nasal space and stop loading and running scripts automatically, and instead register listeners for controlling Nasal scripts, so that scripts can also be reliably suspended, resumed, re-initialized (and script state un/serialized).

The next step would be to port ALL Nasal scripts (aircraft, scenery etc) to make use of those listeners.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11472
Joined: Tue Mar 25, 2008 8:40 am

Re: Possibility to Save a flight

Postby HHS » Sun Mar 13, 2011 2:01 pm

I think we had this discussion once ago.

here is the link: http://www.flightgear.org/forums/viewtopic.php?f=17&t=6427

And here the link to the nasal file: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg02909.html
Up, up and away
User avatar
HHS
Retired
 
Posts: 3624
Joined: Thu Jul 19, 2007 8:09 am
Version: GIT

Re: Possibility to Save a flight

Postby Farmboy » Sun Mar 13, 2011 3:03 pm

Upkeep wrote in Fri Mar 11, 2011 2:38 pm:I am sure it has been mentioned before, but I wondered if there were any plans to have a 'save' function on FlightGear, so you can save a trip in mid flight and load it up again later in exactly the same position, etc. This sort of thing is available in other simulators and it would be very helpful to have it in FlightGear. Sometimes on long flights it is good to take a break!


The other option is to simply record your position, heading and aircraft state manually. (all available in the property browser) Next time you spawn at an airport, reload in air at your recorded position (lat/lon/heading/alt/airspeed).
Horsepower is just an illusion. Torque is the true answer.
User avatar
Farmboy
 
Posts: 436
Joined: Wed Jan 14, 2009 10:10 pm
Location: NorthEast New York State, and the rest of New England....

Re: Possibility to Save a flight

Postby Upkeep » Sun Mar 13, 2011 4:03 pm

Thank you very much Farmboy for the very detailed and full response. Looking at what you say, it does not appear that this is likely to be solved, so I agree noting the location at the time is probably the only way. It is a pity (I assume Orbiter - see post above - is structured in a different way), but I can now understand the issues. Thank you again for your comments.

Regards

Upkeep.
Upkeep
 
Posts: 286
Joined: Sun Nov 22, 2009 5:21 pm

Re: Possibility to Save a flight

Postby ksanman » Sat Aug 04, 2012 12:48 pm

New to FlightGear but got stuck on the same problem. Only way I could find a way to take a break from a flight was to pause, use the map to find the nearest Airport, VOR,NDB, or NAVAID FIX, and then keep track of my altitude, heading and airspeed. Then when you fire up flightgear next you can klick on the Location tab in the menu and select the Airport, etc. and type in the elevation, and other info. That will get you close to where you left off. Kinda awlkward but may help. regards ksanman
ksanman
 
Posts: 7
Joined: Thu Aug 02, 2012 8:52 am

Re: Possibility to Save a flight

Postby Hooray » Sat Aug 04, 2012 1:21 pm

As far as I know, nobody is currently working on this.

That said, the new canvas system will also require more control and better re-initialization support in FlightGear, so that less subsystems are started by default, and so that certain subsystems can be started on demand, that would make it possible to run the canvas system standalone, using a special startup switch: http://wiki.flightgear.org/FGCanvas

Ultimately, the idea is to run certain instruments separately, analogous to the FGPanel project.

However, this probably requires another 6-12 months of work before it starts to materialize, as it will require architectural changes as the subsystem level: http://wiki.flightgear.org/FlightGear_Run_Levels

Currently, this is not a priority, I briefly looked into it, and it's not just the C++ code that's causing problems here, but also all the Nasal code in $FG_ROOT/Nasal which often assumes that a fully initialized simulator session is available.

So these are assumptions that need to be teased out and made explicit via some form of dependency resolution (signals/slots, listeners/events).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11472
Joined: Tue Mar 25, 2008 8:40 am

Re: Possibility to Save a flight

Postby mr_no » Sat Aug 04, 2012 1:34 pm

When the flightrecoder can record the flight isn't it just a matter of formality to store that data in a file???
But, we don't have to be able to fly just to view it would be nice.
Mosquito-XE JT-5B-autogyro Extra-300s STOL-Ch701
User avatar
mr_no
 
Posts: 362
Joined: Thu Jan 19, 2012 2:20 pm

Re: Possibility to Save a flight

Postby Hooray » Sat Aug 04, 2012 1:41 pm

mr_no wrote in Sat Aug 04, 2012 1:34 pm:When the flightrecoder can record the flight isn't it just a matter of formality to store that data in a file???


The flight recorder merely replays the data that it recorded, it doesn't currently support most of the other subsystems, including the FDM.
So when you see a flight being replayed, all the other subsystems are not really replaying at all.

However, ThorstenB mentioned that he was planning to provide support for resuming a flight at an arbitrary point:

ThorstenB wrote:some things are still high on my list: specifically the option to
easily save/load and stream recorded data using a format that doesn't
break easily. Also, the option of taking over flight controls at any
point during a replay. The latter isn't as easy as it sounds, since most
FDMs don't really like being repositioned or even having the speed
changed externally.


http://www.mail-archive.com/flightgear- ... 34164.html
http://www.mail-archive.com/flightgear- ... 34165.html
http://www.mail-archive.com/flightgear- ... 34172.html

Some of the FDM-related issues are discussed here: http://wiki.flightgear.org/FDM_engine_f ... ardization
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11472
Joined: Tue Mar 25, 2008 8:40 am

Re: Possibility to Save a flight

Postby clrCoda » Mon Aug 06, 2012 3:42 pm

I have been working on something that I call RALPH.

RALPH stands for Restart At Last-known Position Helper.

Some of the things i've done with RALPH:

Sim crashed, I restarted the sim where I left off.
Bad Landing? Practice a landing? I rewound the flight to a reasonable point and did the landing again.
Power outage? no problem, see sim crash.
Needed to leave the flight, shut down the sim, and come back to it later? No problem see sim crash.
I wanted to test out new or new to me features of new versions of flightgear, while also flying an airlines flight for the airlines I belong to, even tho some of those features could crash my sim. No probem see sim crash.
I wanted to restart the sim where I parked the plane at the last airport where I did not have a defined parking place, but I wanted to change the plane. No problem.
One could change the plane in flight using RALPH.



So far these things work well in Windows using FGrun and a couple additional files and a PERL installation and a clever PERL script written by Ryan "skyop" Miller, which turns FGrun into the RALPH application I had originally envisioned. About 3 or 4 months old now, really the only reason i've not mentioned RALPH before now is because we are interested in finding ways to get the same kind of joy we get out of FGrun with MAC loader and FGo!. I mention it now because I am pleased with the results and require the expertise of people using or developing MACloader, FGO! and those people well versed in using linux ".fgfsrc" configuration files.

I will try my best to explain the process and the files included. Please note that I am not a real programmer tho I "play" as an amateur/expert in the massively parallel ArrayForth.com computer machine language colorForth on the internet. :) ( hence my callsign clrCoda)

This is not the same thing as described above by more accomplished programmers. BUT it basically accomplishes the same thing. With the clever manipulation of the files about to be presented, much of what a pilot would like to accomplish mentioned in this thread is doable using RALPH. ( besides being a mans name, unfortunately for those men, RALPH is also a American way of describing that sickness where you have to bring your meal back up, that is to puke or vomit. " I ate/drank so much I had to ralph!") :) sorry :)


The basic idea: RALPH uses the logging facility thru a file I wrote (included below) called log-restart.xml to create and populate a Comma Separated Values file called log-restart.csv. This file is cleared and recreated on every restart of the simulator. FGrun points to the log-restart.xml in any one of three ways using the configuration facility that is read by FGrun on start up. ( more about that below in setting this up) The PERL script written by skyop reads the last entry in this log-restart.csv Comma separated values file and converts these relevant information entries into configuration entries relating to restarting at an "Initial Position". In the case of FGrun, the command line on the most PREVious pane, the one before Aircraft Selection, is pre-pended with a call to the PERL script. One can make any additional changes in FGrun ( besides Initial Position) and then having pressed RUN will start at the last known position recorded in the log-restart.csv file.

PERL was picked because we wanted to do this for the three most popular operating systems, Windows, Linux, and MAC where Linux and MAC typically comes with a PERL environment by default. Windows does not, and therefore I suggest installing Strawberry PERL as it is free and open source for Windows users. PERL is especially good at this kind of thing. There is also interest in doing this in PYTHON because most nearly all computers are sold or otherwise have a PYTHON environment, and PYTHON can also create a 'turnkey' application, that is, it can bring as much environment as it needs with the script in those cases where a PYTHON environment is not available. A 'c' programming language version for the 3 operating systems could do the same thing.

Here is the log-restart.xml
Code: Select all
<?xml version="1.0"?>
<PropertyList>
<logging>
  <log>
   <enabled>true</enabled>
   <filename>log-restart.csv</filename>
   <interval-ms>60000</interval-ms>
   <delimiter>,</delimiter>
   <entry>
    <enabled>true</enabled>
    <title>Longitude</title>
    <property>/position/longitude-deg</property>
   </entry>
   <entry>
    <enabled>true</enabled>
    <title>Latitude</title>
    <property>/position/latitude-deg</property>
   </entry>
   <entry>
    <enabled>true</enabled>
    <title>Altitude</title>
    <property>/position/altitude-ft</property>
   </entry>
   <entry>
    <enabled>true</enabled>
    <title>Heading</title>
    <property>/orientation/heading-deg</property>
   </entry>
   <entry>
    <enabled>true</enabled>
    <title>IAS</title>
    <property>/velocities/airspeed-kt</property>
   </entry>
   <entry>
    <enabled>true</enabled>
    <title>Fuel</title>
    <property>/consumables/fuel/total-fuel-lbs</property>
   </entry>
  </log>
</logging>
</PropertyList>


Save this file as log-restart.xml. You would put it in your flight gear root folder at the same level as the folder /data. For me on Windows using FGrun this was c:/flightgear2.6/log-restart.xml

We now need to point FGrun to this file so that the sim will read it and automagically create and re-create on every start up the file log-restart.csv. There are three ways to do this in FGrun.

1) you could go to the FGrun SELECT PATHs -- the most PREV pane and point to it in the EXECUTABLE box like this:
Code: Select all
Executable: C:/FlightGear26/bin/Win32/fgfs.exe --config=log-restart.xml


2) you could go to the ADVANCED pane on the RUN pane and in the GENERAL menu at the bottom just above the OK and CANCEL buttons you can use the CONFIG: box and using the box with the dots "..." you could navigate to the the log-restart.xml and select it here.

3) you could add it to a resource file. For MAC and Linux this file is called .fgfsrc ( in MAC this is most likely a HIDDEN file if it is included at all) For Windows the name is different. In Windows you would create it in your /data folder and it would be called system.fgfsrc. Linux uses a .fgfsrc file, tho you may have to search to find where it is in your file system. These (system).fgfsrc files are read by FGFS.exe on start up. One would open or create the resource file and add the entry "--config=log-restart.xml"

The log-restart.xml is written to log an entry once every 60000 miliseconds, that is, once a minute, which is usually "good enough" granularity. Change the entry in the log-restart.xml file if you need more or less. When the sim is running and if the sim is configured to point to log-restart.xml then a file called log-restart.csv is created on start of the sim and once every minute log-restart.csv is updated with entries.
Each entry line is:

TIME the sim has been running in one minute 60 second intervals
LONGITUDE
LATITUDE
ALTITUDE
HEADING
IAS indicated airspeed
FUEL last known fuel amount left in the plane so that you know how much to reset the tanks which you have to do after restart.

An example of the first 10 minutes of my last flight using RALPH.
Code: Select all
Time,Longitude,Latitude,Altitude,Heading,IAS,Fuel
60,8.586416844,50.05044902,371.2593879,340.167299,2.933680568,5850.06134
120.1,8.586918559,50.05025852,371.178533,131.069527,9.994365151,5848.991932
180.1,8.586699182,50.04857167,368.2954123,193.992153,21.58224094,5848.089069
240.1,8.584136233,50.04463618,360.8254066,235.4795143,19.83154336,5847.907593
300.042,8.551564433,50.03690289,943.0969662,248.8956451,123.5791627,5809.920882
360,8.535276705,50.01482529,2813.541636,116.980445,119.6035743,5744.030556
420.05,8.587713684,50.02271376,4498.904198,76.25837906,144.9419199,5681.444839
480.083,8.670176611,50.03699453,7091.730152,76.71413027,210.2131943,5622.477752
540.108,8.776145978,50.05361977,10532.1656,78.53846013,228.8669645,5568.913741
600,8.891545719,50.06502347,14177.21906,88.91411171,222.2843478,5521.022397


With just this much information, one could go to the ADVANCED dialog on the RUN pane of FGrun, and choosing the INITIAL POSITION menu entry you could insert the LON, LAT, ALT, HEAD, and IAS entries into the proper boxes and restart the sim at your last known position.
Someone using LINUX would write the proper Initial Position entries found at this wiki link into your .fgfsrc configuration file:
http://wiki.flightgear.org/Command_line ... rientation

Making this a bit more convenient:
For WIndows users using FGrun you want a PERL environment to use Ryan 'skyop' Miller's PERL script. Like I said above, I got the Strawberry PERL environment from http://www.perl.org/get.html at the bottom of the page. Linux and MAC usually already have a PERL environment installed.

skyop's script version 3.
Code: Select all
#!/usr/bin/perl
# R.A.L.P.H.
# Reload At Last Position Helper
# Confidential: ATLAS VIRTUAL AIRLINES
# Written by Ryan Miller
use strict;

sub help
{
   print <<EOF;
Usage: <log file> <fgfs executable> [fgfs options...]
EOF
   exit;
}
sub fancyMsg
{
   my $msg = $_[0];
   print "***  ";
   print "$msg\n";
}
sub launch
{
   print "[Hit Return to launch FG]";
   my $input = <STDIN>;
   system(@_);
   exit;
}

if (length @ARGV < 2)
{
   &help;
}
my $logFile = shift @ARGV;
if ($logFile eq "--help" || $logFile eq "-h")
{
   &help;   
}

my $fgfs = shift @ARGV;
unless (open(LOGFILE, $logFile))
{
   &fancyMsg("Failed to open FG log file!");
   &launch($fgfs, @ARGV);
}

my @data = ();
while (<LOGFILE>)
{
   if (eof and /^[^T]/)
   {
      chomp;
      @data = split ",";
   }
}
if (!@data)
{
   &fancyMsg("Did not find a last entry in the log file. Are you sure you set up logging correctly?");
   &launch($fgfs, @ARGV);
}

# assemble fgfs arguments
my @args = ();
push(@args, "--lon=$data[1]");
push(@args, "--lat=$data[2]");
push(@args, "--altitude=$data[3]");
push(@args, "--heading=$data[4]");
push(@args, "--vc=$data[5]");
push(@args, @ARGV);

# messages
&fancyMsg("Restoring position from $data[0] seconds into the previous flight.");
&fancyMsg("Fuel level was $data[6] lbs");

# call fgfs
&launch($fgfs, @args);


The PERL script reads the log-restart.csv file and gets the last entry in the comma separated values file and creates the Initial Positions entries for FGrun so you don't have to. If you start the sim with the logging set up above then shut down or crash the sim, then you could add this entry to your EXECUTABLE box shown here below, and on the next restart, that is the next time you hit RUN in FGrun, you would start in your last known postion.

Code: Select all
Executable: C:\strawberry\perl\bin\perl.exe C:\FlightGear26\ralph_v3.pl C:\FlightGear26\log-restart.csv C:\FlightGear26\bin\Win32\fgfs.exe


Because this was written for an airlines, a feature of this version of the script temporarily halts the loading of the simulator so that one can look at the command box, that black box that hides behind the sim display, the one where you can get your errors: halts the sim so that one can look at this box and get the time the flight has taken so far, and to get the FUEL used amount so that the FUEL can be reset (if the plane you are flying will let you-otherwise record the amount for total calculation at end of flight) FUEL left in the plane if you are restarting mid flight.

Because the IAS is part of the set up, one could use RALPH to restart the sim at the last parking place. Because it is extending the usage of FGrun, one could change planes in mid flight, or make any other FGrun adjustment ( like said earlier with exception of Initial Position otherwise why use RALPH :) ) and then go back into the sim at the last known position.

If you look at that example Executable box just above you will see that it consists of the call to the PERL next the script PERL will use followed by the log-restart.csv file RALPH will use. So, if you save your log-restart.csv file, say you are practicing landings, you could fly out to where you want to begin your landing practice, pause or shut down the sim, go to your log-restart.csv file and save it as say "landing-practice.csv" and then change the name in the executable box from log-restart-csv to landing-practice.csv, and since landing-practice.csv will not get re-written every flight like log-restart.csv will, you can continually go back to were you want by restarting the simulator with the FGrun RUN button.

To redo a landing or otherwise re-wind a flight, you can take log-restart.csv and cut out a few minutes of entries and restart the sim and start over.

Some planes do not restart in air well. Some planes the engines have to be restarted. Often the landing gear needs to be retracted. You might like to reset the fuel amount if the plane will let you. If you are on a ROUTER route, this will have to be reloaded and pointed to the next waypoint. If you are using the autopilot, this too will have to be reconfigured. Sometimes its a good idea to hack the log-restart.csv file to add maybe a few thousand feet to the altitude for falling distance while the plane is restarted. Usually you can just let the sim load, hit the Pause, configure the plane, and the unpause and keep going.

We are hoping people more experienced with MAC loader and with FGo! will be able to read this and work out the convenience we experience using FGrun.

If there are any questions, need more clarity, just let me know.
Ray
Ray St. Marie
clrCoda
 
Posts: 1228
Joined: Wed Apr 07, 2010 11:04 am

Re: Possibility to Save a flight

Postby Hooray » Mon Aug 06, 2012 3:50 pm

Yes, that looks interesting - but it's just that, another workaround for a deeper issue actually.

Now, while this issue has been around for very long already, I wouldn't be too concerned actually.
It's pretty likely that this will get addressed "automatically" in the next 1-2.5 years, simply because there's a non-obvious relationship here:

  • for a long time, external frontends/launchers were used because the native FG GUI wasn't flexible enough
  • The new canvas system will be used to replace the built-in GUI
  • the new canvas-driven GUI (probably in FG 3.0) will be extremely flexible
  • in other words, it will be possible to implement GUI launchers directly in FlightGear, without external tools
  • now, the other major problem is the startup initialization code obviously
  • however, this will need to be addressed for the standalone FGCanvas mode, which is based on Torsten's FGPanel idea
  • also, many of the FDM-related issues will need to be sorted to fix and improve the replay system such that flights can be interrupted, saved and resumed at a later time - which is another long-standing request

In other words, during the next 24-36 months, many things will "automatically" fall into place because of the canvas system, and because of the FGPanel/FGCanvas approach, which is all about providing a separate "standalone" startup mode for instruments, which will inevitably require addressing the initialization issue, so that allowing aircraft to be restarted and switched at run time would no longer be too difficult.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11472
Joined: Tue Mar 25, 2008 8:40 am

Next

Return to New features

Who is online

Users browsing this forum: No registered users and 1 guest