From: Petr G. <pet...@ce...> - 2009-06-26 10:10:05
|
Hello, 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 argument. ;-) 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. I'm building a FlightGear interface for M&S HLA simulations (http://virtualair.sourceforge.net/flightgear.html). There is a single standartized C++ API, but many HLA infrastructure (RTI) implementations. To use a particular HLA RTI it's necessary to re-compile and re-link FlightGear against a particular set of libraries. Thus there can never be a single "HLA compliant" FlightGear binary. 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 M&S HLA users would just need to build a shared module (.dll or .so) for a particular HLA RTI and load it via the standard FlightGear plug-in interface. If I discuss the design issues with you, implement and test such interface, would you accept such interface for the mainline FlightGear? Regards, Petr |
From: Petr G. <pet...@ce...> - 2009-06-26 11:57:02
|
>>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 M&S HLA users would just need to build a shared module (.dll or .so) for a particular HLA RTI and load it via the standard FlightGear plug-in interface. > >Erik wrote: >Adding a plug-in interface instantly raises questions about GPL >compatibility which have to be addressed prior to implementing such a >thing. I believe the question did come up several times before but the >possibility to easily violate the GPL was always a too big a hurdle to >continue. Let me advocate the idea: I'm proposing a generic interface. If you look from the other side, it's a possibility to easily implement a new I/O module for FlightGear. To help people that might be interested to extend FlightGear but do not want to recompile the whole binary. I personally believe that the number of nice users scared away is higher than the number of new GPL violating users. Especially because commercial/proprietary users may use X-Plane. Every coin has two sides: - Not every I/O module will violate the GPL - Not every nice (non GPL violating) user interested in extending FlightGear is able/willing to build the whole binary - Only some of the users will violate GPL - Generic interface simplify/facilitate FlightGear extensibility for all users (both nice and GPL violating) - People don't need the generic interface to violate the FlightGear GPL - The generic interface doesn't have to be included in the mainline CVS - Including the interface in mainline CVS helps all users (both nice and GPL violating) Petr |
From: Rob S. Jr. <rm...@ya...> - 2009-06-27 04:38:00
|
Hello all... Somehow, when updating my FG installation on Vista using Fred's 6/23 build, I can no longer start Dave Culp's T2C. I also tried a couple of his other planes and got similar results. However, loading up several other aircraft models (both YASim and JSBSim) was successful. Below you'll find my command line (generated by FGRun) followed by the console error message. Cheers, -R. (MD-Terp) Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@um... ================================================================================ C:\Program Files\FlightGear\bin\Win32\fgfs.exe --fg-root=C:\Program Files\FlightGear\data --fg-scenery=C:/Program Files/FlightGear/Scenery-1.0.1 --airport=KHAF --aircraft=T-2C --control=joystick --disable-intro-music --enable-mouse-pointer --enable-random-objects --disable-specular-highlight --enable-ai-models --enable-real-weather-fetch --prop:/sim/frame-rate-throttle-hz=20 --bpp=32 --callsign=MD-Terp --multiplay=out,10,mpserver01.flightgear.org,5000 --multiplay=in,10,RMSJR-D,5000 --ai-scenario=nimitz_demo --ai-scenario=vinson_demo --prop:/sim/view/config/limits/enabled=false --prop:/sim/view/config/default-field-of-view-deg=65 --prop:/sim/ai-traffic/enabled=false --prop:/sim/traffic-manager/enabled=false --prop:/sim/atc/enabled=false ================================================================================ Property systems/hook/tailhook-cmd-norm is already defined. Property systems/NWS/engaged is already defined. WARNING: JS: Failed to read joystick name from registry FGPropertyManager::GetNode() No node found for systems/canopy/command In component: Canopy Control unknown property systems/canopy/command reference d. Aborting |
From: Petr G. <pet...@ce...> - 2009-07-01 14:30:05
|
Hi Mathias, 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 in a way that you do not >need to recompile anything. Everyting is done with pure virtual classes and >factories to get them. So however this is implemented in the shared object/dll >you should just need to get a 'standard' implementation dependent RTI header >and compile with that. So you should in theory be able to change the RTI >library of an already compiled binary. The "basic" HLA standard (both DoD and IEEE variant) provides only a C++ API compatibility at a compile-level. There is a SISO standard that should assure dynamic link compatibility (DLC). However, some RTI libraries may not be compliant to the SISO standard. >For the case that a particular RTI implementation does not follow this rule, >you need to compile flightgear explicitly for this particular library. I >believe that this is accaptable. Not for me. :-( >Regarding the different foms: >I have seen your implementation and what I believe we can do more generic. >Sure there is a part of your implementation that hard codes some attribute >names of the foms into the binary. But this could be done in a more generic >way, so that you can configure the attributes meanings at runtime instead. >With this model, your two hardcoded implementaiton stubs for the those two >fom's will be just a special configuration using the same c++ implementation. I've been thinking about this a lot. There is no simple mapping between FlightGear and FOM parameters. Sometimes it's necessary to translate units, geodetic/geocentric frames or perform other calculations. The generic mapping engine would have to be a very powerful scripting language like Nasal or Python. I've decided to start with a simple hardcoded interface and investigate all FOM attributes and interactions that may be supported by FlightGear/HLA. After we understand all possible features of the FlightGear/HLA interface, we will reconsider implementing the generic interface. Of course, unless somebody volunteers to implement it right now. ;-) >I for myself would like to have such a flexible implementation at hands. > >So all together I would prefer to include a more generic HLA/RTI >implementaiton in flightgear than introduce a plugin mechanism. Yes, it would be nice to have a generic HLA/RTI implementation. From the cost-benefit ratio perspective, a plug-in mechanism will significantly simplify the use of the hardcoded interface, so the need for the generic implementation is not so urgent. And it's much easier to implement a plug-in mechanism, than the HLA/RTI interface. Best Regards, Petr |
From: Mathias F. <Mat...@gm...> - 2009-07-09 05:15:59
|
Hi, So sorry for the long delay. On Wednesday 01 July 2009 16:29:23 Petr Gotthard wrote: > The "basic" HLA standard (both DoD and IEEE variant) provides only a C++ > API compatibility at a compile-level. There is a SISO standard that should > assure dynamic link compatibility (DLC). However, some RTI libraries may > not be compliant to the SISO standard. Ok. > >Regarding the different foms: > >I have seen your implementation and what I believe we can do more generic. > >Sure there is a part of your implementation that hard codes some attribute > >names of the foms into the binary. But this could be done in a more > > generic way, so that you can configure the attributes meanings at runtime > > instead. With this model, your two hardcoded implementaiton stubs for the > > those two fom's will be just a special configuration using the same c++ > > implementation. > > I've been thinking about this a lot. There is no simple mapping between > FlightGear and FOM parameters. Sometimes it's necessary to translate units, > geodetic/geocentric frames or perform other calculations. The generic > mapping engine would have to be a very powerful scripting language like > Nasal or Python. I've decided to start with a simple hardcoded interface > and investigate all FOM attributes and interactions that may be supported > by FlightGear/HLA. After we understand all possible features of the > FlightGear/HLA interface, we will reconsider implementing the generic > interface. Of course, unless somebody volunteers to implement it right now. > ;-) Well, I have code here that would at least cover those cases that you have already hard coded in your two fom implementation backends. As soon as I have something ready to try I will send that to you. I am sure that such a thing is much more convenient to use with different foms than something you need to recompile. Regarding the different binaries, you will just need to have so much versions of flightgear compiled from the same source and with different rti's available than you have RTI's. And since changes in the handling of FOM's would not need a recompile at all, I can think of this being also more convenient for your use case. > >I for myself would like to have such a flexible implementation at hands. > > > >So all together I would prefer to include a more generic HLA/RTI > >implementaiton in flightgear than introduce a plugin mechanism. > > Yes, it would be nice to have a generic HLA/RTI implementation. From the > cost-benefit ratio perspective, a plug-in mechanism will significantly > simplify the use of the hardcoded interface, so the need for the generic > implementation is not so urgent. And it's much easier to implement a > plug-in mechanism, than the HLA/RTI interface. Not sure about that. I expect to have something in the not so far future. Greetings Mathias |
From: Erik H. <er...@eh...> - 2009-06-26 10:39:24
|
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 M&S HLA users would just need to build a shared module (.dll or .so) for a particular HLA RTI and load it via the standard FlightGear plug-in interface. Adding a plug-in interface instantly raises questions about GPL compatibility which have to be addressed prior to implementing such a thing. I believe the question did come up several times before but the possibility to easily violate the GPL was always a too big a hurdle to continue. Erik |
From: Erik H. <er...@eh...> - 2009-06-26 12:08:57
|
Petr Gotthard wrote: > Let me advocate the idea: > I'm proposing a generic interface. If you look from the other side, it's a possibility to easily implement a new I/O module for FlightGear. To help people that might be interested to extend FlightGear but do not want to recompile the whole binary. > > I personally believe that the number of nice users scared away is higher than the number of new GPL violating users. Especially because commercial/proprietary users may use X-Plane. > > Every coin has two sides: > - Not every I/O module will violate the GPL > - Not every nice (non GPL violating) user interested in extending FlightGear is able/willing to build the whole binary > - Only some of the users will violate GPL > - Generic interface simplify/facilitate FlightGear extensibility for all users (both nice and GPL violating) > - People don't need the generic interface to violate the FlightGear GPL > - The generic interface doesn't have to be included in the mainline CVS > - Including the interface in mainline CVS helps all users (both nice and GPL violating) 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. Erik |
From: Gene B. <ge...@de...> - 2009-06-26 13:08:59
|
> 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. > Even in the case of a seperately compiled shared library or DLL? I have my doubts. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! |
From: Petr G. <pet...@ce...> - 2009-06-26 14:18:08
|
>> 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. >> >Even in the case of a seperately compiled shared library or DLL? I have >my doubts. GPL does not make shared libraries illegal. Creating GPL'ed libraries, connected to GPL'ed applications does not violate GPL. The GPL is violated if someone refuses to publish source codes of this library. I'm not proposing to use plug-ins with other license than GPL. Since FlightGear is GPL'ed, all plug-ins must be GPL'ed as well. This is out of question. I just propose to enable GPL'ed libraries to get connected to FlightGear without building the whole FlightGear binary. Petr |
From: Jon S. B. <jon...@co...> - 2009-06-27 05:12:41
|
This looks like a side effect of the newer way of interpreting/defining/using properties in the latest JSBSim. I have not seen Dave's TC2 model. Where can I find that? I might be able to help. Jon Jon S. Berndt Development Coordinator JSBSim Project www.JSBSim.org From: Rob Shearman, Jr. [mailto:rm...@ya...] Sent: Friday, June 26, 2009 11:38 PM To: FlightGear developers discussions Subject: [Flightgear-devel] Incompatibility with win32 CVS build 6/23 and Dave Culp's planes... Hello all... Somehow, when updating my FG installation on Vista using Fred's 6/23 build, I can no longer start Dave Culp's T2C. I also tried a couple of his other planes and got similar results. However, loading up several other aircraft models (both YASim and JSBSim) was successful. Below you'll find my command line (generated by FGRun) followed by the console error message. Cheers, -R. (MD-Terp) Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@um... ============================================================================ ==== C:\Program Files\FlightGear\bin\Win32\fgfs.exe --fg-root=C:\Program Files\FlightGear\data --fg-scenery=C:/Program Files/FlightGear/Scenery-1.0.1 --airport=KHAF --aircraft=T-2C --control=joystick --disable-intro-music --enable-mouse-pointer --enable-random-objects --disable-specular-highlight --enable-ai-models --enable-real-weather-fetch --prop:/sim/frame-rate-throttle-hz=20 --bpp=32 --callsign=MD-Terp --multiplay=out,10,mpserver01.flightgear.org,5000 --multiplay=in,10,RMSJR-D,5000 --ai-scenario=nimitz_demo --ai-scenario=vinson_demo --prop:/sim/view/config/limits/enabled=false --prop:/sim/view/config/default-field-of-view-deg=65 --prop:/sim/ai-traffic/enabled=false --prop:/sim/traffic-manager/enabled=false --prop:/sim/atc/enabled=false ============================================================================ ==== Property systems/hook/tailhook-cmd-norm is already defined. Property systems/NWS/engaged is already defined. WARNING: JS: Failed to read joystick name from registry FGPropertyManager::GetNode() No node found for systems/canopy/command In component: Canopy Control unknown property systems/canopy/command reference d. Aborting |
From: Rob S. Jr. <rm...@ya...> - 2009-06-27 14:59:16
|
http://home.comcast.net/~davidculp2/hangar/hangar.html "North American T-2C Buckeye" Not counting DavePack (the instrument models), it's the 13th aircraft from the top. But as I said, I started up a couple other of his models (the A-29B, I think, and one of the F-4's, I forget which) and got identical results. Thanks for looking into it. I guess you'll want to contact him with the results. His e-mail info is on that website as well. Cheers, -R. Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@um... ________________________________ From: Jon S. Berndt <jon...@co...> To: FlightGear developers discussions <fli...@li...> Sent: Saturday, June 27, 2009 1:12:36 AM Subject: Re: [Flightgear-devel] Incompatibility with win32 CVS build 6/23 and Dave Culp's planes... This looks like a side effect of the newer way of interpreting/defining/using properties in the latest JSBSim. I have not seen Dave’s TC2 model. Where can I find that? I might be able to help. Jon Jon S. Berndt Development Coordinator JSBSim Project www.JSBSim.org From:Rob Shearman, Jr. [mailto:rm...@ya...] Sent: Friday, June 26, 2009 11:38 PM To: FlightGear developers discussions Subject: [Flightgear-devel] Incompatibility with win32 CVS build 6/23 and Dave Culp's planes... Hello all... Somehow, when updating my FG installation on Vista using Fred's 6/23 build, I can no longer start Dave Culp's T2C. I also tried a couple of his other planes and got similar results. However, loading up several other aircraft models (both YASim and JSBSim) was successful. Below you'll find my command line (generated by FGRun) followed by the console error message. Cheers, -R. (MD-Terp) Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@um... ================================================================================ C:\Program Files\FlightGear\bin\Win32\fgfs.exe --fg-root=C:\Program Files\FlightGear\data --fg-scenery=C:/Program Files/FlightGear/Scenery-1.0.1 --airport=KHAF --aircraft=T-2C --control=joystick --disable-intro-music --enable-mouse-pointer --enable-random-objects --disable-specular-highlight --enable-ai-models --enable-real-weather-fetch --prop:/sim/frame-rate-throttle-hz=20 --bpp=32 --callsign=MD-Terp --multiplay=out,10,mpserver01.flightgear.org,5000 --multiplay=in,10,RMSJR-D,5000 --ai-scenario=nimitz_demo --ai-scenario=vinson_demo --prop:/sim/view/config/limits/enabled=false --prop:/sim/view/config/default-field-of-view-deg=65 --prop:/sim/ai-traffic/enabled=false --prop:/sim/traffic-manager/enabled=false --prop:/sim/atc/enabled=false ================================================================================ Property systems/hook/tailhook-cmd-norm is already defined. Property systems/NWS/engaged is already defined. WARNING: JS: Failed to read joystick name from registry FGPropertyManager::GetNode() No node found for systems/canopy/command In component: Canopy Control unknown property systems/canopy/command reference d. Aborting |
From: Mathias F. <Mat...@gm...> - 2009-06-28 09:54:21
|
Hi, So, since I wanted to get in touch with you anyway ... Good to hear from you! On Friday 26 June 2009 12:09:48 Petr Gotthard wrote: > 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 argument. ;-) > > 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. > > I'm building a FlightGear interface for M&S HLA simulations > (http://virtualair.sourceforge.net/flightgear.html). There is a single > standartized C++ API, but many HLA infrastructure (RTI) implementations. To > use a particular HLA RTI it's necessary to re-compile and re-link > FlightGear against a particular set of libraries. Thus there can never be a > single "HLA compliant" FlightGear binary. > > 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 M&S HLA users would just need to build a > shared module (.dll or .so) for a particular HLA RTI and load it via the > standard FlightGear plug-in interface. 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 in a way that you do not need to recompile anything. Everyting is done with pure virtual classes and factories to get them. So however this is implemented in the shared object/dll you should just need to get a 'standard' implementation dependent RTI header and compile with that. So you should in theory be able to change the RTI library of an already compiled binary. For the case that a particular RTI implementation does not follow this rule, you need to compile flightgear explicitly for this particular library. I believe that this is accaptable. Regarding the different foms: I have seen your implementation and what I believe we can do more generic. Sure there is a part of your implementation that hard codes some attribute names of the foms into the binary. But this could be done in a more generic way, so that you can configure the attributes meanings at runtime instead. With this model, your two hardcoded implementaiton stubs for the those two fom's will be just a special configuration using the same c++ implementation. I for myself would like to have such a flexible implementation at hands. So all together I would prefer to include a more generic HLA/RTI implementaiton in flightgear than introduce a plugin mechanism. Greetings Mathias |
From: Melchior F. <mf...@ao...> - 2009-06-28 10:30:35
|
I'm (still) against binary runtime modules for FlightGear. They are an invitation for circumventing the GPL, locking in users, and potentially harm cross-platformness. I find the prospect of a vendor offering a new device with closed source libraries for stock FlightGear worrying, and even more so if there's only a Windows DLL, but none for OSX and all the Unices/Linux. (Not that I'd want to run any secret binary blobs on my clean machine.) 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. That linking non-GPL modules would be illegal, anyway, doesn't make the situation any better. Unless you can offer us a *lot* of money, time and personnel for filing lawsuits. Otherwise the GPL protection is rather weak and only theoretical. We shouldn't encourage corporate entities to rip us off. m. |
From: Robin v. S. <sto...@st...> - 2009-06-28 18:13:27
|
Melchior FRANZ wrote: > I'm (still) against binary runtime modules for FlightGear. > I'm more curious as to whether we need them. The entire guts of FlightGear are available to almost anyone via external communications (e.g. sockets) and Nasal. Why not write a communications script or Nasal script that exposes the data required for your add-on over a socket, and use a similar tool at the add-on end? There is no license that will ever state that any application that *communicates* with it (whether it be a TCP socket, file, or Unix socket) needs to adhere to that license as well, since that would pretty much be the ultimate enforcement of copyleft. Simply put, the mechanics for doing this with FlightGear are already in place, you only need to take a slight detour over a communications link. This has its advantages too, such as added security (no possible code injection) and inherent networkability. Downside is that it takes a little more brain-food to make it work. |
From: Petr G. <pet...@ce...> - 2009-07-01 14:47:43
|
Hi, >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 extremely generous. In fact, this allows me to implement the generic plug-in interface and distribute the modified FlightGear along with my binary runtime modules that are all under GPL. >That linking non-GPL modules would be illegal, anyway, doesn't make >the situation any better. Unless you can offer us a *lot* of money, >time and personnel for filing lawsuits. Otherwise the GPL protection >is rather weak and only theoretical. We shouldn't encourage corporate >entities to rip us off. In my opinion not all commercial entities are trying to rip off open-source software. Both commercial entities and GPL software can benefit from each other if they are all fair. Which is not always true, I know. :-( Best Regards, Petr |