Am Montag 20 Dezember 2004 22:20 schrieb Jorge Van Hemelryck:
> ...
> 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

I'd go with option three. I see the FG core (the simulator itself) as an 
independent "demon".  Multiple 'control' clients can connect and interact 
with the FG server ('GUI', Atlas Moving Map, Flight Tutor*, Flight 
logger, ...). We might need a locking mechanism to have only 1 client writing 
properties though.

* some future app that gives remarks on flight performance, i.e. "Give 
attention to engine rpm", "More left rudder" (just an idea :-))

> ...
> 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.

That's a definite goal, to have a clean API to the simulator core, which is 
used by an internal as well as an external GUI.

> 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.



Flightgear-devel mailing list

Reply via email to