The network piece is responsible for taking protocol specific information and using classes wrapped around that information to present a general interface such that the creation of the visuals and data does not need to know which protocol is providing the information. Two that, the network is broken up into two pieces: The protocol specific piece and the protocol independent piece. The protocol independent piece is built on top of the protocol specific piece. The gui has plugins that are loaded depending on the protocol the user has selected in order to determine which kind of exercise connection to make to get the data from the protocol specific to protocol independent part.

The Protocol Specific Component

Each protocol has a plugin that can be loaded to implement the interface between that protocol and the protocol independent portion of the code. The protocol interface subclasses from a class called makVrf::VRF_PROTOCOL_NAMESPACE::DtVrfDriver. The driver class is installed as part of the plugin initialization and is tied to the driver that is being created as part of the command line argument (for example, –dis will create a driver of type DtDisDriver)

makVrv::DtDriverFactory::instance(de).addDriverCreator("DtDisDriver",new DtVrfDisDriverCreator());

It should not be necessary for you to ever override the main driver. All additional functionality can be added on accesory plugins. See Adding Protocol Functionality

The makVrf::VRF_PROTOCOL_NAMESPACE::DtVrfDriver class is responsible for creating:

The DtExerciseConnection that is protocol specific and used to listen to network traffic
The makVrf::DtVrlinkVrfRemoteController which will be responsible for communicating with any VR-Forces Back End that is part of the simulation
The various reflected lists that are used to listen to specific classes of simulation objects on the network (Entity, Unit, Environmental, IFF, Emitter, etc.). This is explained more in the Network Interface section
The makVrf::DtVrfConnectionHelper class that is used to communicate with the front end visualization thread. See How the Visuals and The Network Work Together
The makVrf::DtSimDataProcessorManager class that is used for taking the data from the network and putting it into protocol independent data structures for use in the visualization thread. See The Protocol Independent Component

The classes that are typically subclassed and replaced are the DtVrlinkVrfRemoteController class to implement (or change) a particular piece of code that will communicate with the back end, the maka reflected list to read additional information from the network that is not part of the standard protocol, or a sim data processor that will take that information read from the network and put it into structures to allow the visualization piece to have access to this data.

VR-Link Network Interface

The VR-Link Netwok Iterface library contains network interfaces to read from the netwwork (Remote Interface) or write to the network (Local Interface) using the makVrf::DtStateData and makVrf::DtStateDataComponent in order to transfer the data from/to the network. This library is shared by the front-end and the back-end. The makVrf::DtSimObjectNetInterfaceFactory contains entries for creating interfaces based on keys in the .ope file:

(local-objects 
   (net-interface "individual-local-entity-net-interface-with-properties")
)
(remote-objects 
   (net-interface "vrf-individual-remote-entity-net-interface-with-properties")
)

The DtSimObjectNetInterfaceFactory class has a method addCreatorFcn that allows you to add network interfaces by their keyword. The vrfNetInterfaceTypes.h contains a list of all the current keywords.

      addCreatorFcn(
         DtSimIndividualLocalEntityWithPropertiesNetInterfaceType,
         DtSimIndividualLocalEntityWithPropertiesNetInterface::creator);
      addCreatorFcn(
         DtVrfIndividualRemoteEntityWithPropertiesNetInterfaceType,
         DtVrfIndividualRemoteEntityWithPropertiesNetInterface::creator);

See Subclassing Network Interfaces for how to install your own version of a network interface

How to Subclass and Replace Components

DtVrfGuiNetworkFactory

This class will hold creators for the main global instances of functionality contains in the DtVrfDriver:

      static DtVrfRemoteController* createRemoteController(int receivePort = 9000);
      static void setRemoteControllerCreatorFcn(VrfRemoteControllerCreatorFcn);
      static VrfRemoteControllerCreatorFcn remoteControllerCreatorFcn();
      static DtVrfRemoteController* defaultRemoteControllerCreatorFcn(int receivePort = 9000);
      static DtVrfMessageInterface* createMessageInterface(DtCommunicationManager*, bool useDefaultFactory = true);
      static void setMessageInterfaceCreatorFcn(DtVrfMessageInterfaceCreatorFcn);
      static DtVrfMessageInterfaceCreatorFcn messageInterfaceCreatorFcn();
      static DtVrfTDLMessageInterface* createVrfTDLMessageInterface(DtCommunicationManager*, bool useDefaultFactory = true);
      static void setVrfTDLMessageInterfaceCreatorFcn(DtVrfTDLMessageInterfaceCreatorFcn);
      static DtVrfTDLMessageInterfaceCreatorFcn vrfTDLessageInterfaceCreatorFcn();
      static DtVrfCommunicationManager* createCommunicationManager(const DtSimulationAddress&, DtStateDataManager* em = 0);
      static void setCommunicationManagerCreatorFcn(DtVrfCommunicationManagerCreatorFcn);
      static DtSimDataProcessorManager* createSimDataProcessorManager(DtStateDataManager*, makVrv::DtBaseConnection& c);
      static void setSimDataProcessorManagerCreatorFcn(DtSimDataProcessorManagerCreatorFcn);
      static DtVrfConnectionHelper* createVrfConnectionHelper(makVrv::DtDe&, bool inThread);
      static void setVrfConnectionHelperCreatorFcn(DtVrfConnectionHelperCreatorFcn);
      static DtVantageToLegionIdMapper* createVantageToLegionIdMapper(DtStateDataManager*, makVrv::DtBaseConnection& c);
      static void setVantageToLegionIdMapperCreatorFcn(DtVantageToLegionIdMapperCreatorFcn);
      static DtTDLMessageProcessor* createTDLMessageProcessor(makVrv::DtBaseConnection& c, DtVrfRemoteController*);
      static void setTDLMessageProcessorCreatorFcn(DtTDLMessageProcessorCreatorFcn);
      static DtExtendedStateDataProcessor* createExtendedStateDataProcessor(DtStateDataManager*, makVrv::DtBaseConnection& c);
      static void setExtendedStateDataProcessorCreatorFcn(DtExtendedStateDataProcessorCreatorFcn);

To replace any of the classes contained in the factory, you would need to create a static creator method that would create a subclass of the intended class, and the subclass of that class. The Network Callback Manager example shows how this can be done

makVrf::DtVrfGuiNetworkFactory::setRemoteControllerCreatorFcn(boost::bind(&DtExampleRemoteController::Creator, _1));

DtVrfRemoteController* DtExampleRemoteController::Creator(int receivePort)
{
   return new DtExampleRemoteController(receivePort);
}

When this example is run you will see that anytime a user loads a scenario, a message will be printed to the console with the scenario they are loading.

Subclassing Network Interfaces

Generally, when thinking about sending extended data over the network, using VR-Forces State Properties is the best and easiest way to do this. State Properties are sent in a VR-Forces PDU that knowns how to serialize/desieralize DtReaderWriter content. The Add State Property GUI example shows how to reference newly addded state property data from the back-end (Add State Property Sim) and reference in the front-end via the makVrf::DtVrfObjectDataState state view data (stateviews).

For those times, however, where you need to publish to or read data from an external simulation, then, overriding the network interface and supplying encoders/decoders and FOM files is the appropriate way to do this. The Add State Component GUI example shows how to add a state component and receive published information over the network. This information is currently published by the back-end in the Add State Component Sim example. See stateComponentAddition for how to add your own state components

The example adds a new remote entity net interface to read the new reflected state repository that contains the temperature:

void DtAddStateComponentGuiAccessory::slot_onConnectionSetUp()
{
   makVrv::DT_PROTOCOL_NAMESPACE::DtVrlinkConnection* connection =
      dynamic_cast<makVrv::DT_PROTOCOL_NAMESPACE::DtVrlinkConnection*>(myDriver->connection());
   DtSimObjectNetInterface::factory()->addCreatorFcn(
         DtVrfIndividualRemoteEntityWithPropertiesNetInterfaceType,
         DtIndividualRemoteEntityNetInterfaceWithTemperature::creator);
   DtReflectedEntity::setStateRepCreator((DtReflectedEntity::DtStateRepCreator)
      DtEntityStateRepWithTemperature::create);
   // Add the new sim data processor into the system such that when components of type temperature are created, the state view and
   // data for that will be created
   DtTemperatureSimDataProcessor* iffdp = DtTemperatureSimDataProcessorCreator::instance(*connection).create(myDriver->stateDataManager(), *connection);
   DtSimDataProcessorManager::instance(*connection).addDataProcessor(iffdp);
}

