Generic attributes and parameters are a way of accessing extended information in your FOM that is not normally supported.

For example, suppose your FOM, based on RPR contains an extra attribute on entity objects called "RadarSignature". Once generics are enabled in VR-Link, all you have to do is ask for your data:

int size;

const char* val = entity->stateRep()->getAttributeByName("RadarSignature", size, entity->hlaObject());

Interactions work in a similar manner:

val = fireInteraction->getParameterByName("RadiationEmitted", size);

There is no longer a need to write a code generator, or to hand model anything. Getting (and setting) your new attributes is simple and effective.

There are two ways to enable generics. The first is the easiest. If you enable generics in your initializer, all unknown attributes will be automatically handled:

appInit.setGenericAttributes(true);

Alternatively, you can choose to only decode generics on single classes, which might be faster than decoding every entity:

DtInterClassDesc* interClass = exConn.fom()->interClassByName("WeaponFire");

interClass->enableUnknownParameters();

Previous versions of VR-Link already supported generic handling of new classes using DtUnknownInteraction and DtUnknownHlaObject. With VR-Link 5.1, you can have hybrid objects, where some are known and some are generic.

So why would you not just use generics? Generic attributes do not have type safety. They are only sent and received as byte arrays and it is up to you to encode and decode them correctly. For attributes that VR-Link knows, this is handled for you already, letting you deal with the data in a more natural form. The same situation applies to code generated objects. However, there are many situations where this might be more work than necessary, and generics let you work with your data as fast as you can change your FOM.

[<< Using the DtInteraction Class] [Home] [Top of Page] [General HLA Issues >>]