 |
VR-Forces 5.0.3 Developer's Guide
|
All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Properties Friends Macros Groups Pages
|
VR-Forces 5.0.3 Developer's Guide
|
This chapter describes models that have been implemented as simulation components and information about how to construct new models.
An object model includes logic and data that perform a variety of functions: parameter and state data; modules that provide the infrastructure for managing resources, tasks, plans, and communications; configurable components; and task behaviors. (This architecture is explained in Simulation Object Design.) Models of specific vehicles, lifeforms, aircraft, ships, etc. are created by setting parameters for manager modules in an object and/or listing appropriate components in object configuration files. Completely new components can be created in C++ code and then added to the object to model new behaviors or subsystems.
The following sections describe several classes of components:
Sensors are components that are typically used to implement models of target acquisition. In other words, the sense objects, and they model not only physical sensor systems, but the processing of signals by machines and humans that may occur in the system. The output is generally a list of objects and Combat Identification Level associated with them.
Object Sensor Concepts provides some explanation of the sensing and target acquisition process in VR-Forces and presents the main classes that support object sensing.
Sensor components may also be used to interpret other conditions in the simulated environment, such as whether the object is receiving fire (for example, see DtUnderFireDeterminationSensor or DtNbcSensor).
Sensor components are ticked before other components in a component system, so the results of the acquisition process are available the same tick for a controller.
How to Create a New Sensor. The radarWarnRx example demonstrates how to create a new sensor component and connect it to controller components. It adds the following new capabilities and behaviors to existing simulation objects in VR-Forces:
This example extends the CIS generic attack/strike fixed-wing entity to have a radar warning receiver. It also adds a reactive behavior to the plane, such that when its radar warning receiver detects a radar, the entity moves to a designated safe location. The safe location is a control point positioned out of range of the radar threat. Once it has reached the safe location, it resumes the task it was executing (if any).
Controllers are components that perform a similar function to managers in that they typically are ticked each simulation frame an perform some computation on behalf of the object. Unlike managers though, they do not generally provide a service that other modules of the object can access. If a controller is part of a component system (see below), then the controller and the capability it provides can be configured onto the object in the Simulation Object Editor.
Some components get data from a sensor or from object state, compare it to desired data set by a command, and provide outputs to an actuator. In this way they act as feedback controllers. Other controllers just compute something and update some part of the object state.
General Classes. DtControllerComponent documents the base class for controllers and lists controllers derived from the base. See also Component Manager.
The following are examples of controller classes in VR-Forces:
How to Create a New Controller. To learn how to create a new controller and add it to a simulation object, see the radarWarnRx example. This example contains code for two separate plug-ins: one for the back-end and one for the Simulation Object Editor. The source code and project files for both of these plugins can be found in ./examples/radarWarnRx. A sample scenario demonstrating the new behavior is available in ./userData/scenarios/developer_toolkit_examples/radarWarnRx/radarWarnRx.scn. In the scenario, the aircraft tries to move toward Waypoint Alpha. Once it detects the missile launcher, it veers off towards the waypoint named Safe Haven. Upon arrival at Safe Haven, it resumes its original course (toward Waypoint Alpha).
Task controllers are a subclass of controllers. These controllers implement tasks that the object can execute. The DtTaskControllerComponent subclass has special functions for registering for tasks, processing a task, clearing a task, etc. These functions are generally called by the task manager.
General Classes. DtTaskControllerComponent, DtSingleTaskControllerComponent, DtMultiTaskControllerComponent. See also Task Manager, DtTaskMessage, Tasks and Set Data Requests.
Examples of task controllers:
How to Create a New Task Controller. To learn how to create a new task controller, see the Add Task example.
Actuator components are ticked last in a system. They typically take physical action commands from a controller and change the state of the simulated world to model the effect of a physical device. For example:
Most movement actuators take input commands such as throttle, steering, joystick, or rudder position. The actuator computes the response of the propulsion system and direction control elements based on the state of the object. The actuator then computes the interaction of the object with the environment and outputs a new position, velocity, and orientation. Examples include
Other actuators such as the fall-from-sky actuator (DtFallingFromSkyActuatorComponent) don't take input commands, but simply update the object's kinematic state over time. This actuator is used in ballistic munitions, chaff, naval mines, etc.
The update-repository actuator (DtUpdateRepositoryActuator) in a movement system takes position, velocity and orientation data from a connected component (such as a movement actuator) and updates the external state of the object.
Damage actuators are typically the only component in a damage system. These actuators register for notifications from the DtDetonationManager when detonation events are received. The damage actuators use the information in these events to determine what type of munition caused the detonation and whether it damages the object. Damage actuators include the following:
How to Create a New Actuator. If you want to create a completely new type of actuator, subclass DtActuatorComponent (actCmpnt.h). If you want to inherit functionality from one of the existing actuators, such as DtAutomotiveActuatorComponent, you can subclass that actuator.
In your actuator, you must do the following:
The Modify Sim Component (modifySimComponent) example creates an actuator that simulates a vehicle that travels due north regardless of steering inputs, but at a speed regulated by the throttle input. It replaces the DtAutomotiveActuatorComponent.
Components are often grouped into systems that represent a capability–for example, a sensor, weapon, or propulsion system. Each system may have sensors, controllers, actuators, and subsystems in it. A weapon system might have an actuator that models the physical weapon characteristics, and one or more controllers that define target selection, rules of engagement restrictions, aiming behavior, and firing mode selection. The actuator would implement the shared simulation representation of a firing event. The controllers would handle messages that request firing tasks. Systems can model any capability that requires processing, such as a capability to airdrop cargo or handle detonation events and compute damage. The .entity files include references to all of the systems that are configured onto a particular entity type.
Component systems are constructed entirely in data files. New systems can be constructed from similar existing ones using the Simulation Object Editor; this approach mostly allows for changing some system names and parameters. For example, a new weapon system could be copied from a similar weapon system and then the name and key parameters changed to model the characteristics of the new weapon. Alternatively, a whole new system could be constructed by editing a text file and writing it out as a sysdef file. This way, any components could be included in the system. A very simple example of this is a system that includes only a DtScriptEnableController, which enables certain scripts (tasks or set commands). This system could be configured onto some entity type using the Simulation Object Editor to provide a capability to a certain type of entity.
Some types of systems share a common template file that defines all of the components in the system. The system file that is referenced by the .entity file then contains little more than variable value assignments and a reference to the template. The variables are assigned to the component parameters in the template file, thus defining the character of a particular system. For example, all ballistic guns use the same "mm-gun.template_sysdef" file but change the parameters for targets, gun range, rate of fire, etc.
The following subsections describe some of the commonly used systems that have been built in VR-Forces:
Sensor systems typically contain one component, a sensor component. See Actuators. The exceptions to this are
Movement systems are responsible for executing all of the movement-related tasks that an object can perform. Typically these include moving to a location or waypoint and moving along a route object. Each different task is implemented by a different task controller. Some related tasks, such as moving to a waypoint and location, may be implemented by controllers that are derived from a common base controller. The controllers provide low level command input to actuators which perform dynamics calculations and update the object state. See Fixed Wing Fighter Jet System for a diagram of an example movement system.
Weapon systems can be relatively complicated because the weapon requires components not only to fire the weapon at the designated target, but to control the aiming functions–i.e., articulated parts for changing azimuth and elevation. There may be a component for making sure the target is visible and otherwise within the engagement envelope of the weapon as well. If weapon physical characteristics are provided by actuator parameters, but the controller needs to know the characteristics to use the weapon, then the characteristics have to be shared between the components. Weapons that are aimed may support tasks that move the aiming parts (i.e. the turret) in addition to aiming at a target. The aiming parts may affect other things on the object as well, so there has to be communication and coordination between different components, systems, and/or tasks. All of this coordination takes place through either port data or shared data in the process state repository.
Gun System Template shows a diagram of the components in a template for a gun system.
Most of the damage systems in entities in VR-Forces contain only an actuator, the DtDamageAdjudicationActuator, which takes detonation events/interactions and computes the effects on objects in terms of Catastrophic Kill, Mobility Kill, or Firepower Kill. For lifeforms, Slight and Moderate damage are used instead of Mobility and Firepower kill. There are also damage actuators, and systems that use them, for other models such as non-lethal damage, suppression, and multiple hit vulnerability. See Damage.
See the User's Guide for information about how munition damage power and object vulnerability data work together to produce damage probabilities. Note that the AggregateLevel Simulation Model Set assesses attrition with a model implemented as a Lua Background Task (see the User's Guide for documentation on background tasks and the Aggregate Level models.)
This section provides some examples of how components, component systems, and managers work together to model a capablity in VR-Forces.