FlightGear plugins

See also Addon.

This article is a stub. You can help the wiki by expanding it.

Note  In its current form, this section/article is largely based on quotes collected from various related discussions/channels (devel list, forum etc) using the Instant-Cquotes script. Wiki users and other contributors are encouraged to help rewrite/edit contents accordingly to help get rid of unnecessary quoting (i.e. while the wiki is not intended to be a collection of quotes, quotes are sometimes the best/easiest way to bootstrap new articles, while also providing a good way to link back to related discussions in the archives). While rewriting usually only entails changing first person speech to 3rd person. However, please try to retain references/links to the original discussion whenever possible.

Work in progress This article or section will be worked on in the upcoming hours or days. See history for the latest developments.

Although the FlightGear design fairly modular it's provided as a single binary. Everyone who wants to create a new I/O module must patch the FlightGear sources and compile the FlightGear binary from scratch. This may discourage those who want to use FlightGear as a tool and extend it in some way. Moreover, it's not always possible to include all functions in a single binary. Some functions may be mutually exclusive. — Petr Gotthard (Jun 26th, 2009). [Flightgear-devel] [RFC] Dynamic plug-in interface for I/O modules. (powered by Instant-Cquotes)

• http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg37031.html
• http://www.mail-archive.com/flightgear-devel%40flightgear.org/msg37031.html

Background

There's been talk about binary 'modules' to be loaded optionally, so that you could have optional C++ functionality, but I don't think that's feasible just yet. — Thorsten (Dec 15th, 2015). Re: Military simulation (from Su-15 Screenshots). (powered by Instant-Cquotes)

Would it be possible to implement enough in the "core" or "official" software so that an externally distributed add-on "plugin" could add the functionality some people would like to see? Forgive the terminology, but I'm essentially just saying that for anyone that downloads FG from official sources it'd be a civilian sim, and if a smaller group wanted to dogfight etc they'd have to go outside to get the functionality - AND people in MP wouldn't see anything other than fighters flying around; i.e. no missiles flying, no planes disintegrating etc. — Lydiot (Dec 15th, 2015). Re: Military simulation (from Su-15 Screenshots). (powered by Instant-Cquotes)

its not that easy to get your changes into the system. I am not complaining about this and I acknowledge that changing the internal program is a thing that has to be carefully reviewed. Writing some Nasal code usually does not affect the whole system and can be maintained for a single aircraft. To make things easier for developers, can we think of a plug-in system for callbacks so a potential developer write a library that is linked in dynamically by the flightgear core? I think having a plug-in system for compiled/binary extensions whould give us great flexibility without touching the flightgear-core to heavily. — Torsten Dreyer (Oct 25th, 2007). Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes. (powered by Instant-Cquotes)

Rather than FlightGear embedding another language, FlightGear would probably benefit much better with a type of loadable module support. Nasal could become one of those modules along with Python and maybe Perl. Much in the same manner that Apache and Apache Modules work. I think that would greatly broaden the horion. Scripting would be just one type of module, the GUI could be another type which might make it easier to support QT or even Java, not to mention that the FDM code could become a separate module, one for each supported FDM. So in just discussing Python support we may be limiting ourselves and/or FlightGear . Should we be discussing Module support instead? Would that greatly reduce the core FlightGear code? Has module support been discussed before? — japreja (Dec 30th, 2015). Re: FGPython an propose for Python as an nasal alternative. (powered by Instant-Cquotes)

Proprietary modules

VATSIM/IVAO

My sense is that there are very few people who would outright oppose a vatsim interface to flightgear. I think most people would consider this is a good thing. Here is my question/concern. If some developer gets approved by vatsim and signs the appropriate NDA's and then builds an interface from vatsim to flightgear, then sure, that could be an external "closed source" application that bridges the communication gap between FlightGear and VATSIM. But here's the problem. Now anyone (good or evil) has a wide open, public, unsecured route into the vatsim network. The flightgear API's are open and you can inspect all the code and structures. So anyone could take the vatsim<->flightgear interface and leverage it to interject any kind of nonsense into the vatsim network. This is exactly what vatsim is trying to avoid by protecting their communication protocols. As soon as they allow a translator to be written with an open/published/documented protocol at the other end ... this is the very next best thing for someone wanting to do mischief. Please notice: this isn't me being negative about vatsim, or being negative about the idea of a vatsim interface for flightgear. I'd personally love to have it available one way or another. But I'm trying to place myself in the perspective of what the vatsim folks would think. Hopefully I'm way wrong, but if we lay it all out for them open and honestly up front so we aren't trying to sneak something past them, what do you think they would say? FlightGear doesn't have a binary plug in system so it's not possible for someone to write a closed source plugin to implement the vatsim protocol. It would have to be done as an entirely open-source module within FlightGear, or as an entirely separate external application that communicates with flightgear through some network protocol. So all that said, here's one more thing to ponder. FlightGear is a volunteer driven project. The people that pitch in and do the work get to decide what they will work on and how they will do it. We can discuss vatsim back and forth all day long, but until a volunteer steps forward who's willing (and able) to build the vatsim interface to flightgear, and who is willing to sign all the vatsim nda's, and who is willing to do whatever discussion and negotiation and strategiing and design work that is required to make the system function satisfactorily from the perspective of both vatsim and flightgear ... until such a person emerges, really all we can do is talk about it theoretically. — Curtis Olson (Jan 26th, 2011). Re: [Flightgear-devel] VATSIM support?. (powered by Instant-Cquotes)