Hey all,I was wondering if anyone had any previous experience with controlling FlightGear with an external application. We are attempting to use FlightGear as the visual end of a physical flight simulator and we are interested in creating an operator application that can control starting and stopping the simulation, setting different simulation options (thermals, time limit for simulation, weather, wind), etc.I envision booting up FlightGear once, and then controlling the simulator with the external application from that point forward. We are especially interested in allowing the external app to start/stop the running of the simulation (but not necessarily launching or exiting FG).I've read some things about Perl scripts, nasal scripts, and network interfaces to FG, but haven't found anything really helpful yet.Please let me know if anyone has any suggestions or ideas.Thanks!-Stefan

>Hey all,>>I was wondering if anyone had any previous experience with>controlling FlightGear with an external application.Depending on the scope of your application this is to some extent already possible.>We are>attempting to use FlightGear as the visual end of a physical>flight simulator and we are interested in creating an operator>application that can control starting and stopping the>simulation, setting different simulation options (thermals,>time limit for simulation, weather, wind), etc.yes, that's indeed possible, most of these settings are runtime-configurable via the so called "property tree", which you can access directly using the in-built property tree browser, or alternatively using various included network mechanisms/protocols, the property tree itself is also exposed via a HTTP interface, so that you can connect to FlightGear using an arbitrary browser in order to poll/set values.Likewise, the property tree is also exposed via shell-like telnet service that you can also use to get/set runtime variables as well as run most in-built fgcommands.You might want to run:fgfs --help --verbosein order to get an impression of the various startup parameters that are already supported.>I envision booting up FlightGear once, and then controlling>the simulator with the external application from that point>forward. We are especially interested in allowing the>external app to start/stop the running of the simulation (but>not necessarily launching or exiting FG).Most of what you seem to be envisioning is indeed already possible (indeed, you can easily exit FG using the corresponding fgcommand), however there are some limitations concerning the functionality that may be accessible in general, for example it is still not conveniently possible to reliably change aircraft at runtime.If you are mainly looking into changing simulator state variables, however this is extremely straight forward using the aforementioned property tree interfaces, simply because most state variables are already exposed via the property tree (and you can easily export new ones), thus you can simply set a state variable to true/false in order to change the status of the sim (i.e. in order to pause the simulation). Likewise, you can also easily provide your own FDM using a network interface.>I've read some things about Perl scripts, nasal scripts, and>network interfaces to FG, but haven't found anything really>helpful yet.Well, then you have most likely not checked out the included documentation, which can be found under $FG_ROOT/Docs, in particular you will want to check out the following files:README.introductionREADME.propertiesREADME.IOREADME.protocolREADME.commandsConcerning Perl scripts: if you check out the source code, you will find a "scripts" directory containing various examples about how to interface with the FlightGear property tree using programming languages such as Perl, Python or Java.Nasal itself however is not an external programming language in itself, rather it is the FlightGear scripting language that is embedded in FlightGear itself, so if you intend to control FG externally, you will probably not really want to use FG-internal Nasal scripts.>Please let me know if anyone has any suggestions or ideas.Actually, there's meanwhile lots of information available about this specific topic, I encourage you to 1) check out the docs 2) search this forum, 3) search the FlightGear mailing lists.Also, you might want to provide more detail about the sort of application you are developing, so that we can make more informed recommendations concerning the potential approaches.

To search this forum:http://forums.avsim.net/dcboard.php?az=sea...elect_forum=198To search the (old) Devel mailing list:http://marc.theaimsgroup.com/?l=flightgear-devel&r=1&w=2Relevant *forum* discussions:http://forums.avsim.net/dcboard.php?az=sho...=1086&mode=fullhttp://forums.avsim.net/dcboard.php?az=sho...d=842&mode=fullhttp://forums.avsim.net/dcboard.php?az=sho...d=249&mode=fullAs mentioned before, documentation available via:$FG_ROOT/Docs$FG_SRC/docs-miniwhereas, "$FG_ROOT" refers to the base package (data) directory and $FG_SRC to the directory structure from the source tarball.Interfacing examples can be found in the following folders:$FG_SRC/scripts/example (C, C++)$FG_SRC/scripts/perl (Perl)$FG_SRC/scripts/python (Python)$FG_SRC/scripts/java (Java)Also, $FG_SRC/utils contains smaller programs that you may find useful.In general, you will probably simply want to fire up FlightGear with the telnet service running, afterwards you can simply connect to FlightGear using arbitrary programs in order to access the same state variables that are also available via the property tree browser. If you also want to use a custom FDM, you will probably want to use the NULL fdm in order to make FlightGear disable its own FDMs, so that you can simply feed in your own data directly, without interfering with the in-built FDMs.However, please note that you might find the performance of the telnet service insufficient for more complex/more verbose tasks as it was not designed for high throughput, so you may find it necessary to make up your own protocols, either using the in-built XML configurable protocol mechanism ($FG_ROOT/Docs/README.protocol), or alternatively by manually adding a hardcoded C++ based protocol (check out the NetFDM example from $FG_SRC/example/netfdm).Even though the property tree itself is some aspects relatively cluttered, it is generally pretty structured so important properties are usually grouped into logical categories (paths/folders) and names are chosen to be pretty self-explanatory, also browsing the property tree at runtime while flying (i.e. on autopilot) is also pretty enlightening as you see what properties are modified by certain actions/conditions.

