In VR-Forces 4.7 and earlier, you would send messages to the network through the exercise connection.

The Event Manager (see the makVrfEvents::DtEventManager class) is an improved method of sending these messages and direct reference to the exercise connection in code is discouraged.

The DtEventManager class was introduced as an interface to sending “events” in the system. There are a number of predefined events that are used (see events.h), and, in issuing an event to the system you would create an event and then use the event manager to added the event to the system. For example, if you used to send a DtDetonationInteraction on the network:

DtDetonationInteraction detonation;

mySimManager.exerciseConn()->sendStamped(detonation);

you would could now send it as:

DtDetonationInteraction detonation;

simulationServices()->eventManager()->addEvent(DtDetonationEvent(detonation));

The same for receiving a callback for a detonation interaction. If you used to do:

DtDetonationInteraction::addCallback(mySimManager.exerciseConn(), detonationCallback, this);
void DtDetonationManager::detonationCallback(DtDetonationInteraction* detInter, void* usr)
{
   DtDetonationManager* act = static_cast<DtDetonationManager*>(usr);
   act->processDetonation(*detInter);
}

you could now do:

simulationServices()->eventManager()->signalForDetonationEvent().connect(boost::bind(&DtDetonationManager::detonationEvent, this, _1));
void DtDetonationManager::detonationEvent(const DtEvent& e)
{
   processDetonation(*static_cast<DtDetonationInteraction*>(e.contents()));
}

Note: If you previously used the DtDetonationManager or DtFireManager to register for detonation and fire events, a similar API is still available. See\ vrfFireAndDetonationServices.

Each event signal (see DtEventManager) will be passed a DtEvent. This DtEvent will have an event type and a contents. The contents is the memory representation of that event.

A specialized DtNetworkEventManager will be created to send the event contents onto the network (i.e. the VR-Link exercise connection), and, if the connection is not self-reflecting, post that as an event in the event manager to be processed in the next back-end tick (or in the case of the front-end, since the front-end will not tick the event manager, the event will be processed immediately).

This system is put into place to make the sending and receiving of events more flexible. This allows a central point at which events can be intercepted and sent over other transport mechanisms than HLA/DIS.

See the eventManagerTCP example for an example of how to replace and use the event manager.

To this the DtVrfMessageInterface and DtVrfTDLMessageInterface no longer take an exercise connection in their constructor. Also, in the VR-Forces GUI, the creators now take the DtVrfDriver in the factory (to reference the driver’s event manager) not the DtVrlinkConnection

While it is possible to send and receive fire and detonation events through the DtEventManager directly, there are also services that make this easier. The DtFireManager and DtDetonationServiceInterface are built on top of the DtEventManager. They provide a simpler API for fire and detonate events, including filtering by location and in some cases greater context about the event.