Component Overview

Components are the modules of code that implement physical and behavioral models for an object.

Unlike object state and object managers, components can be configured onto an object to change how the objects works. The diagram below is a typical use of components in an object.

Simulation Object Component Architecture

VR-Forces supports three basic types of components - sensors, controllers, and actuators. The component architecture supports any number of sensors, controllers, and actuators in a simulation object. These three types of component are very similar, but a key difference is that in any system, the sensors are all executed (ticked) first, then all controllers are executed, and finally all actuators are executed. This ordering supports a natural flow of information through the component system in a given tick.

• Ports. Components communicate with each other through ports. Ports are anonymous connections that allow components to produce and consume data without needing to know what is consuming or producing the data. This anonymity allows component connections to be specified in configuration (data) files without any changes to code. The port communications are shown in red in the above diagram.
• Descriptors. Components are specified in the object parameter database file by using descriptors. Descriptors specify the type of component to be created and parameter values for the component to use. Different parameter values allow components to act differently for different systems (for example, the cyclic firing rate of a gun).
• Component Systems. Groups of related sensors, controllers, and actuators can be assembled into component systems. A component system is a set of components that are managed as a group. They typically represent some logical subsystem of a simulation object, such as a weapon or movement system.
• Process State Repositories. Components may use local state objects called process state repositories (PSR). Each component may have one if needed, or components may share one–for example, components in a system may share one. A shared PSR provides another means for components to share data. Only components contained in the same system can share process state repositories.
• Resource Manager. Component systems can also have a resource manager for that system. Resource managers can track the use and replenishment of quantities of material such as ammunition or fuel.
• Component Manager. Each local simulation object has a Component Manager. The Component Manager creates, connects, and maintains the lists of components to execute. Remote objects are not simulated, so they generally do not have components or a component manager. (The exception is components attached to remote objects– see vrfRemoteAttachment).