


In order to communicate with the flight simulator, FlightGear has to be started with the following command line options:įgfs.exe -fg-root=SOME.PATH -fg-scenery=SOME.PATH -props=PORT-A -httpd=PORT-B Functions for other purposes can be easily implemented by using the same type of socket connection. The functions were written for the simulation of routing algorithms in Matlab. Speeds up FlightGear's simulation speed by a factor. Inserts waypoint/s (Latitude, Longitude, Altitude ) at certain position of current route. Reads number of remaining waypoints on the current route. Reads distance of aircraft from current waypoint in sea miles and converts it to meters. Reads FlightGear's simulation time in seconds. Reads aircraft position and orientation (Latitude, Longitude, Altitude, Ground elevation, Heading, Pitch, Yaw, Roll ). The ZIP-file contains a library of Matlab functions to remotely control an aircraft's path in FlightGear:Īctivates Autopilot and sets target speed.Īdds waypoint/s (Latitude, Longitude, Altitude ) after last entry of current route.ĭeletes all waypoints of the current route. command interface /autopilot/route-manager/input: This control interface is implemented beginning in flightgear/flightgear/next/src/Autopilot/route_mgr.cxx#l688: Once some FlightGear system writes to such a listened-to property, the registered callbacks of the route manager system are automatically invoked by the listener to process, validate and handle the "command" properly. This is very much similar to Qt's signals/slot mechanism.
#Flightgear route manager code#
This means that C++ code can be easily invoked by setting a bunch of "control properties", to which the route manager subsystem holds registered listeners. In addition, the route manager system also implements the interface of the SGPropert圜hangeListener SimGear class to create a property-tree based control interface on top of the property tree.

SGPath path(arg->getStringValue("path")) Īs can be seen here, all commands follow a fairly similar pattern: Static bool commandLoadFlightPlan(const SGPropertyNode* arg)įGRouteMgr* self = (FGRouteMgr*) globals->get_subsystem("route-manager") So, if you haven't already, it's a good idea to first read Howto: Add new fgcommands to FlightGear. These "commands" are pretty much standard fgcommands, so they have the standard fgcommand signature. the commands plain text name) to a C++ callback function.

The addCommand() method merely maps an ASCII string (i.e. SGCommandMgr::instance()->addCommand("delete-waypt", commandDeleteWaypt) SGCommandMgr::instance()->addCommand("insert-waypt", commandInsertWaypt) SGCommandMgr::instance()->addCommand("set-active-waypt", commandSetActiveWaypt) SGCommandMgr::instance()->addCommand("clear-flightplan", commandClearFlightPlan) SGCommandMgr::instance()->addCommand("activate-flightplan", commandActivateFlightPlan) SGCommandMgr::instance()->addCommand("save-flightplan", commandSaveFlightPlan) SGCommandMgr::instance()->addCommand("load-flightplan", commandLoadFlightPlan)
#Flightgear route manager full#
For example, this would enable Scripted AI Objects to use full FDM implementations and/or built-in route manager systems. The FlightGear/ SimGear code base already contains fairly generic and efficient systems and helpers, implemented in C++, that merely need to be better generalized and exposed to Nasal so that they can be used elsewhere. It will also help to unify duplicated code. This is primarily to help reduce Nasal overhead (especially GC overhead). Note Whenever possible, please refrain from modeling complex systems, like an FDM, autopilot or Route Manager with Nasal.
