On Mon, 20 Dec 2004 13:04:47 -0600
Curtis L. Olson wrote:
> That certainly sounds doable, although the particular details of how to
> launch, and kill, and detect if the child process is running will
> probably vary wildly from platform to platform.
The only OS where I could do it would be Linux (I have done some
programming on Windows in the past, but not enough to be able to do
that). I thought that the way to do this would be the same on UNIX-like
systems, and that it would differ only on Windows...
Here are the ways of launching the simulator and the "FlightGear
Control" app I can think of:
1- the Control app launches and communicates with FlightGear, the latter
being for instance a child process (or fgrun could be extended to
communicate with FlightGear in this way)
2- FlightGear is launched at the same time as the Control app
3- FlightGear and the Control app can be run independently
With option 1, there are issues such as how to ensure that when FlightGear
exits, the Control app reverts to a launcher app.
Does option 2 mean that they have to be launched at the same time ?
Could we benefit from this ?
What is already clear is that FlightGear should not depend on this
Control app. It must be possible to run FlightGear from the command-line
without anything else. That is why I would be in favor of option 3.
Here is what is already possible with what we presently have. The
FlightGear telnet protocol allows an external program to get and set
properties. This already allows for environment / position / time /
radio / gps / view settings, to name a few.
The current gui (menubar) can do more than that, and in the future it
would probably a good thing to use the same API, in order for instance
to be able to launch a nasal command from the Control app.
As we said before, the main problem would be to change aircraft (and
therefore reinit FDM, 3D model, systems) without restarting FG. I'll try
and have a look at the initialization code as soon as I find some time.
Jorge Van Hemelryck
Flightgear-devel mailing list