Jump to content

  • Log in with Facebook Log in with Twitter Log In with Steam Log In with Google Sign In
  • Create Account

Tutorial info Visit support topic

  • Added on: Feb 16 2011 05:25 AM
  • Date Updated: Feb 18 2011 11:20 AM
  • Views: 3392
 


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.

Posted by Dupstep on Feb 16 2011 05:25 AM
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.

First, why write scripts and what do they do for you?

My config has some things added:

  • Improve control flexibility (e.g., multiple weapon binds)
  • Execute multiple functions with one keystroke (e.g., demo recording)
  • Facilitate config customization for multiple mods or classes (e.g., Engineer vs Medic)

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)

Posted Image





Basic Binds
Binding 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 Binds
We 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.

bind F11 "cg_draw2d 0;cg_drawgun 0; wait; wait; wait; screenshot; toggle cg_draw2d; toggle cg_drawgun"



Recursive Scripts
Everything 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 does
Add 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.

// SMG-Pistol toggle

Step 2 - Write commands for each 'step' in the script

set [scriptline(n)] "[command]; set [nextscriptline] vstr [scriptline(n+1)]; echo [comment]"

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.

Here's an example for a two-weapon toggle:

set w-bank2 "weaponbank 2; set nextw-bank23 vstr w-bank3" set w-bank3 "weaponbank 3; set nextw-bank23 vstr w-bank2"



Step 3 - Assign dynamic variable to first 'step' in sequence
After 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 variable
The 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:
Posted Image

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


Toggles
Any 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.

The syntax is:

bind [key] "toggle [command]"

Here are a couple of examples that you could use in autoexec.cfg

bind SHIFT "toggle cl_run"
bind F2 "toggle r_fastsky" //Speed toggle
bind F3 "toggle cg_drawFPS" //Displays Frames per Second
bind F4 "toggle cg_drawTimer" //Displays timer
bind F5 "toggle cg_thirdperson" //Shows model in thirdperson view
bind F6 "toggle cg_drawgun" //Shows gun


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 Executables
I 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.

The syntax is:

exec [filename.cfg]

Here is my autoexec build up:

// DUPSTEPS CONFIG IS READY FOR KILL CHUCK NORRIS
//
// +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
// |D|e|l|u|x|X|e| |E|d|i|t|i|o|n|
// +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
//
//Settings/Binds
exec cfg/settings.cfg

//User settings
exec cfg/user.cfg

//ETpro settings
exec cfg/etpro.cfg
exec cfg/etpro_lua.cfg

//Client settings
exec cfg/client.cfg

//Userinterface settings
exec cfg/userinterface.cfg

//Input settings
exec cfg/input.cfg

//Common's
exec cfg/common.cfg

//Bob's
exec cfg/bobs.cfg

//Net Work
exec cfg/network.cfg

//Punkbuster
exec cfg/punkbuster.cfg

//Crosshair
exec cfg/crosshair.cfg

//Sound
exec cfg/sound.cfg

//render
exec cfg/render.cfg



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
Posted Image

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 Property
There 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: