Board index FlightGear Development

GUI for in-air startups/re-spawning and switching aircraft

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

GUI for in-air startups/re-spawning and switching aircraft

Postby Jabberwocky » 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.
Jabberwocky
Retired
 
Posts: 1316
Joined: Sat Mar 22, 2014 8:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: FlightGear GUI hell: PUI, Canvas GUI, Mongoose, Qt5 ??

Postby Hooray » Sat Jan 17, 2015 6:27 pm

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-init
http://wiki.flightgear.org/FlightGear_Sessions

Given 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_Replay

In fact, we have 2-3 programs using the props interface to remote-control FlightGear, e.g. see: http://wiki.flightgear.org/FGFSCopilot
Image

You could run a forum search for "FGFSCoPilot", and you'll find dozens of relevant postings: FGFSCopilot Hybrid

Thus, 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 ... ardization

there 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.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU


Return to Development

Who is online

Users browsing this forum: No registered users and 12 guests