Predefined Variables and Constants
There are several predefined variables and constants available for use
in writing scripts. This section lists them all.
Analog Variables
CURRENTMODE
This variable can be used to get or set the
current mode of the Control Manager. It is normally set via
the switch on the FighterStick or ProThrottle that controls the mode.
On the FighterStick, it's controlled by Button 3 on the upper right side
of the stick handle. On the ProThrottle, it's Button 1 which is activated
by pressing straight down on the ministick handle. When you switch modes
using this method, the three LEDs on the base of the unit will cycle as
the button is pushed, indicating which Mode the system is currently in.
Note that you will probably have to switch modes at least once when you
start the game to get the LEDs in sync with the actual Mode.
The Mod can also be set by the script itself. The CURRENTMODE variable can
be assigned a value and the rest of the map will change modes just as
if it were switched using one of the above devices. The script cannot
affect the LED indicators on the devices, though, so if you set CURRENTMODE
via the script there will be no particular correlation between the Control
Manager mode and the device LEDs.
There are also a three predefined constants which can be used to set or
check the CURRENTMODE variable. These values are MODE1, MODE2, MODE3
and MODE4 and have values of 0, 1, 2, and 3 respectively. Thus, to force
a particular mode, you might write:
CURRENTMODE = MODE3;
to cause the map to switch to Mode 3
PROTHRMODE and FTRSTKMODE
While the Control Manager cannot control which of the LEDs on the FighterStick
or ProThrottle, it does know which one is currently on. You can use the
information to set up "submodes" that respond to the Mode switches on
the FighterStick and ProThrottle without using them to set the primary
Map Mode at all. The two variables that contain this information are
called FTRSTKMODE and PROTHRMODE. Note that these values are "Read Only",
you cannot set them as that would imply that you could set the LED state.
These values will be 0, 1, or 2 depending on which LED is last on. Note
that the values may need an initial synchronization when the script
initially starts since it is the change in controller mode that causes
the Control Manager to get notified. The map will initially see the
controllers in Mode 0 regardless of the actual LED position. If the
first LED is on at that point, all is well. If not, it won't actually
line up until you click the button to change the LED and it reports that
to the Control Manager.
Bit Variables
Several bit variables are also predefined. These can be used
in the scripting to sense and control some functions which would otherwise
be unavailable.
FIRSTSCAN
The FIRSTSCAN flag is TRUE for the first loop through the CMS script. It
is primarily used to reset variables when the Control Manager is switched
from Direct Mode to Mapped Mode and the script starts executing. This
avoids the necessity of constructing such a flag to achieve initial
synchronization.
CLOCKTICK
The CLOCKTICK flag is TRUE when script executes and the clock has
ticked. This probably bears a little explanation. The script can execute
for a variety of reasons. To keep track of any timers that the script
might contain, there is an internal clock that is checked when the script
is executed. If the clock has "ticked" on that scan, then the timers are
decremented. The CLOCKTICK flag indicates whether the scan is one during
which the clock will be applied to the timer or not.
XRELATIVE, YRELATIVE, and ZRELATIVE
These flags are used to indicate to the script whether or not the data
passed from CMS values to the Mouse X, Y, and Z values are relative or
absolute. These are necessary for the use of the Trackball. If the map
does not include a Trackball, then these flags can be ignored.
Trackball
data and Joystick data are fundamentally different. Trackball data shows
how far the ball has moved since the last check, whereas Joystick data
really shows how far off-center the stick handle is. When the data is
destined for the mouse, it becomes necessary for the system to know which
type of data it's handling. When you assign a device axis directly to
the mouse values in the GUI, the CM can tell based on the source of the
data whether it should be treated as relative or absolute. When the data
is moved through the script though, it loses its source identity and so
the script has to be told which type of data is being used.
To use the flags, simply set them TRUE for any of the mouse axes that's
getting data which originated with the Trackball. If the mouse is getting
data that originated as a joystick axis, then these flags can simply be
ignored as they default to FALSE. Again, if you don't have a Trackball,
you needn't bother with these at all.
Note that these flags may need to be changed dynamically during the
script execution if the source for the mouse is changed. In some cases,
it may prove desirable to use the Trackball as the mouse at some times, at
others you may want to use a Joystick. You can't assign more than a single
device to the mouse, but you can select the device using the script, move
the appropriate data into CMS variables, then assign the CMS variables to
the mouse itself. If the source changes for an axis, then the flag for
that axis must also change. See the section on Sample Scripts
for an example of implementing this sort of logic.
TIMESTAMP
While the timing functions built in to the Control Manager are generally
adequate for most programming needs, they are subject to some variations
due to Windows own timing, thread switching and pre-emptions, etc. In these
cases, it can be useful to have a more "absolute" timing reference. The
TIMESTAMP variable serves this function. It is treated like any other
analog variable, but it is read-only and returns a value approximately
equal to the number of milliseconds that have elapsed since Windows as
started. This time is derived from the system clock and so is not subject
to the variations inherent in the normal timing functions.
Note that while the timer itself reads in milliseconds, that does not mean
you can control timing to within 1 millisecond. You can tell if some operation
has taken longer than some predetermined time by recording TIMESTAMP at the
beginning and then checking TIMESTAMP periodically to see how much time has
elapsed, but you only get a look at TIMESTAMP periodically so the time can
vary simply because you can't respond to the timer immediately.
Hat Middle Buttons
Four additional buttons have been created that indicate when a
POV or hat switch is in its center position. All of the
joysticks and yokes have a POV. Additionally, some yokes and
joysticks have one or three 4-way hats.
The four button are referenced as JSx.B21 through JSx.B24 and are
assigned thus:
B21 - Hat 1 Center
B22 - Hat 2 Center
B23 - Hat 3 Center
B24 - Hat 4 Center
All of the controllers except the ProPedals have B24 since they
all have POV hats. The FighterStick and the ProThrottle have 3
additional hats and so support all 4 buttons. The CombatStick and
the VPPro have 1 additional hat and so support Buttons B21 and
B24 only.
These are useful, for example, if you were programming a
snap view system. The hat center position can be used to send the
"Look Forward" command so that the view will return to normal
when you release the POV.
A word of warning on this one, it stays
On whenever the hat is centered. If you simply assign a character
to it, the character will repeat continuously whenever the hat is
centered. Be sure to use a NULL character to suppress this
activity, e.g. program "NULL a" rather than "a".
