News
  News Archives
  Search
  Articles
  How To: RTCW
  Servers
  Scripts
  Staff

  Register a User


  Upload Stats
  Clan List
  Top 10
  Ladders
  Clan Stocks
  Future Matches
  Recruiting Center

  Quakecon 2020


  Quakecon 2020


  Quakecon 2020


  Discord (EU)
  Discord (NA)
  Facebook
  Maps
  OSP
  Reddit
  RTCW Chile
  RTCW Cups 2010+
  Stats processor



5136979 hits

Scripting for Dummies


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 RTCW 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?


I've added scripts to my basic configuration for three main reasons:



  1. Improve control flexibility (e.g., multiple weapon binds)
  2. Execute multiple functions with one keystroke (e.g., demo recording)
  3. 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 Q3:A scripts and Commander Keen's Quake 3 Arena Console Page for all of the different console commands and variables you might need while writing your scripts. the sites I've referred you to are Quake 3: Arena oriented sites, but since RTCW is based on the Quake 3 engine, most of the material should still work for you.









Script Organization



Scripts have to be saved in a separate .cfg file from your wolf_mp.cfg. The reason is that RTCW overwrites the wolf_mp.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. RTCW will not execute anything that follows a pair of double-backslashes (//).


Example of //



You can also use the Echo command (more on this later) to give yourself in-game messages when a script has been activated. We'll discuss this later, but you can go to some of the examples section and look at the crouch toggle and the demo recording script to see what in-game messages I give myself when the script is activated.





Back to Top





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.



Back to Top




Multiple Binds


We can also bind a key to execute multiple commands. Remember that RTCW 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 RTCW 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"




Back to Top




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 RTCW 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]"


  1. The set command tells RTCW that you are defining a line of commands that will be grouped and executed under the name [scriptline].

  2. [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.

  3. [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.

  4. set [nextscriptline] - this tells the script to assign [nextscriptline] to execute the string of commands defined in [scriptline(n+1)]

  5. 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.

  6. 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:




Try this out and play around a little. You'll be writing your own scripts in no time. Go to the Examples section to see a couple I've written.





Back to Top





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:

  1. 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.
  2. 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 I use in my 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.


Back to Top





Other Executables


I use these to clean up my autoexec.cfg. For RTCW, I have 8 different config files in addition to my basic configuration: one for each class, match graphics settings, demo record script, class selection scripts, and team communications scripts. 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, RTCW 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 are a couple of examples that I use in my RTCW autoexec.cfg

    exec engineer.cfg

    exec medic.cfg

    exec lieutenant.cfg

    exec soldier.cfg

    exec demorecord.cfg

    exec bindchats.cfg

    exec class-select-v1.cfg

    exec matchgfx.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




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.


Back to Top





Examples


I’ve included examples of several scripts I use to illustrate what we just covered. Use them as you like.



    // Changes names

    set gamename1 "name Frau Iffy; set nextname vstr gamename2; play sound/multiplayer/axis/g-affirmative"

    set gamename2 "name
    Sgt. Iffy; set nextname vstr gamename1; play sound/multiplayer/axis/a-affirmative"

    set nextname "vstr gamename1"

    bind x "vstr nextname"




    //Quick Grenade script (adapted from original script by RRZ|CorpseR)

    set quickgrenade "weaponbank 4; wait 90; +attack; -attack; wait 120; weapprev"

    bind x "vstr quickgrenade"




    //Crouching script, hit toggle first time to stay crouched, hit toggle second time to stand

    set crouch "+movedown; set nextcrouchtoggle vstr stand"

    set stand "-movedown; set nextcrouchtoggle vstr crouch"

    set nextcrouchtoggle "vstr crouch"

    bind x "vstr nextcrouchtoggle"



    //Quick Medic - switches to needle and crouches, then switches to SMG and stands

    set quickmedic1 "+movedown; weaponbank 5; set nextmedic vstr quickmedic2"

    set quickmedic2 "weaponbank 3; -movedown; set nextmedic vstr quickmedic1"

    set nextmedic "vstr quickmedic1"


    //Tosses airstrike cannister and then switches back to SMG

    bind g "weaponbank 5; +attack; wait 90; -attack; vsay_team FireInTheHole; weaponbank 3"


    //Pulls out binos, calls artillery, then switches back to SMG

    bind b "+zoom; wait 20; +attack; wait 20; -attack; wait 15; -zoom; wait 15; weaponbank 3;



    //Quick Medic - switches to needle and crouches - switches to SMG and stands
    set quickmedic1 "+movedown; weaponbank 5; set nextmedic vstr quickmedic2"

    set quickmedic2 "weaponbank 3; -movedown; set nextmedic vstr quickmedic1"

    set nextmedic "vstr quickmedic1"

    bind x "vstr nextmedic





This next script combines several of the concepts we have already discussed. It's recursive, but you can advance through the progression both forwards and backwards using either of the bound keys. Each step in the script also executes a sub-configuration because we want class-specific binds to be loaded when we change classes.



    //Other classes - keys scroll forwards and backwards through all Engineer-Medic-Lieutenant and weapon combinations

    set other1 "mp_playertype 2; mp_weapon 7; limboMessage Axis/Allied Engineer SMG; set nextother vstr other2; set prevother vstr other5; exec engineer.cfg"

    set other2 "mp_playertype 1; mp_weapon 7; limboMessage Axis/Allied Medic SMG; set nextother vstr other3; set prevother vstr other1; exec medic.cfg"

    set other3 "mp_playertype 3; mp_weapon 3; limboMessage Axis/Allied Lieutentant MP40; vstr otherweapons; set nextother vstr other4; set prevother vstr other2; exec lieutenant.cfg"

    set other4 "mp_playertype 3; mp_weapon 4; limboMessage Axis/Allied Lieutentant Thompson; set nextother vstr other5; set prevother vstr other3; exec lieutenant.cfg"

    set other5 "mp_playertype 3; mp_weapon 5; limboMessage Axis/Allied Lieutentant Sten; set nextother vstr other1; set prevother vstr other4; exec lieutenant.cfg"



    set nextother "vstr other1"

    set prevother "vstr other1"




You'll notice that I've reset the nextsoldier variable when ever I change class. I've done this because I want to always start my soldier rotation from 'Soldier armed with Thompson'.

    bind 9 "vstr prevother; set nextsoldier vstr soldier1"

    bind 0 "vstr nextother; set nextsoldier vstr soldier1"




    //Quick Medic (adapted from original script by RRZ|CorpseR)

    set quickmedic "+movedown; weaponbank 5; wait 90; +attack; wait 90; -attack; weaponbank 6; wait 90; +attack; wait 90; +attack; wait 90; -attack; -movedown; weaponbank 3; echo
    EXECING QUICK MEDIC"

    bind x "vstr quickmedic"




This script is a little different from the Quick Medic script because it's interrupted by a manual component (arming the dynamite). The reason for this is that engineers are often planting their dynamite under enemy pressure. Some times you may be forced to plant, and then defend yourself. There's also the possibility that you might throw down your dynamite and then 'miss' when you try to arm it. Lastly, by default, you immediately switch to pliers after dropping the dynamite. To me, the cost of missing the arm far outweighed the additional speed potentially gained by making the dropping and arming process completely automated.



    //Quick Engineer - crouch and set dynamite (script part 1) - arm with pliers (manual) - warn and switch back to SMG (script part 2)

    set quickengineer1 "+movedown; weaponbank 6; wait 90; +attack; wait 60; -attack; set quickengineer vstr quickengineer2; echo
    NOW ARM DYNAMITE AND HIT B WHEN FINISHED; -movedown"

    set quickengineer2 "vsay FireInTheHole; weaponbank 3; set quickengineer vstr quickengineer1"

    set quickengineer "vstr quickengineer1"

    bind x "vstr quickengineer"




Here's an example of a recursive script that executes another recursive script to record demos. The nested script ensures that each demo recorded has its own name to prevent overwriting a demo that has been already created.



    // Demo Recording Script - Starts and stops a recording for a group of demos

    set toggle1 "g_syncronousClients 1; vstr nextdemo; g_syncronousClients 0; set nexttoggle vstr toggle2"

    set toggle2 "stoprecord; set nexttoggle vstr toggle1; echo Stop
    Recording ..."

    set nexttoggle "vstr toggle1"

    bind j "vstr nexttoggle"


    set demo1 "record gamedemo1; set nextdemo vstr demo2; echo Recording Demo #1"

    set demo2 "record gamedemo2; set nextdemo vstr demo3; echo Recording Demo #2"

    set demo3 "record gamedemo3; set nextdemo vstr demo4; echo Recording Demo #3"

    set demo4 "record gamedemo4; set nextdemo vstr demo5; echo Recording Demo #4"

    set demo5 "record gamedemo5; set nextdemo vstr demo6; echo Recording Demo #5 - last demo"

    set demo6 "echo no more demos"

    set nextdemo "vstr demo1"







Back to Top





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:


Please Login to PlanetRTCW


Team Special America. Very Special
Team Special America. Very Special

(Submit POW)

Irc Channel:
irc.gamesurge.net,
#PlanetRTCW

Top Stock Prices
US/flagrant/139.92
US/np./139.78
US/blatant/109.97
US/LLC/109.08
US/dont-blink/108.99

Recent Articles
Aggregate Performance Metric, Pt. III - Examples
(57 views)
(0 comments)
For the previous articles, see Aggregate Performance Metric, Pt. I - Overview and Aggregate Performance Metric, Pt. II - Breakdown. Here...

Aggregate Performance Metric, Pt. II - Breakdown
(64 views)
(0 comments)
For the previous article, see Aggregate Performance Metric, Pt. I -...

Aggregate Performance Metric, Pt. I - Overview
(109 views)
(2 comments)
Introduction In anticipation of Wolf PRO being released sometime in the near future, I developed a new framework for ranking players which...

Movies 2008
(470 views)
(5 comments)
Here is a list I compiled of my picks for movies in 2008. There is nothing else really going on with this site, but I figured you guys would...

Things That Would Make RTCW Better.
(645 views)
(3 comments)
RTCW has been one of the most balanced, attractive, addictive game since it came out. Not too many games are fit for competition mode right off the...

Which map is missing from QuakeCon?

Aldersnest
Password
Tundra
Cipher
Sub
Chateau
UFO
Keep

 


(Previous Polls)

 

printer-friendly Printer view
 

PlanetRTCW (planet-rtcw.donkanator.com) is 2003-2004 Mithun Balachandran and Robert Dyer.
Best viewed in Internet Explorer at 1024x768x32-bit color.
Return to Castle Wolfenstein is a registered trademark of id Software.
OSP and related material is property of rhea and Orange Smoothie Productions.
All other names or logos listed on this site are property of their respective owners.