Jabberwocky wrote in Sat Jan 17, 2015 5:46 pm:On the not so entirely GUI related front: I ran some little experiments with a Java-based test launcher to make the aircraft I launched reporting it's position to the java-program outside of FG. It'S part of thast not very mellowed SkyNet-approach, so nothing, that will be publicly available anytime soon, but the idea behind it could be used very well by others
launch a plane by starting FG as a sub-process with all the parameters (aircraft, airport, etc)
let the plane report a variable set of data (position, altitude, n1, n2, etc) all five seconds
In the launcher the last set of information is stored in a "session object"
If FG crashes, the launcher offers this data as "unclosed session" and if the user wants to continue, FG is spawned again, with an additional property that causes the plane-startup to set engines running, go on altitude and position again and continue where the last data was reported before the crash.
Well, obviously there are some problems still to overcome, for example, that planes need a plane-specific part integrated. However, it looks like, if that is done, and since a launcher has also access to other planes, this could be "abused" also for plane changes in the air. However, I did my experiments in Java and I know, this could easily cause a flamewar with the C++ disciples, I stopped there and if someone wants to implement it in C++, feel free (causes of course three different binaries again for Linux, Mac and Windows).
J.
Sorry, none of this is going to work for reasons that may not be obvious to you admittedly, but that are otherwise fairly well-documented (see the wiki).
FlightGear has roughly ~20 different GUI front-ends, including a few Java-based front-ends using IPC (sockets) for remote-controlling FlightGear to a similar degree.
Saving/loading and resuming flights is a completely different issue, that cannot be solved externallly, for explanations see:
http://wiki.flightgear.org/Reset_%26_re-inithttp://wiki.flightgear.org/FlightGear_SessionsGiven FlightGear's built-in restrictions, the best thing you could conceivably come up with using your approach is an external "flight recorder (replay system)":
http://wiki.flightgear.org/Instant_ReplayIn fact, we have 2-3 programs using the props interface to remote-control FlightGear, e.g. see:
http://wiki.flightgear.org/FGFSCopilotYou could run a forum search for "FGFSCoPilot", and you'll find dozens of relevant postings:
FGFSCopilot HybridThus, in summary, what you are envisioning is touching on quite a few hard-coded restrictions - e.g. the same ones responsible for the flight recorder not being able to resume JSBSim flights or startup profiles for aircraft not being supported at all:
http://wiki.flightgear.org/FDM_engine_f ... ardizationthere are people who've been working towards this for years, some of whom having been involved in the project for over a decade, intimately familiar with the SG/FG code base - while also with the overall FlightGear architecture - there really is no workaround here, what is currently done via external launchers/front-ends is what is technically possible, anything else requires refactoring efforts analogous to the ongoing reset/re-init work, that Zakalawe has been working on for 5+ years.