Dear FlightGear developers,(a short introduction first: I'm a newcomer to
FlightGear, my professional profile can be found at
http://www.linkedin.com/in/gotthard) May I ask whether you would be interested
on striving to make FlightGear compliant with the US DoD High Level
the HLA specifications (IEEE 1516) are not free, that's a disadvantage. However
there are open-source HLA run-time environments (e.g.
http://www.cert.fr/CERTI), so it's not necessary to implement whole new HLA
Regarding the multiplayer in FlightGear I see two
I'd like to bring up again the issue of standalone FlightGear modules (add-ons,
plug-ins). You probably hear this question once a while, but I have a new
Although the FlightGear design fairly modular it's provided as a single binary.
Everyone who wants to create a new I/O
Petr Gotthard wrote:
To follow the do things right rule I think it would be great to implement
a generic interface for standalone I/O modules. Both Micro$oft FSX and
X-Plane have such interface. The MS HLA users would just need to build a
shared module (.dll or .so) for a particular HLA RTI
All valid points but irrelevant for the GPL. It is already possible to
connect proprietary software to FlightGear using the generic binary
(socket) protocol handler, but that doesn't violate the GPL. Plug-in
interfaces tend to do because they are considered 'part of the program'
by the GPL.
Thank you very much for your comments.
So, as far as I knor HLA/RTI, your problem is divided in two parts:
1. The problem with different RTI implementation libraries.
2. The problem with different fom's
Regarding the RTI libs:
As far as I can see the RTI c++ interface is defined
I'm (still) against binary runtime modules for FlightGear.
And I respect that.
We offer more possibilities than X-plane and MSFS and all the others
put together -- by letting people look at/modify/redistribute our
source code. For free. That's very generous, if you ask me.
Yes, that is
Mail list logo