Make sure to create a new DtEntityStateInterceptor that is derived from the new reflected class:

DtEntityStateRepository* DtAddStateComponentEntityStateInterceptorCreator::create(makVrv::DT_PROTOCOL_NAMESPACE::DtVrlinkEntityStateListener* listener)
{
   return new makVrv::DT_PROTOCOL_NAMESPACE::DtEntityStateInterceptor<DtEntityStateRepWithTemperature>(listener);
}

And, when the network interface needs to update itself from the network, it places the internal temperature into the state component:

   DtEntityStateRepWithTemperature * netState = dynamic_cast<DtEntityStateRepWithTemperature*>(individualNetworkState());
   if (netState)
   {
      try
      {
         // Find the state component, and, if it exists, set the temperature.  Next frame state is used in order to write in the new information
         makVrf::DtInternalTemperatureStateComponent* stateComp = mySimObject->
            nextFrameState()->getStateComponent<makVrf::DtInternalTemperatureStateComponent>();
         if (stateComp)
         {
            stateComp->setInternalCoreTemperature(netState->temperature());
         }
      }
      catch(...)
      {
         // State component does not exist, so, that is ok
      }
   }

In order to send data from the network side to visualization side of the front-end you must use agents (see Agent Connectivity). The first agent created will be the DtTemperatureStateObject agent. This agent will be used to serialize DtTemperatureStateData from the network thread to be processed in the visualization thread:

void DtTemperatureStateObject::setState( DtTemperatureStateData& state )
{
   *myTemperatureState = state;
   if(mySimEntry)
   {
      // This call will emit the signal that this state view has been updated
      mySimEntry->stateUpdated();
   }
}

Once the state data and agent are created, the state data processor can be created and added to the network. The state data processor uses the agent to send through a state data that is set from the network side with network data and received on the gui side.

   // Add the new sim data processor into the system such that when components of type temperature are created, the state view and
   // data for that will be created
   DtTemperatureSimDataProcessor* iffdp = DtTemperatureSimDataProcessorCreator::instance(*connection).create(myDriver->stateDataManager(), *connection);
   DtSimDataProcessorManager::instance(*connection).addDataProcessor(iffdp);

Once the state processor is set up, the setState method will be called when the state has changed or wants to be updated into the visualization thread.

bool DtTemperatureSimDataProcessor::setState(const std::set<const makVrf::DtFrameStateInterface*>& interfaces, DtTemperatureStateData& state) const
{
   DtTemperatureStateData curState(state);
   // There is only ever one interface supplied
   const DtInternalTemperatureStateComponent* tsc = dynamic_cast<const DtInternalTemperatureStateComponent*>(*interfaces.begin());
   state.myTemperature = tsc->internalCoreTemperature();
   return (state != curState);
}

The state is then set into the agent for processing in the visualization thread.

   if (setState(interfaces, iter->second) || force)
   {
      if (entObjAgent)
      {
         signal_stateUpdated(id, iter->second);
         // This will use the agent to archive the state into a buffer, put it into the agent interface queue, and, when the queue
         // processes in the main visualization thread, dearchive the state and set it into the gui representation of the data
         entObjAgent->setState(iter->second);
      }
   }

Visualizers and State Listeners

5.2 - Simulation Drivers

Adding Protocol Functionality

5.3 - Adding Functionality to a Driver (Accessories) There are a few important methods to call out, as, implementing these methods and connecting to signals sent by the driver will allow for the proper use of the accessory in a VR-Forces front-end. The first method to overrride is the install method. This will allow the connection to three important signals sent from the driver:

signal_connectionCreated - This signal is sent when the exercise connection has been created and initialized but before the reflected lists and remote controller are created
signal_connectionSetUp - This signal is sent after all objects that need an exercise connection (remote controller, logger control) but before reflected lists are set up
signal_driverStarted - This signal is sent after the signal_connectionSetUp and after VR-Forces overrides to the reflected lists and interceptors. Connect to this signal to install your own subclasses of these items

