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,

Flightgear-devel mailing list

Reply via email to