This mode must be preferred for 1516 and large Federations.
The Wizard can then be used and will reduce the coding effort.
This mode relies on data structures generation extracted from the Federation definition.
It also can work with user defined data structures if these one matches their RTI counterpart.
With 1516 Federations, vsTASKER produces the OMT like objects that correspond to the Federation definitions.
It is then possible to make C++ data structures based on these definitions, in order to directly use them into the code.
Attaching a DataModel to a FedItem will also speed up the data conversion and manipulation from RTI to Entity data structures.
To make (or even update) the DataModel based on the OMT definition, go to OMT panel then right click and select ...
Using this converter tool, you will be able to select all Objects and Interactions defined into the FOM and make them DataModel objects into Container named HLA (by default. This can be changed).
Press then, open the container HLA into Models
We can then see that DataModels have been generated:
Here, we have all Federation Objects and Interactions (hlaEntity, hlaDamage, hlaDeleteEntity, hlaExplosion) that have been defined as DataModel classes.
For example, if we open hlaEntity DataModel, we will see the following:
So the class hlaEntity, contains the three Attributes Identifier, Position and State, whose types has been defined in DataModel Hla_struct:
So now, it is possible to attach each DataModel object to their corresponding FedItem, allowing then vsTASKER to generate code that will simplify the data transfer.
Time to define the SOM data transfer for both Publisher and Subscriber FedItems.
The data models built by the OMT converter are just class definitions.
The user must map them with real simulation data before using them.
This is not mandatory. For example, the Federation can contain some Objects and Interactions that are specific to an environment and have no connection with vsTASKER internal data (belonging to Entity Scenario or whatever items).
But in our case, hlaEntity object contains position and state values that must be copied to/from existing runtime values, belonging to the entity.
To do that, we will create two methods set() and get().
and we will define each of them:
-
Giving DataModels to Entity
We want each Entity using the FedItem to hold one hlaEntity DataModel.
For that, we will attach the DataModel to the Entity of the scenario, but also to the default one of the Catalogs!
This is because the subscribing FedItem will create external entities based on the default Entity (in this case).
You add the DataModel to the Catalog Entity the same way as for a Scenario Entity, by selecting it and switching the Models panel.
Entity has data distributed between several internal structures, data-models and components.
This data does not necessarily match the one requested for HLA input/output of Objects/Interactions.
This is the reason why we need to attach to the Entity every Data-Model generated by the OMT converter.
According to the following picture, we can see that one FedItem is instanciated, even if used by Entity 1 and 2.
As a publisher, the FedItem will be called by the RTC at the frequency set by the user, then, will process the Object code for each entity attached to it (used_by list), then, call the code of all Attributes.
We will see later how to get a pointer to the hlaEntity data of the entity. Once obtained, using the get() function will refresh the data. Then, FedItem will publish it.
The subscribe part is the reverse process of the publish.
There is also one FedItem per HLA Object subscribed even if several entities are using it.
We the subscriber FedItem receives a data from the RTI, it will retrieve the corresponding entity automatically and then, get the pointer to the hlaPosition of the entity.
This is done because the FedItem is instructed to use hlaEntity as a DataModel, assuming that every attached entity holds the hlaEntity DataModel also.
If not (forgotten by the user) nothing will really happen.
Once all Attributes have been received from the RTI, the Object code is then called. There is when the set() function is called to refresh the entity data values.
Now, let's define the FedItems.