Thanks very much for the good advice.As to more info about the application, we are interested in creating a seperate operator interface that would be visible on a different monitor for someone to control the flight simulator, while another person is sitting and viewing the pilot interface. Therefore we are looking into creating some sort of GUI interface, where certain simulation properties can be set. But mainly, we want to be able to start and stop the simulation from the operator's interface. I know you can launch the program from the command line, but we want to be able to start and stop the actual flying once the program is launched.Thinking about writing an external program that could pass start/stop messages to FlightGear telling it when to start/stop the actual flying of the plane. Possibly through sockets?Any more thoughts are appreciated.-Stefan

>As to more info about the application, we are interested in>creating a seperate operator interface that would be visible>on a different monitor for someone to control the flight>simulator, while another person is sitting and viewing the>pilot interface.Sounds as if you are trying to write some sort of observer/instructor console?What functionality do you specifically intend to implement? >Therefore we are looking into creating some>sort of GUI interface, where certain simulation properties can>be set.Depending on the scope of your application (i.e. do you want to display a real-time moving map?) there are various possibilities, a good start for an "instructor station"-like program might be atlas: http://atlas.sourceforge.net which is a moving map application that can be fed with data from FlightGear.Thus, an operator/instructor could also directly see the position/heading of the student/pilot.However, if you do intend to write a somewhat less complex GUI frontend, you could probably simply use a scripting language such as Perl,TCL/TK,Python/QT in order to quickly come up with a convincing external GUI. Depending on whether you ultimately intend to possibly contribute your work back to the FlightGear project, you might also want to take into consideration that any coding should be conducted with multi-platform'ness in mind. Thus, a scripted approach is probably a good compromise between rapid application development and portability.On the other hand, if you do plan to implement the frontend using C/C++, there are also various possibilities to create a multi-platform GUI, i.e. using toolkits such as FLTK (http://www.fltk.org), wxWidgets, or QT.>But mainly, we want to be able to start and stop the>simulation from the operator's interface.>I know you can launch the program from the command line, but we want to be>able to start and stop the actual flying once the program is>launched.Seems to me you are mainly looking for a possibility to pause the sim at runtime from an external application? You can already do this easily by simply setting the corresponding property, i.e. by issuing the following command using the telnet interface:set /sim/master/freeze true>Thinking about writing an external program that could pass>start/stop messages to FlightGear telling it when to start/stop the actual flying of the plane. >Possibly throughsockets?>>Any more thoughts are appreciated.As I said already:1) start up FlightGear so that its in-built telnet server is enabled: --telnet=55002) wait for FlightGear to start up3) connect to FlightGear using a standard telnet client: telnet localhost:55004) type 'help' to get a listing of available commands5) issue: "set /sim/master/freeze true" to pause the simulator6) unpause the simulator by setting the same property to false

Thanks for being so helpful. Those are all great ideas, especially the mapping aspect, we were kind of envisioning something like that as well. I'm brand new to FlightGear, and all these ideas seem like great starting points to work from.Thanks so much for your advice, and I'll be sure to post anything interesting that we come up with.-Stefan

>I know you can>launch the program from the command line, but we want to be>able to start and stop the actual flying once the program is>launched.I think you were getting me wrong jere: I only recommended to check out the documentation as well as running# ./fgfs --help --verbose...in order to see what sort of STARTUP parameters are available that would ultimately also affect the simulator at runtime. That is, as a new FlightGear user you are not that likely to actually know of the various command line parameters available, if you are not using any sort of GUI launcher to start FlightGear. However, if you do run fgfs to output its parameter list, you will also see that there are various different I/O modes supported (httpd, telnet, atlas etc.).

