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 ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
