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 ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
