Contents

Previous

Next

Last
Programming Tips
This section offers some tips on working with your own scripts. Not so much on how to program, but some things that can make creating and testing your scripts easier and help you deal with the problems that can turn up.

Tip #1 - Try to Work on One Function at a Time

Try to create the script one function at a time and work with the minimal map that you need to see your function work. You might even want to set up a temporary "working map" that does nothing but handle whatever the particular function is you're working on at the moment and only has the GUI assignments that you need for that function. It saves a lot of time in the download if the Map doesn't have all the strings and control assignments that it will use in the final version, and a smaller script is more easily debugged. Once the function is working to your satisfaction, you can cut and paste it into your real map for final testing.

Tip #2 - Remember to Use the Script Check Button

Try to make it a habit to use the Script Check button in the CMS editor before trying to do the download. It will find typos and missing operators for you very quickly, and can save a lot of time and trouble in going back and forth between editing and trying to download.

Tip #3 - Save Your Map Before You Run It

This is very important during debugging. If you start the map and it starts generating characters or otherwise misbehaving, it can end up changing the map. Save it to disk first. Then if anything goes wrong, you won't lose your work.

Tip #4 - Try to Keep Things "Visible" at First

When you're initially creating a function, try to stay away from using "invisible" characters, such as the Function keys (F1, F2, etc.), and substitute something visible like "a" or "b" instead. If the script doesn't do what you expect, the standard keys are less likely to activate some Windows menu or function. It's also quite handy to be able to view the characters in NotePad or some other text editor. While the Keytest utility will show you the press and release of any key, it may or may not be what a Windows program actually sees. Looking at the output in NotePad will show you things like the system autorepeat and give you a better idea of how the output might affect the game. Once it all seems to be running correctly, you can go back and change the characters to whatever they really need to be.

Tip #5 - Use Keytest and Test/Calibrate for Initial Testing

Do the initial testing using the Test/Calibrate screen and the Keytest utility. You can usually spot anything that's gone completely wrong by just watching the axes, buttons, and characters that the script causes to be generated. It's also much faster than exiting the Control Manager and starting the game to try the script. Eventually of course it will have to be tested in-game, but you can minimize that "back and forth" between the Control Manager and the game by observing things in the GUI and seeing that it looks like it's doing what you want before you actually try it. With any luck, you'll only need to tweak things a little when you actually get into the game.

Tip #6 - Debugging the Script

When you run your script and it's not doing what you planned, keep in mind the first rule of debugging - "It's only doing what you told it to do.". The CMS doesn't really "think", it just follows the instructions you gave it in the script. Look at what it's doing, then look at the script and try to see what's there that might be causing the observed behavior. Usually it's not too hard to find the piece of the script that's telling it to do whatever it is that you're seeing, and that will give you a place to start looking.

Tip #7 - Dealing with a Buggy Script that's Running

With the CMS, it is possible to create scripts that can cause problems when the map is activated. Normally it's nothing more serious than just a key that's getting held down because no logic came along to turn it off, but it can still be a little troublesome. Here's a few tips that can come in handy if that happens:

1. If you're debugging in the GUI, you can usually just click the Direct Mode button and shut off the map.

2. If you know which key it is, you can usually stop it by typing that same key on the keyboard. That will generate a key "break" and will break the stuck key coming from the script, too.

3. If the key is something that gets intercepted and processed by Windows, it can be a bit more difficult. If the mouse can be used, then shutting down the map by going to Direct Mode will still work. If the key happens to be something that the system uses for a specific function, it can be a problem. A stuck TAB key, for instance, may cause the cursor to run around the desktop continuously, making the mouse pretty much unusable. In those cases, a good thing to remember is that unplugging any of the CH USB devices will put the Control Manager back into Direct Mode. Just unplug something, things should settle right down. You can plug it right back in once the Mode Change has been completed.

Such occurrences aren't really hard to deal with. The main idea is to just try get the Control Manager back to Direct Mode, one way or the other.

Tip #8 - Avoiding Startup Problems

If you're running the CMStart utility at Windows startup, be careful not to leave a buggy map downloaded at the end of your debugging session. When Windows restarts, the map will be enabled and start to run. Whatever problems it might have been causing will start right up with it. You can disable CMStart, of course, or just download a known good map before you quit working.