void DtAddStateComponentGuiAccessory::install(makVrv::DtDriver* driver)
{         
   makVrf::VRF_PROTOCOL_NAMESPACE::DtVrfDriver* vld = dynamic_cast<makVrf::VRF_PROTOCOL_NAMESPACE::DtVrfDriver*>(driver);
   if(vld)
   {
      //connect accessory to connection signals.
      vld->signal_connectionCreated.connect(
         boost::bind(&DtAddStateComponentGuiAccessory::slot_onSimCreated, this, _1));
      vld->signal_connectionSetUp.connect(
         boost::bind(&DtAddStateComponentGuiAccessory::slot_onConnectionSetUp, this));
      // Since the driver overrides the entity state interceptor to create an entity state that has the right reflected object, this
      // example must install a new version when the driver is set up to allow for the new subclass that knows about temperature to be installed
      vld->signal_driverStarted.connect(
         boost::bind(&DtAddStateComponentGuiAccessory::slot_driverStarted, this));
      myDriver = vld;
   }
}

void DtAddStateComponentGuiAccessory::slot_onSimCreated(makVrv::DtConnection* connection)
{
   connection->signal_connected.connect(
      boost::bind(&DtAddStateComponentGuiAccessory::slot_onSimConnected, this, connection));
   connection->signal_toBeDisconnected.connect(
      boost::bind(&DtAddStateComponentGuiAccessory::slot_onSimAboutToBeDisconnected, this, connection));
}

void DtAddStateComponentGuiAccessory::slot_onSimConnected(makVrv::DtConnection* connection)
{
   makVrv::DT_PROTOCOL_NAMESPACE::DtVrlinkConnection* vrlCon = dynamic_cast<makVrv::DT_PROTOCOL_NAMESPACE::DtVrlinkConnection*>
      (connection);
   if(vrlCon)
   {
      configFomMapper(vrlCon->exerciseConn()->fomMapper());
   }
}

void DtAddStateComponentGuiAccessory::slot_onConnectionSetUp()
{
   makVrv::DT_PROTOCOL_NAMESPACE::DtVrlinkConnection* connection =
      dynamic_cast<makVrv::DT_PROTOCOL_NAMESPACE::DtVrlinkConnection*>(myDriver->connection());
   DtSimObjectNetInterface::factory()->addCreatorFcn(
         DtVrfIndividualRemoteEntityWithPropertiesNetInterfaceType,
         DtIndividualRemoteEntityNetInterfaceWithTemperature::creator);
   DtReflectedEntity::setStateRepCreator((DtReflectedEntity::DtStateRepCreator)
      DtEntityStateRepWithTemperature::create);
   // Add the new sim data processor into the system such that when components of type temperature are created, the state view and
   // data for that will be created
   DtTemperatureSimDataProcessor* iffdp = DtTemperatureSimDataProcessorCreator::instance(*connection).create(myDriver->stateDataManager(), *connection);
   DtSimDataProcessorManager::instance(*connection).addDataProcessor(iffdp);
}

void DtAddStateComponentGuiAccessory::slot_driverStarted()
{
   makVrv::DT_PROTOCOL_NAMESPACE::DtVrlinkConnection* connection =
      dynamic_cast<makVrv::DT_PROTOCOL_NAMESPACE::DtVrlinkConnection*>(myDriver->connection());
   DtAddStateComponentEntityStateInterceptorCreator::instance(*connection);
}

Visual Object Filtering

There are times when a user wants to filter visuals and items from the object list that meet certain criteria. This is called Fog Of War filtering. The selection filters are described in Selection Filters Selection Filters, and, the visuals are filtered out using the makVrf::VRF_PROTOCOL_NAMESPACE::DtVrfFogOfWarHandler. This handler will determine whether or not the filters set into the makVrf::DtVrfSpotReportManager via the addFogOfWarFilter pass the filter test for each object in the system and then hide the visuals if it does pass the test. The fog of war filters are also execture in the makVrf::DtVrfFilteredListView and makVrf::DtVrfHierarchyPageLogic classes. The Object Filtering example shows an example of how to add a new filter to the makVrf::DtVrfSpotReportManager to hide visuals based on certain criteria.

Table of Contents