Mapping – Must read before you begin

coreDS™ defines a concept of “internal object representation”. In order to be able to create different configurations (mapping) compatible with a wide variety of simulator, without having to change the underlying implementation, the concept of “internal object representation” was created.

An internal object representation is simply a name (string) by which your object, interaction, message, properties are locally named. They have no direct relation to, let says, a DIS Entity State PDU location or HLA RPR FOM Spatial attribute.

For example, if you have an object in Unreal that represents a “minitaur” monster with a single property which represents its ugliness. Then, your local object representation will be “minotaur” and a local property “ugliness”.

Using coreDS UI’s, you will then link “minotaur” to DIS Entity State or HLA RPRFOM BaseEntity and “ugliness” to a corresponding HLA attribute or DIS property.

Let’s say your local representation needs some conversion before sending to the distributed simulation framework, you can use the build in LUA interpreter to take care of the conversion are runtime.

How To

The following section represents the most common uses.

How to send a message (Interaction) to the simulation

How to create and object and object

 

When using the “Update Object” blueprint node, the object will be created at the first update.

How to discover and receive object updates

In order to receive new information about an object, you must register a custom event for a given ObjectRepresentation (“MyObjectRepresentation” shown below).

Decoded values will be received in a TArray of pairs: Parameters Name, Value. “Object Name” is the local object name (in the HLA world, this will be the Object Instance Name).

How to receive message

In order to receive new information about a message, you must register a custom event for a given MessageName (“MessageName” shown below).

Decoded values will be received in a TArray of pairs: Parameters Name, Value.