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#p94288viewtopic.php?f=17&t=8982&p=88427#p88427viewtopic.php?f=6&t=2916viewtopic.php?f=2&t=6894viewtopic.php?f=2&t=2897&p=25188viewtopic.php?f=2&t=3246redneck 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=16215kyokoyama 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.