>Thanks for being so helpful.Those are all great ideas,>especially the mapping aspect, we were kind of envisioning>something like that as well. I'm brand new to FlightGear, and>all these ideas seem like great starting points to work from.If you check out Atlas at http://atlas.sourceforge.net you will see that it is indeed very well suited to be used as a framework for an instructor/obvserver station, where the mapping aspect is usually one of the more complex ones. Besides, atlas itself is already written with portability in mind, so it would be straight forward to keep doing so.Basically, the only thing you might immediatley want to add would be an integrated telnet client (this can be accomplished using PLIB's netchat object), so that you can issue commands to FlightGear, i.e. in order to configure environmental settings (such as winds, temperature, clouds etc.) or in order to change/reset the runway/position, daytime.FlightGear itself also supportes a so called "raw" mode for the specific purpose of automated telnet access, so that you do not have to do any complicated parsing when you set properties in order to fail a piece of equipment such as cockpit instruments, engines, flaps or the navcom.Of course, directly issuing telnet commands manually would probably become somewhat inconvenient for an instructor sooner or later, so you might want to sort of save frequently used properties (i.e. via some sort of history buffer) or later on, possibly even map such properties/macros to certain buttons/action, i.e. a "winds" button to configure the winds, a "temperature" button to modify the temperature etc.If you do intend to head towards a instructor station, most instructor stations for professional simulators also feature a profile view, this is something that Atlas does not yet support.So, Atlas might probably benefit from a corresponding vertical profile view in that case, so that the flight path can be depicted with regard to the underlying terrain, which would also add the possibility for instructors to do evaluations based on AGL altitude/terrain height (i.e. approach evaluation).Depending on the level of usability you envision, you might also want to have some sort of "overview" page, where all configurable properties are directly visible or at least accessible, so this is where some sort of GUI library/toolkit would come in:. Atlas itself uses the same GUI library as FlightGear: PLIB's PUI: http://plib.sourceforge.net, this is a pretty simplistic widget library that contains only very basic controls (i.e. labels, buttons, text fields, check boxes, radio buttons), however it is highly portable (using OpenGL) and is known to work pretty well on all platforms supported by FlightGear. So, depending on the level of "eyecandyness" that you envision, you might find PLIB's PUI sufficient or not, simply check out FlightGear and Atlas in order to get an impression of PUI's capabilities.On the other hand, actually keeping PUI would have the potential benefit of being able to re-use much of FlightGear's highly flexible GUI code (if you are interested in a dynamically configurable GUI): in large part, FlightGear itself makes no longer directly use of PLIB's GUI library PUI, rather FlightGear uses an wrapper that allows people/NON-PROGRAMMERS to easily create GUI elements (menubars, dialogs, controls) using an XML-oriented approach (similar to, but significantly less complex and feature-rich than Mozilla's XUL).That is, in order to add new GUI dialogs to FlightGear, you do not necessarily have to modify the (C++) source code, rather you can simply create an XML based dialog file (as explained in $FG_ROOT/Docs/README.gui, $FG_ROOT/Docs/README.layout) and put it under $FG_ROOT/gui/dialogs, afterwards the corresponding PUI dialog can be dynamically created at runtime. The same approach is taken for the menubar in FlightGear, which is also dynamically created using the file $FG_ROOT/gui/menubar.xml. So, this makes FlightGear's GUI not only very extendable but also pretty maintainable.So, if you would like to reduce the amount of C++ coding and would also like to increase the flexibility of your application (updates to dialog files do not require a recompilation of the executable in order to take effect), make sure to actually look into the approach FlightGear has taken to feature a non-hardcoded and very flexible GUI.Concerning the amount of state variables that you hope to ultimately provide a GUI for, you might also want to think about the various possible approaches regarding the method of reading/setting these variables:While it is indeed possible to quickly write up your own I/O protocols using the aforementioned XML configurable protocol mechanism (without doing any C/C++ coding on the FG side of things!), this mechanism is mainly meant to provide regular updates for crucial runtime variables-meaning that the simulator will permanently send/receive the corresponding properties, so polling variables that may not be relevant would only increase bandwidth usage unnecessarily.So, for some sort of "instructor/observer-station" this would probably not really be desirable and would possibly also slow down the simulator itself in the end.Thus, only specific and crucial data should be polled at regular intervals (intervals are customizable, either by providing a custom hz number at startup, or by harcoding the interval in), all other data should only be polled on demand. So, while it may be important to continually update data such as:- aircraft heading- aircraft altitude- aircraft IAS/TAS/GSother data such as:- aircraft configuration (flaps, gear)- bearing to navaids- distance to/from airportshould only be retrieved under certain circumstances, in order not to negatively influence the simulator's performance.Finally, note that some of your more specific questions are probably better asked on the FlightGear (or Atlas) mailing lists, as only few people are actually using these forums to get/provide support. So, whenever you're stuck, make sure to consult the mailing lists.