Basic Scripting
Before delving into the details of the scripting language, a quick
overview of how it all works might be helpful. The first thing to
realize is that a script is just a "list of things to do" that the
CMS processes while it's in Mapped Mode. The script tells it to
move data around, process particular functions, whatever needs to
be done. Each item on the list (referred to as a "statement") defines
some action that to be performed using the functions that the CMS
provides.
Creating a script is, essentially, just laying out a set of directions
for the program to follow. That does oversimplify it a bit, creating a
list that does what you want can be tricky sometimes, but that's the
essence of it.
The Script Loop
The operation of the Control Manager is simply a repetitive "loop"
operation that goes something like this:
1. Get new axis values and button states from the real devices.
2. Process the new values as in the manner defined by the script
to produce new states for the buttons and axes on the CMS Controls.
3. Process the new CMS Control states via the GUI-created
map to produce Control Manager Device axes and buttons, key strokes,
or mouse moves.
4. Go back to Step 1 and do it all again.
This loop is executed periodically depending on several factors, whether
and real data changed, how long it's been sense the last pass through
the loop, etc. This is all pretty much transparent to the user, but it's
good to be aware of what's happening.
When Step 2 is executed, the script (if there is one) is processed
starting at the first line and proceeding through the script to the last
line. While this takes a very small amount of time, it should be noted that
things still happen in the order that they appear in the script and not
simultaneously or randomly. No script statement can effect anything that
comes ahead of it in the script on the same pass. Something that changes
at, for example, the 10th line in the script, cannot affect something
that happened at the 9th line until the next time that the script is
processed. This sequencing of operations can be very handy at times.
It should also be noted that, aside from changes in the values coming
from real devices which are picked up during Step 1, none of the variables
will change value during Step 1, 3, or 4. They only change as a
result of a the script statements during Step 2.
A Simple Script
A simple example of a complete script might help give a little better
idea of how the whole thing fits together. Suppose, for some reason
you want to create a map with one Joystick in it. In that map, you want
Button 2 on Control Manager Device 1 pressed when Button 2 on your
joystick is released and vice-versa. It's a trivial example, not something
with much practical use, but it does show how the data moves through
the system.
Such a script might look like this:
SCRIPT
CMS.B1 = NOT JS1.B2;
ENDSCRIPT
The script only consists of one actual line aside from the SCRIPT and
ENDSCRIPT statements. The line simply says "Set the state of CMS.B1
(the first button on the CMS Controls) to be the opposite of whatever
the state of JS1.B2 (Button 2 on the Joystick is). Every time the loop
is executed, the state of JS1.B2 is checked and the opposite of its
value is sent to CMS.B1.
CMS.B1 isn't a device that Windows will automatically see, however,
so you would go to the GUI and select Button 1 on the CMS Controls.
Set it in DX Mode and assign it CM Device 1, Button 2. That makes
the connection to the outside world. While you're in the GUI, you
would also clear any assignment to CM Device 1, Button 2 that may
already exist so that there won't be multiple devices trying to
to control the button.
That's about it. If you were to set up the map and download it, you'd find
that Button 2 will be on when Button 2 on the joystick is released and
then turn off when the button is pressed.
