Understanding the logic behind Mover is an essential knowledge to use it.

There's more to it than the logic, but this is the base of everything.

Mover is composed by modules that communicate between them.

We have many modules, but all of them can be grouped in 7 basic types. They are:

The modules that receive or generate values.

We can receive values from other applications like games, or generate values with specific modules.

The modules that receive values from the sources and generate a pose.

A pose is a orientation and position defined by 6 values: Sway, surge, heave, yaw, pitch and roll.

The objective of the pose module is to filter the received data and generate a pose that fits the hardware ranges.

The modules where we define the rig with it's dimensions and limits.

Having the actuators joints positions, we can calculate the required actuator position, to achieve the desired pose on the rig.

The desired pose comes from one or more pose modules.

A module that receives values from the sources, and calculates an actuator position. There's no pose here. It's a direct calculation.

For example, calculate the position of the actuator in a seat belt tension system, through the longitudinal acceleration received from a source.

Or calculate the speed of a fan (just like an actuator) from the speed received from the game.

Similar to directs, but specific to calculate waves that we can use in the outputs or in audio devices.

They receive values from the other modules and allow the user to define a sequence to send data to the hardware.

They allow us to visualize the motion of the rig in the 3D viewer or the evolution of any value in the graphics viewer.

So now that we have the basic modules, we can connect them and pass information from one to the other.

We can have more than one module of the same type (not always in the sources).

Best way to show it is with an example.

Bellow you can see an hypothetical module diagram to use with RFactor2 (a race car simulator):