Enemy Territory scripting for newbies - crouch, weapons, etc

I see script-related questions all the time. "Where do I find a dual weapon bind?" Where can I find a crouch script?" There are plenty of sites that offer ready-made Quake 3: Arena (Q3:A) scripts just waiting for you to copy and paste into your autoexec. For many of them, using them in ET is just a matter of modifying the script a little. What I'll try to do here is a little different. I want to help you understand how to write scripts so that you can make your own. Once you learn the basics, it's easy.

I see script-related questions all the time. "Where do I find a dual weapon bind?" Where can I find a crouch script?" There are plenty of sites that offer ready-made Quake 3: Arena (Q3:A) scripts just waiting for you to copy and paste into your autoexec. For many of them, using them in ET is just a matter of modifying the script a little. What I'll try to do here is a little different. I want to help you understand how to write scripts so that you can make your own. Once you learn the basics, it's easy.

After reading through this basic explanation of script writing you should be comfortable with writing your own basic scripts. Visit The Bind:Arena to see some examples of some really cool ET Console commands page for all of the different console commands and variables you might need while writing your scripts.

Script Organization

Basic Binds

Multiple Binds

Recursive Scripts

Toggles

Executables

Examples

Resources and Intellectual Property

Script Organization

Scripts have to be saved in a separate .cfg file from your etconfig.cfg. The reason is that ET overwrites the etconfig.cfg file every time you start a game or change settings and therefore will delete any scripts and comments you add. I put all of my scripts into an autoexec.cfg. If you don't know how to put one together, visit the Tweaking Your Controls:Making an Autoexec article I wrote for a quick lesson.

As you write scripts, use //comments to help annotate what your script does. It will help better organize scripts in your configuration and if you want to give your scripts to other people, it makes it pretty clear what it does. ET will not execute anything that follows a pair of double-backslashes (//).

Example of //(Example,just random keys I choiced)

Basic BindsBinding a key to perform a single action is the easiest place to start. We'll start by binding the x-key to select the primary weapon (typically the SMG) (weaponbank 3).

The syntax is:

bind [key] "[command]"

Since we want to bind x to the SMG, we will substitute x for [key] and weaponbank 3 for [command]. This should give us:

bind x "weaponbank 3"

That was simple enough, let's move on.

Multiple BindsWe can also bind a key to execute multiple commands. Remember that ET executes commands in the order you've specified so we have to be a little careful. Now, we are going to bind a key to switch to the SMG and yell "Fire in the hole!" for our friendly engineer.

The syntax is:

bind [key] "[command 1]; [command 2]"

You have to separate the commands with a semicolon ( ; ) so that ET recognizes where each command starts and stops. We're going to use the x-key again for [key], weaponbank 3 for [command 1], and vsay fireinthehole for [command 2]. This should give us:

bind x "weaponbank 3; vsay fireinthehole"

When you hit x, the bind selects the weaponbank 3 (the SMG) and then executes the vsay command. That way, our engineer can get away, switch to the SMG, and warn everyone else all with one push of a button.

You can string a whole bunch of commands together to be executed all at once. This bind for example, will take a remove all the clutter from your screen (e.g., icons, guns, etc) , take a screenshot, and then return your HUD to the way it was.

Recursive ScriptsEverything is clear so far, right? Now, instead of only selecting one weapon, what if we want to toggle back and forth between two weapons, like the SMG and the pistol or make it possible to toggle between always crouched and always standing? This requires a script, which I will call the recursive script. By recursive, I mean that you can cycle through the script an infinite number of times. The intent is to execute one string of commands when you hit the bound key, then re-bind the key to execute new string of commands the next time you use the key.

The process is:

Step 1 - Name your script and add a short description of what it doesAdd your name and description after a comment (// - double-backslash) so that ET doesn't try to recognize it as a command. Assigning a good descriptive name will help you find your script later, and if you decide to share it with others, helps them understand what they're getting.

The set command tells ET that you are defining a line of commands that will be grouped and executed under the name [scriptline].[scriptline(n)] - is the name of one iteration or step in your script. If you have a large number of steps, start numbering with 1. If you have 4 steps, then the highest number should be 4. For scripts with a small number of steps, you can use simple names, just make sure that you don't use the same name twice.[command] - is the command or set of commands you want to execute with the script. Multiple commands should be separated by a semicolon ( ; ) like we learned in the Multiple Binds section. set [nextscriptline] - this tells the script to assign [nextscriptline] to execute the string of commands defined in [scriptline(n+1)] vstr [scriptline(n+1)] - is the name of the next alias in the sequence to be activated. Look at the weapon scripts. In the first iteration, I want to choose the SMG, but in the second, I want to reverse the sequence and choose the pistol. In your last iteration, make n=1 to start all over from the beginning. This will let your key cycle through all of the combinations you've written, then start all over from the beginning. You don't have to use a numerical sequence, but it might make it easier to keep track of. In any case, pick whatever you're comfortable with. echo [comment] - Any text that follows the echo command will be shown to you as an in-game message. I find this useful for reminding me what my script just did.

Step 3 - Assign dynamic variable to first 'step' in sequenceAfter you have finished writing the basic set of commands, use

set [nextscriptline] vstr [scriptline(n+1)]

This tells the computer that [nextscriptline] should start by executing [scriptline(n+1)]. Notice however, that every time you execute your script, the value attached to [nextscriptline] changes. Here's an example for the two weapon toggle:

set nextw-bank23 "vstr w-bank2"

Step 4 - Bind key to execute dynamic variableThe last step is to bind a key to execute your new script. We learned the syntax in the first step, Simple Binds. The final line in the weapon toggle looks like:

bind w "vstr nextw-bank23"

All this does is bind the key to execute the string of commands associated with [nextscriptline].

Here's what it looks like when it's all put together:

Try this out and play around a little. You'll be writing your own scripts in no time. Here are the examples: Link coming soon

TogglesAny command that can be set to either on or off, can be set up on a toggle. For example, you can set Always Run to either on (1) or off (0), therefore I can create a toggle that lets me switch between always on or always off. This has a couple of advantages:

In the case of the +speed (run) command, I don't have to hold down my SHIFT key to run or walk. If I want to sneak up on someone, I can hit the toggle to walk, and then hit it again when I want to resume running. This set up conserves keys. Instead of one button set to enable always run and another to disable it, I can consolidate everything to one key.

Look through your configuration for variables that take either a 0 or 1 value. Those are the commands that can be set up on a toggle.

Other ExecutablesI use these to clean up my autoexec.cfg. For ET, I have 30 different config files in addition to my basic configuration: one for each class, match graphics settings, demo record script, class selection scripts, team communications scripts,punkbuster,netports..etc,(I don´t/not gonna publish my multiconfig,because of some secrets,what only some peoples know). Having them in a separate file lets me share them with teammates, team comm binds for example, without having to send the entire autoexec. The other reason for this is config organization. If your configuration to too large, ET may have problems executing the whole thing. Seperate configs set up as executables enable you to reduce the overall size of your primary autoexec.

You can also combine this with a bind command, for example to exec a new set of key bindings for a new class. I use this technique because each class has slightly different binds based on their equipment and role in the game. This way, when I select a new class, I simplely hit the bound key, and I'm ready to play. Here's an example.

bind 7 "exec engineer.cfg"

Here's a schematic showing how all of my config files are related and executed

Notice that all of my key settings are actually saved in a file called ifurita.cfg, not autoexec.cfg. The file autoexec.cfg only has one line in it, exec ifurita.cfg. This autoexec can then be dropped into each mod folder which will then execute the single file, ifurita.cfg which resides in /Main. One advantage of this arrangement is that I don't have to edit multiple autoexec files whenever I change key assignments.

Resources and Intellectual PropertyThere are many scripters out there who create scripts for general community use. If you use these scripts or distribute them via autoexecs, it is considered good form to credit the original writer in your notes. If I have a script that is bascially a modfication of another scripter's work, his name goes into the credits. Enough of my soapbox.

Here are a couple of resources you might want to look up when writing scripts: