🚀 go-pugleaf

This was goooooooood Awebb!!!!!
McG.

"Awebb" <masterfreak@arcor.de> wrote in message 
news:463631ad$0$23142$9b4e6d93@newsspool1.arcor-online.net...
> OscartheGrouch schrieb:
>> "Profil1" <jay@neostrada.pl> wrote in message
>> news:f0vv66$llb$1@nemesis.news.tpi.pl...
>>> Is there an option in the game to do so, or do I have to use some 
>>> commands
>>> for it? If command are needed couls somebody paste me an example?
>>>
>>> Cheerio
>>>
>>>
>>
>> bind r "use rocket launcher" etc.
>>
>>
>
> This is the best tut i know:
>
>
> --------------------------------------------------------------------------
>
>
> Quake 2 Console Tutorial
> Abstract
>
> Author: JakFrost
> Email: jakfrost(at)planetquake(dot)com
> Web Site: http://www.planetquake.com/console/
> Created: January 23, 1998
> Last Modified: May 18, 2000
> Based On: Quake 2 v3.12
> Source: http://www.planetquake.com/console/tutorials/quake_2.html
>
> Copyright (C) 1998-2000 JakFrost, All Rights Reserved
>
> This document is a tutorial for the Quake 2 console. It describes all
> aspects of the console; such as the syntax, the usage of commands and
> variables, the creation of aliases and bindings, and script. There is a
> great amount of information contained in this tutorial which should help
> anybody who is willing to read it and learn from it.
> Table Of Contents
> Introduction
> Foreword
> Document Conventions
> Definitions
> The Console
> Introduction
> Syntax
> Special Characters
> Dollar Sign
> Double-Quote
> Double-Slash
> Newline
> Semicolon
> Space
> Console Commands
> Introduction
> Commands
> Action
> Function
> Operation
> Variables
> Bitmap
> Command Line Parameter
> Register
> String
> Toggle
> Bindings
> Introduction
> Single Command
> Multiple Commands
> Aliases
> Introduction
> Simple Aliases
> Advanced Aliases
> Action
> Toggle
> Scripts
> Introduction
> The Outside
> Idea
> Execution
> The Format
> The Inside
> Bindings
> Aliases
> Settings
> Documentation
> Afterword
> Version Information
> Legal
> Copyright
> License
> Trademarks and Servicemarks
> Warranty Disclaimer
> 1. Introduction
> 1.1. Foreword
>
> I have decided to write this document to better educate the Quake 2
> players about the console and its powerful use. The console is very easy
> to use and very easy to understand. Now all of those Quake 2 players who
> have wondered about aliases and bindings will have a clear picture of
> what everything means. After reading and understanding this document the
> console will lose its mystic value and will become just another part of
> Quake 2.
>
> This is actually my second console tutorial. I have written one before
> this for the Quake console. That tutorial did explain a lot of things
> about the console but it did not go into such detail as this tutorial
> does. That tutorial was like a beta version of this tutorial to tell you
> the truth. By the way, the Quake console is almost identical to the
> Quake 2 console, so even though this is a Quake 2 tutorial and I'm using
> Quake 2 specific commands all of the same ideas can be applied to Quake.
>
> I would like to recommend that while reading this document you take a
> look at the Quake 2 Console Commands document which is available at this
> site. That document will become an invaluable tool for you in the
> understanding of the console. All of the console commands and console
> variables are described in that document. With this tutorial and that
> document you will be making aliases and scripts in no time.
>
> I hope you enjoy this tutorial and that it increases your knowledge of
> Quake 2 in some way. Enjoy...
> 1.2. Document Conventions
>
> Right now I would like to touch-up on a couple of conventions that I use
> though this document. It is very important to understand exactly what
> these conventions. Don't worry these conventions are very similar to
> other conventions used in technical documents, so if you ever read a
> technical document before you will feel right at home. In case you are
> wondering, I took these conventions right out of the definitions that
> are given for them in the HTML Recommendations for the specific markup 
> tags.
> Code
> I use the convention of code to designate the names of commands or words
> which appear exactly in the console. Anything that is designated as code
> stays the same, which is the opposite of variable which would change.
> For example in the syntax of a command the word "command" is designated
> as the code since it stays the same throughout the console. The example
> of the syntax for a command would be 'command (parameter)'.
> Keyboard
> I will sometimes use the convention of keyboard input to designate the
> name of a key that should be pressed. For example I would say something
> like "...and bind that command to the pgup key." I will usually name the
> key the same as it is named by Quake 2.
> Quotation
> If I want to show an example inside a paragraph I will use single-quotes
> ( ' ) to quote the whole example. For example, I would quote the example
> such as 'command (parameter)' to show syntax information, or 'bind
> mouse1 +attack' to show the exact string of code. The reason why I quote
> whole lines of code is to make it easier to differentiate between the
> text in a paragraph and the example itself.
> Sample
> I will usually use the convention of sample code to show off whole
> strings of commands which are used in the console. When something is
> designated as a sample, it should be used exactly as shown. An example
> of a sample code would be 'bind mouse1 +attack'. This is somewhat
> similar to my use of the code convention but they are not exactly the 
> same.
> Variable
> Variables are parameters which change from one use of a command to
> another. The command stays the same, it's the variables that change. For
> example in the example of the syntax of a command the word "parameter"
> is designated as a variable since it can be anything, a word, a number,
> etc. The example of the syntax for a command would be 'command 
> (parameter)'.
>
> Throughout this document you might see examples of code. Most of the
> code that I show in this tutorial is taken right from my very own Quake
> 2 script. You will probably see a lot of familiar things along the way.
> I chose to use examples from my script because it is better to use
> examples from the real world than some made up ones. Soon after you will
> learn a lot of things from my script and will become familiar with the
> way that I play. Consider this an extra benefit like a extra tutorial on
> a comfortable playing style. :)
> 1.3. Definitions
>
> Below are a couple of confusing terms which I decided to describe. This
> is just a precaution to make sure that I don't mislead anybody with
> weird words that I make up and use.
> command
> A command is bridge to a function which is carried out by the game. The
> player uses commands to interact with the game through the console.
> console command
> A console command is a regular command which takes one or more
> parameters. A console command is just a name of the group of commands to
> go along with the name "console variables".
> console variable
> A console variable is a command which holds an alphanumeric value. I
> might refer to console variables as commands, since they act the same as
> console commands.
> executable string
> An executable string is a single line of code which is executed by the
> console. The ending of an executable string is a carrige-return or a
> newline which is produced by the ENTER key. An executable string might
> be composed of a command, its parameters, and special characters.
> parameter
> A parameter is a value which is used with a command to execute a
> specific function. Some commands accept parameters which change the
> function of the command to carry out a different task.
> 2. The Console
> 2.1. Introduction
>
> The console is a wonderful idea for a game as complex as Quake 2. It
> allows the player to have a lot of control and more chances to customize
> the game to his liking. It's no wonder that the console was implemented
> in this game; it would be quite hard to make a menu system to access all
> the different features that this game offers. The console is a very
> powerful tool and is very useful to the player.
>
> First off, the easiest way to access the console is to hit the ~ (tilde)
> key which is located to the left of the 1 key on and above the TAB key
> on the keyboard. It is very easy to access the console, and you can do
> it even if you are inside the game playing on a map. All of the features
> of Quake 2 are accessed and set with the console or with the menu if you
> don't know the appropriate commands.
>
> It is also possible to access the console from outside the game by using
> the operating system command line to pass commands to the console before
> the game is loaded up. The way that this works is that you specify
> parameters after the name of the executable file to run Quake 2. The
> name of the console command has to be preceded by the + character to
> indicate that it is a console command. An example of this would look
> like 'quake2.exe +exec myscript.cfg +map base1'.
> 2.2. Syntax
>
> First, what "syntax" means is how commands and parameters are put
> together to form acceptable strings. There are certain rules to follow
> when putting in commands together with their parameters for the console
> to understand. The syntax for the Quake 2 console is very simple so
> don't worry about remembering a lot of weird things. It's all logical.
>
> Any executable string for the console is made up of a couple of parts
> usually. The main part is the command. Sometimes the command is
> accompanied by parameters for that command. Sometimes there are even
> multiple commands in an executable string. A simple executable string
> might be 'alias' which is just composed of the single alias command. A
> more complex string might be 'alias foomsg "say I am the Foo Master!"',
> which is composed of the alias command and it's parameters. Another
> example of a complex executable string might be 'set name JakFrost;set
> skin male/howitzer', which is composed of two instances of the set
> command and some parameters.
>
> As you notice each of the above mentioned examples of executable strings
> always has the command. Sometimes the command has parameters, and
> sometimes there are more than one command on a single line. Basically
> you can divide an executable string into commands, parameters, and
> special characters. As you noticed the second example used quotes in the
> executable string, and the third example used the semicolon ( ; ). These
> are special characters to the console and they have special meanings.
> The sections below will describe exactly what these characters do and
> how to use them.
> 2.3. Special Characters
> 2.3.1 Dollar Sign
>
> The dollar sign is the $ character. This character is special in a sense
> that it allows for the substitution of a variable name preceded with the
> dollar sign character into the value which is held by that variable. The
> power of this is that you can display the values that variables hold and
> you can even copy the values from one variable to another, and back.
> This allows for an alias to copy the original value of a variable into a
> backup variable, change the value of the original variable to execute
> the alias, and after it is finished the original value from the backup
> variable is copied into the original variable. This way, the alias will
> return the variable to its original state.
>
> Before this feature was implemented, all of the aliases which had to
> modify variables would change the variable to a preset value that was
> stored in the alias. This was problematic in that the player had to
> change every value in the alias so that those values would be put into
> the variables after the alias finished executing. If a player set a
> variable to a setting which was different than the one that appeared in
> the alias, then after the alias was executed the changes to that
> variable would be lost because the alias would set the variable into the
> preset value stored inside the alias.
>
> Also, I would like to mention something about creating backup variables
> to store values from the original variables. I personally create a
> backup variable with the same name as the original variable, except that
> I append the character - to the end of the backup variable. So, if I
> made a backup variable of the name variable, the backup variable would
> be name-. By using this technique you can be sure of what the backup
> variable is holding. I think that this is a much better solution, than
> creating backup variables with extraneous names like temp, backup, or a.
> This is just a little thing I picked up while learning about Linux. :)
> echo $name
> echo $sensitivity
>
> In the examples above, the echo command displays the value of the name
> and sensitivity variables.
> set myname $name
>
> In the example above the myname variable is created with the copied
> value from the name variable.
> set coolname "$name is the Foo Master"
> echo $name is the Foo Master
>
> In the example above the coolname variable is created which takes the
> value from the name variable and appends the string " is the Foo Master"
> to it. In my case the value of the coolname variable would be "JakFrost
> is the Foo Master". The second example just displays the string
> "JakFrost is the Foo Master". These examples show that the displayed
> values can appear inside strings or strings can be appended to the values.
> // Rocket Jump Quake 2 Alias - Custom Version
> alias +rj "rj1;rj2"
> alias rj1 "set cl_pitchspeed- $cl_pitchspeed;cl_pitchspeed
> 100000;wait;+lookdown;wait;-lookdown;set cl_pitchspeed $cl_pitchspeed-"
> alias rj2 "set hand- $hand;hand 2;+moveup;+attack;echo Rocket Jump"
> alias -rj "-attack;-moveup;set hand $hand-;centerview"
>
> The example above is a version of the Rocket Jump alias which works no
> matter what is the setting of the hand variable. The alias above will
> save the value in a backup hand- variable, it will then set the value of
> hand to 0 so that the rocket is fired from the center of the body. After
> the alias is finished, the value from the backup hand- variable will be
> restored into the hand variable. This allows the player to hold the gun
> in any hand that he wishes, and still make this alias work. The same
> principle is used with setting the value of the cl_pitchspeed variable
> to allow instantaneous look down speed.
> 2.3.2. Double-Quote
>
> The double-quote is the " character. This pair of special characters is
> used to reverse the function of the special characters, space, and
> semicolon. Unlike the space and the semicolon which are used to
> separate, the double-quote is used to joining. Usually when a command
> accepts only a single parameter but you must include a space or a
> semicolon in that parameter you would use double-quotes to enclose that
> string to form a single parameter. Examples of such commands are the
> alias and name commands which will be discussed later.
> name "The Foo Master!"
>
> In the example above the double-quotes were used to pass the name which
> is composed of three words separated by spaces as a single parameter to
> the name command.
> alias +grapple "use grapple;+attack;echo Quick Grapple"
>
> In the example above the double-quotes were used to make the string of
> commands into a single parameter which will be used by the alias
> command. As you notice, the string contains spaces and semicolons.
> 2.3.3. Double-Slash
>
> The double-slash is the // character pair. This pair of characters
> signifies a comment. It is usually found inside script files where
> authors chose to leave comments on their work. Anything after the pair
> of characters is ignored as a comment and is not executed. It is
> possible to include a comment on the same line that an executable string
> is on but I recommend that comments should appear on a separate line
> above the code to be commented. It is also possible for the comments to
> appear on the same line as the executable string but I don't recommend
> that practice.
> // Quick Grapple Quake 2 Alias
> alias +grapple "use grapple;+attack;echo Quick Grapple"
> alias -grapple "-attack"
>
> In the example above, the double-slash was used to comment on the name
> of the alias that was used and also on the name of the author for that
> alias. This is one of the aliases which I use in my script.
> // These are the user settings that I use when I play the game.
> set msg 1
> set name JakFrost
> set skin male/howitzer
>
> In the example above, the double-slash was used to make a comment on
> what the commands below are used for.
> 2.3.4. Newline
>
> The newline character is the carrige-return character and is invisible.
> It is invoked by the ENTER key. The importance of this character is that
> is separates commands, just like the semicolon separates commands. Even
> though this might seems like a very basic concept, I felt that it was
> important to mention this.
> set m_pitch -0.022
> set sensitivity 17
>
> In the example above the two instances of the set command are separated
> by the invisible newline character. If the newline character was
> missing, the commands would not execute properly.
> 2.3.5. Semicolon
>
> The semicolon is the ; character. The semicolon character is a very
> important one. It allows the grouping of multiple commands on a single
> line. This is a great feature which is very useful when making complex
> aliases or bindings. The semicolon will become a very useful feature
> once you start creating complex scripts.
> alias +sz "set fov- $fov;fov 20;m_pitch -0.004;m_yaw 0.004"
> alias -sz "set fov $fov-;m_pitch -0.022;m_yaw 0.022"
>
> In the example above, you will notice that the semicolon was used to
> separate three different commands inside the Sniper Zoom alias.
> 2.3.6. Space
>
> The space is the invisible separator character. The space character is
> another separation character. This character is similar to the newline
> character but instead the space character separates commands from their
> parameters and parameters from other parameters. The space character is
> also used to separate words when using strings for parameters.
> set cl_run 1
>
> In the example above, you will notice that the set command was separated
> from its first parameter by a space, and the first parameter was
> separated from the second parameter by another space.
> 3. Console Commands
> 3.1. Introduction
>
> Console commands are the commands which are used to carry out certain
> tasks with the console. There are two major classes of console commands.
> The first class is the commands which are basically all the left over
> commands from the variables class. The variables class is second major
> class of console commands. The difference between a console command and
> a console variable is that a console command performs a certain task
> where the console variable is only used to display or store a value.
>
> There are also sub-classes for console commands and variables. These
> sub-classes are all extraneous to the game, which means that I just use
> them to describe the syntax for a specific command or a variable and
> that the game doesn't know anything about these different classes. I
> felt that it was necessary to classify commands since it is much easier
> to explain the usage of a command or a variable if you group the
> appropriate commands and variables. Some of these classes might be
> merged but I felt that it was necessary to have these very separate
> groups to avoid any confusion.
>
> A lot of this information was taken directly from the Quake 2 Console
> Commands document which has a section devoted to grouping and
> identifying the different classes of commands and variables.
> 3.2. Commands
> 3.2.1. Action
>
> An action command performs an action when the +action part of the
> command is executed and terminates that action when the -action part of
> the command is executed. When an action command is bound to a key, the
> +action is executed when the key is pressed, and the -action is executed
> when the key is released. The default syntax for an action is +command
> or -command.
>
> It is possible for you to make your own action commands by creating two
> aliases, one starting with a + and another one with -. The beauty of
> action commands is that their use is only momentary, so you can create
> special aliases or functions which only work for as long as a key is
> held down.
> 3.2.2. Function
>
> A function command performs a single function based on the parameters
> included for that operation. A function usually has extra parameters and
> they are usually necessary for the proper execution. The default syntax
> for a function is 'command (parameter)'. All function commands have
> their own unique syntax.
> 3.2.3. Operation
>
> An operation command performs a single function in the game every time
> the command is executed. It does not use any parameters. The default
> syntax for an operation is 'command'.
>
> An operation is exactly the same as a function, except that it does not
> accept any parameters at all. I felt that it was important to make this
> group because it is important to know if a command accepts parameters or
> not. I would be pretty funny if somebody was trying to pass parameters
> onto an operation command and then get angry that it's not working
> because he didn't know that it does not accept any parameters.
> 3.3. Variables
> 3.3.1. Bitmap
>
> A bitmap variable is able to toggle more than one feature by using a
> single value. The way that a bitmap variable works is that a value is
> assigned to each bit. Each bit is like a toggle, only being able to be
> set to an off and on value. To turn on the desired features all the
> values representing individual bits are added together. The default
> syntax for a bitmap variable is 'variable (value)'. Allowable values for
> a bitmap variable include integers only.
>
> A bitmap variable might be the toughest one to explain of all of them
> since it involves a little knowledge of programming and the binary base
> system. I'll try to do my best to explain this, since it's important to
> understand it.
>
> Ok, let's take the variable dmflags for example. As you might or might
> not know, it allows the setting of all the different features for
> deathmatch, such as if weapons disappear and respawn, if health is
> available on the level, or if weapons have infinite ammo. So, one
> command is able to set all of these features independently of each other
> with only one value.
>
> I really don't want to get into the binary part of the explanation here,
> so I'm going to avoid that topic. For example, let's say that you wanted
> to create a total blood bath game and wanted to use the settings of: no
> health, no powerups, weapons stay, spawn farthest, force respawn, no
> armor, and infinite ammo. You would set a value of 11783 because 1 + 2 +
> 4 + 512 + 1024 + 2048 + 8192 = 11783. The reason for this value is that
> each setting represents a value, and to achieve all of the settings you
> have to add all the values. If for example you wanted to create another
> game of deathmatch which is not as bloody you might choose the settings
> of: weapons stay, instant powerups, and spawn farthest. You would set
> the value of 532 because 4 + 16 + 512 = 532.
>
> Below is a list of the settings to the dmflags variable. This list will
> make it easier to understand the explanation.
>
> 1 - No Health.
> 2 - No Powerups.
> 4 - Weapons Stay.
> 8 - No Falling Damage.
> 16 - Instant Powerups.
> 32 - Same Map.
> 64 - Teams by Skin.
> 128 - Teams by Model.
> 512 - Spawn Farthest.
> 1024 - Force Respawn.
> 2048 - No Armor.
> 4096 - Allow Exit.
> 8192 - Infinite Ammo.
>
> The reason why all of this works is because each of the values
> represents a single bit. When you use a setting with that value in it,
> that bit is turned on. The bit representation for the value of 532 is
> 1000010100. If you notice, for that value I chose to only turn on 3
> settings thus you have three instances of the number one. I chose to use
> the setting of "weapons stay" which has the value of 4 and from the list
> above is the third one from the top. If you notice the third bit from
> the right is turned on. The same rule applies to the other two settings.
> By now, I hope that you have seen that each bit has a specific value
> associated with it. For example the value of 8 determines the value of
> bit number 4.
> 3.3.2. Command Line Parameters
>
> A command line parameter is a variable which is set from a command line.
> The reason for setting a variable from the command line is that some
> variables are write protected once the game starts and cannot be
> changed. Command line parameters are usually used to enable or disable a
> handful of features before loading up the game. The default syntax is
> "quake2.exe +set variable (value)".
>
> This variable has replaced the old use of the command line parameters
> which started with a dash -parameter. This is an advantage because you
> can check inside the game if a command line parameter has been accepted
> correctly or not. The old use of command line parameters was limited in
> that the user had to guess if the value has been accepted or not.
> 3.3.3. Register
>
> A register variable is able to store any type of numeric information.
> Register variables are used for numeric data which does not have clearly
> defined boundaries. The default syntax for a register variable is
> "variable (value)". Allowable values for a register variable include
> integers, fractions, and negative values.
>
> This group of variables is similar to the command group of functions in
> that all the left over variables are put into the group. Registers
> usually hold numeric information, sometimes positive numbers, negative
> numbers, whole number, or fractions.
> 3.3.4. String
>
> A string variable is able to store any type of text information. The
> default syntax for a string variable is 'variable "(text)"'. Allowable
> values for a string variable include all numbers and all text characters.
>
> The reason for string variables is to allow the storing of human
> readable information, such as names, addresses, or other things. It
> should be clear to see why string variables exist in the game.
> 3.3.5. Toggle
>
> A toggle variable is able to turn a feature on, off, or set to an
> alternative setting. All the values for a toggle are integers, usually
> only 0 and 1. Sometimes there are alternative settings for a toggle, in
> which case subsequent numbers are used. The default syntax is 'variable
> (value)'. Allowable values for a toggle variable include integers only
> in increments of 1.
>
> Toggle variables are a little similar to bitmap variables but toggle
> variables are only able to store the information about one setting
> instead of multiple settings.
> 4. Bindings
> 4.1. Introduction
>
> Bindings allow the connection of commands to keys. The binding of keys
> is done with the use of the bind command. This command allows the player
> to bind a command or a series of commands to a key or a button. This is
> very useful for a number of reasons. Because of this command, you will
> be able to hit a key and have a single command executed or a whole bunch
> of commands. This command also allows the input devices such as the
> keyboard and mouse to serve as an interface to the console.
> 4.2. Single Command
>
> A single command binding is the most simple of all bindings. It just
> binds a single command to a key. All of the action commands are bound
> with the use of a single command binding.
>
> In the example below you see the bindings of all the movement keys which
> I use. You will notice that the binding is composed of the bind command,
> the key to bind such as e, and the command which should be bound to the
> key which would be +forward.
> bind e +forward
> bind s +moveleft
> bind d +back
> bind f +moveright
> bind alt +movedown
> bind space +moveup
>
> In the example below you will notice that the keys F7 and F8 were bound
> to non-action commands. Just another simple example.
> bind f7 menu_keys
> bind f8 menu_video
> 4.3. Multiple Commands
>
> The binding of multiple commands is somewhat more advanced. It allows
> one key to perform multiple functions. The benefit of this is that it
> allows the creation of key-stroke saving keys, where you press one key
> and it executes a frequently used list of commands.
>
> In the example below, you will notice that three commands have been
> bound to the keys. Each command was separated by the semicolon character
> which is used especially for separating commands. One thing to remember
> is that when binding multiple commands you have to enclose the commands
> in double-quotes since the semicolon character and spaces were used.
> bind F6 "echo Quick Saving...; wait; save quick"
> bind F9 "echo Quick Loading...; wait; load quick"
> 5. Aliases
> 5.1. Introduction
>
> Aliases is where the real power of the console lies. With aliases you
> can create very elaborate strings of commands to perform almost any
> function imaginable. Aliases kind of imitate commands in that after an
> alias is created you can execute the commands for that alias just by
> specifying the name of the alias. The only real draw back that aliases
> have is that they can't accept parameters like real commands do.
>
> It is possible to create an alias which will execute another aliases.
> For as long as the game is concerned an alias is an operation command.
> You can create an alias which will execute other aliases and in turn
> those other aliases execute even more aliases. So as you see, you are
> not only limited to using aliases for commands or variables, you can
> create execution trees of aliases. You can even create other aliases
> from inside aliases.
>
> There are different types of aliases. There are those very simple
> aliases which are just strings of commands executed by the use of the
> alias name. Then there are action aliases which mimic the action
> commands. There are also toggle aliases which kind of mimic the toggle
> variables. There are also more advanced aliases then those, but they are
> too complex to try to classify.
> 5.2. Simple Aliases
>
> Simple aliases are just strings of commands condensed into a single
> command which is the name of the alias. Simple aliases are usually used
> to save time on frequently used commands, they are also quite similar in
> syntax and use to the single command bindings.
>
> In the example below is an alias which when executed would execute the
> commands within it. As you see the string is composed of the alias
> command, the name of the alias which is settings, and the following
> commands which are separated by semicolons.
> alias settings "set msg 1;set name JakFrost;set skin male/howitzer"
> 5.3. Advanced Aliases
>
> There are aliases which I chose to classify as advanced aliases because
> their functions are not as basic as the simple aliases. There are a
> bunch of advanced alias groups, and each one differs from another by the
> function and the type of coding that is used.
> 5.3.1. Action
>
> Action aliases are just like action commands in all respects. The
> benefit of using action aliases is for special functions which only
> should be active when a key is pressed and held down, and when the key
> is released that function should stop.
>
> In the example below you have the famous Quick Grapple alias. As you
> notice it is actually two aliases. One starts with the + character and
> enables the function as long as the key is pressed and held down. The
> other starts with the - character and disables the function once the key
> is released.
> bind x +grapple
> alias +grapple "use grapple;+attack;echo Quick Grapple"
> alias -grapple "-attack"
> 5.3.2. Toggle
>
> Toggle aliases are similar to toggle variables, in that they usually
> turn a feature on or off. Sometimes though, toggle aliases select from a
> list of settings which necessarily does not involve the enabling or
> disabling of a feature. The benefit of using such aliases is that you
> can choose from a list of options just by using one alias instead of
> having to resort to using multiple aliases.
>
> In the example below you have an alias which will cycle through all the
> settings for setting the crosshair. The name of this alias is ch which
> stands for crosshair. The first line of this alias creates the initial
> setting in that when the ch alias is executed it will execute the ch1
> alias. When the ch1 alias is executed by the use of the ch alias it will
> in turn set the ch alias to execute the ch2 alias next time. Because of
> this, a cycle is created which allows the single ch alias to execute all
> of the other aliases on subsequent executions. The other part of the
> other aliases sets the crosshair toggle variable to another setting and
> displays a message to the player.
> bind x ch
> alias ch ch1
> alias ch0 "alias ch ch1;crosshair 0;echo Crosshair Off"
> alias ch1 "alias ch ch2;crosshair 1;echo Crosshair 1"
> alias ch2 "alias ch ch3;crosshair 2;echo Crosshair 2"
> alias ch3 "alias ch ch0;crosshair 3;echo Crosshair 3"
>
> The example below is very similar to the example above, except that a
> different coding was used to perform the same function. As you notice
> the bind command was used to achieve the cycling effect. In this alias,
> every time an alias is executed the X key is rebound to another alias.
> This type of a toggle alias is not as flexible as the above version in
> that if the player wants to move the alias to another key, he has to
> change every instance of the bind command instead of just changing just
> one like in the alias above.
> bind x ch0
> alias ch0 "bind x ch1;crosshair 0;echo Crosshair Off"
> alias ch1 "bind x ch2;crosshair 1;echo Crosshair 1"
> alias ch2 "bind x ch3;crosshair 2;echo Crosshair 2"
> alias ch3 "bind x ch0;crosshair 3;echo Crosshair 3"
> 6. Scripts
> 6.1. Introduction
>
> Scripts are files which have been made by players to hold their aliases,
> bindings, and settings. Scripts are quite useful in that all the
> information necessary for setting up the controls for the game reside in
> a single file.
>
> The benefit of that is that you can take that single file to other
> computers and use it, or distribute the file on the Internet for other
> people to see. The problem with putting settings in the config.cfg file
> is that it is modified by Quake 2 every time it boots and it does not
> maintain aliases. Another benefit of scripts is that only the
> information for setting the bindings and controls are stored in the file
> so that settings which are specific to the computer are not stored in
> the file. The reason why this is a benefit is that if you move the
> script from one computer to another you don't have to worry about sound
> or video card settings for that computer. It is also easier to edit a
> script which is cleanly made instead of having to go through all the
> crud that's inside the config.cfg file.
> 6.2. The Outside
> 6.2.1. Idea
>
> Basically before making a script you have to have an idea of what it is
> and what it does. It is also a good idea to know what purpose the script
> is supposed to serve. Most of the time scripts are made to be
> distributed to other computers or given to friends.
>
> The script file should hold information which is only necessary for
> settings the controls and settings for the player and should not contain
> any information which is specific to the machine. The reason for this is
> that it is much easier to distribute scripts like that since the
> receiving person doesn't have to go through the script file and take out
> all the instances of code which is computer dependent, such as the video
> card settings, or the sound settings. Usually, it's a good idea to place
> all of the necessary bindings, all of the aliases, and a couple of
> player dependent settings inside the script.
> 6.2.2. Execution
>
> Before you go off and starting making aliases and scripts you should
> first think where you are going to put all of that work. First, you
> should think of a filename where your script is stored. It is not a good
> idea to store your script inside the autoexec.cfg in the quake2/baseq2/
> directory because that file should be kept as small and possible only
> with links to other files which should be executed. Think of a file
> name, maybe one that is based on the nick name that you use when you
> play. For example, for my script I chose the filename of jf_q2cfg.cfg.
> Also, make sure that when you make your script file that you place it in
> the quake2/baseq2/ directory.
>
> If you ever want to create scripts which are made up of more than one
> file then you should create your own directory to keep all of those
> files there and not clutter up the main directory. For example, I would
> make a directory like quake2/baseq2/jf_q2cfg/ to hold all the files if I
> made a large script. It's a good idea to be organized and not clutter up
> your system, that's what directories are for.
>
> The way that you want to have your script executed by Quake 2 is to put
> in a line like 'exec jf_q2cfg.cfg' in the quake2/baseq2/autoexec.cfg
> file. That file is executed by Quake 2 every time that Quake 2 is
> started up. Remember, avoid putting in other commands into the
> autoexec.cfg file.
>
> Below is an example of my autoexec.cfg file. The first two lines of code
> prevent the startup introduction from playing. The last line executes my
> script.
> alias d1 ""
> toggleconsole
>
> exec jf_q2cfg.cfg
> 6.2.3. The Format
>
> I would now like to describe a format which I use for making script
> files. This is just a recommendation from me and is in no way related to
> how Quake 2 will feel about your script. These are only things which I
> do to keep my script organized.
>
> Your script should have a heading which would idenfity it as a Quake 2
> script. The reason for having a heading is if somebody stumbles on your
> script file he will know exactly what that file does. Below is the
> heading which I have in my script file.
> // JakFrost's Quake 2 Configuration Script
> // =======================================
> // Copyright 1998 JakFrost, All Rights Reserved.
>
> Next, your script should have some information about it, like its
> author, how to contact the author, its version or release, and the last
> date of its update. It is important to state such things in a file so
> that it's easy to find out who the script belongs to and who the
> rightful author is. You might want to a create comment inside the script
> file which would specify all of that information or just create a small
> section in your alias with a couple of echo commands which would display
> that information on the Quake 2 console whenever the game starts up.
>
> Below is the section of my script file which displays the information
> for my script to the Quake 2 console upon startup.
> echo
> echo ------- Configuration Script -------
> echo Version: Release 4
> echo Date: February 20, 1998
> echo Author: JakFrost
> echo ------------------------------------
> echo
>
> The example shown below would be if I wanted to include a heading in the
> script file which would not be displayed on the Quake 2 console. This is
> for the people who do not want to clutter up the console when the game
> starts up but still want the information about the script displayed.
> This information should appear directly under the heading for the script
> file.
> // JakFrost's Quake 2 Configuration Script
> // =======================================
> // Copyright 1998 JakFrost, All Rights Reserved.
> //
> // Version: Release 4
> // Date: February 20, 1998
>
> Also each script should have an ending marker. This is totally not
> necessary for the script or for Quake 2 but I include it in my script
> files. The reason why I include this is that Quake and Quake 2 suffer
> from a couple of bugs, one of which involves commands which appear at
> the very end of a script. If a command appears on the last line of the
> script it will not be executed when the script is executed by Quake 2.
> If you put a comment on the last line of your script you will be able to
> avoid this bug.
>
> Below is an example of the ending marker that I use for my script files.
> The acronym EOF stands for end-of-file.
> // EOF
> 6.3. The Inside
> 6.3.1. Bindings
>
> I think that bindings are the most important part of a script file.
> After all, bindings are what set up your controls for playing. The
> reason that you should include your bindings in your script file is that
> you can avoid the ever changing structure of the config.cfg file which
> is changed every time that Quake 2 starts. Settings bindings in a script
> also allow you to make the script more modular, enabling for the
> distribution of the script without having to distribute the config.cfg 
> file.
>
> The one thing that you should put in a script before you put in any
> bindings is the unbindall command which will clear all the bindings that
> Quake 2 has. This is very important because some phantom bindings are
> saved in the config.cfg file which could come back later to haunt you
> and screw up your setup. You have to remember that you will have to redo
> all of the bindings after you use the unbindall command.
>
> When you put your bindings into your script file, it is a good idea to
> organize the bindings in groups. Later on you will find that it's easier
> to change bindings if they are grouped instead of having all of them in
> an alphabetical list. It would be a good idea to group bindings by the
> functions that they carry out. For example you could separate some
> bindings and make them into the "Movement Keys" group, or take all of
> the number key bindings and make a group called "Weapon Keys". This is
> not necessary but it's just for being neat.
>
> Below is the bindings section from my script. Look over this list and
> notice the groupings of bindings by their functions. Also if you are
> interested you will be able to learn the keys that I use to play. This
> is just an example to show you what I mean in the paragraphs above.
> // Bindings
> // --------
>
> unbindall
>
> // Special Keys
> bind escape togglemenu
> bind pause pause
> bind ` toggleconsole
> bind - sizedown
> bind = sizeup
> bind tab "cmd help"
>
> // Function Keys
> bind f1 "cmd help"
> bind f2 menu_savegame
> bind f3 menu_loadgame
> bind f4 menu_keys
> bind f5 menu_startserver
> bind f6 "save quick"
> bind f7 menu_playerconfig
> bind f8 menu_addressbook
> bind f9 "load quick"
> bind f10 menu_quit
> bind f11 menu_credits
> bind f12 screenshot
>
> // Weapon Keys
> bind 1 "use blaster"
> bind 2 "use shotgun"
> bind 3 "use super shotgun"
> bind 4 "use machinegun"
> bind 5 "use chaingun"
> bind 6 "use grenade launcher"
> bind 7 "use rocket launcher"
> bind 8 "use hyperblaster"
> bind 9 "use railgun"
> bind 0 "use bfg10k"
>
> // Movement Keys
> bind e +forward
> bind s +moveleft
> bind d +back
> bind f +moveright
> bind alt +movedown
> bind space +moveup
>
> // Quick Keys
> bind q "use rocket launcher"
> bind w "use hyperblaster"
> bind r "use railgun"
> bind t "use bfg10k"
> bind a qw
> bind g +rj
> bind z "use power shield"
> bind x "use grenades"
> bind v "use invulnerability"
> bind b "use quad damage"
> bind shift +sz
> bind ctrl +speed
>
> // Option Keys
> bind y "use environment suit"
> bind u "use rebreather"
> bind i "use silencer"
>
> // Inventory Keys
> bind [ invprev
> bind ] invnext
> bind \ inven
> bind ' invdrop
> bind enter invuse
>
> // Wave Keys
> bind h "wave 0"
> bind j "wave 1"
> bind k "wave 2"
> bind l "wave 3"
> bind semicolon "wave 4"
>
> // Message Keys
> bind n messagemode
> bind m messagemode2
>
> // Mouse Buttons
> bind mouse1 +attack
> bind mouse3 +grapple
> 6.3.2. Aliases
>
> It is a good idea to place all of your favorite aliases in the script
> file. That's what a script file was designed to do. Your script is the
> only place to actually keep aliases since you can't put them inside the
> config.cfg file since they will be deleted by Quake 2.
>
> Before you start putting in all of your little aliases, I think that it
> would be a good idea to give names to those aliases in case other people
> like those aliases and use them. I personally name all of the aliases
> that I use which serve specific functions.
>
> There is one thing that I would like to mention about aliases. Most of
> the time people take aliases posted on the Internet which were made by
> other people. I think that those people deserve respect and recognition
> for the work that they did. I feel that it would be a good idea to
> include some information about the original author of an alias right on
> top of that alias and below its name. If the author information is
> included in an alias and somebody decides to take that alias out of your
> script and use it in their script, they could just cut and paste the
> alias and information which would save them time.
>
> Below are all of the aliases from my script file. Notice that all of the
> aliases have names to them and include information about the author.
> // Aliases
> // -------
>
> // Quick Grapple Quake 2 Alias
> alias +grapple "use grapple;+attack;echo Quick Grapple"
> alias -grapple "-attack"
>
> // Quick Weapon Quake 2 Alias - Best Weapon Version
> // Author: Craig "Vermin" Morris (cmorris@aol.com)
> alias qw "msg 3;qw1;qw2;msg 1;echo Quick Weapon"
> alias qw1 "wait;use grenades;wait;use shotgun;wait;use super
> shotgun;wait;use grenade launcher;wait;use machinegun;"
> alias qw2 "wait;use chaingun;wait;use railgun;wait;use rocket
> launcher;wait;use hyperblaster;wait;use bfg10k;"
>
> // Rocket Jump Quake 2 Alias - Custom Version
> alias +rj "rj1;rj2"
> alias rj1 "set cl_pitchspeed- $cl_pitchspeed;cl_pitchspeed
> 100000;wait;+lookdown;wait;-lookdown;set cl_pitchspeed $cl_pitchspeed-"
> alias rj2 "set hand- $hand;hand 2;+moveup;+attack;echo Rocket Jump"
> alias -rj "-attack;-moveup;set hand $hand-;centerview"
>
> // Sniper Zoom Quake 2 Alias - Inverted Mouse Version
> alias +sz "set fov- $fov;fov 20;m_pitch -0.004;m_yaw 0.004"
> alias -sz "set fov $fov-;m_pitch -0.022;m_yaw 0.022"
> 6.3.3. Settings
>
> You should also include a section where you keep a couple of your
> settings for your configuration. It is a good idea to place things such
> as the player's name here, the skin that he uses, and a couple of other
> settings. This section is just for things that you use to help you with
> your bindings and aliases.
>
> Below is the settings section from my script. Notice there are a lot of
> personal settings there. There are also a couple of settings for my
> keyboard and my movement.
> // Settings
> // --------
>
> // Personal
> set hostname "JakFrost's Fridge"
> set msg 1
> set name JakFrost
> set skin male/howitzer
>
> // Other
> set cl_run 1
> set crosshair 3
> set freelook 1
> set hand 0
> set lookspring 0
> set lookstrafe 0
> set m_filter 0
> set m_pitch -0.022
> set skill 2
> 6.3.4. Documentation
>
> If you are planning to release your script on the Internet, it would be
> a good idea to write something about your script file. It is usually a
> good idea to give some background information about the script such as
> the author information, the version information, and the date of the
> last update. You should also mention a couple things about the bindings
> in the script and maybe explain the aliases that you used. I would
> recommend that you write something about your script that would enable
> other people to know what's going on.
>
> Also, if you are planning to release your script on the Internet it
> would be a good idea to release it with the script file and the
> documentation file inside a compressed archive file, usually a .zip
> file. I would recommend that you would name your documentation file with
> the same file name as your script file except that the extension to that
> documentation should be .txt. So if my script filename is jf_q2cfg.cfg
> the filename of the documentation file would be jf_q2cfg.txt. I would
> also recommend that the filename of the compressed archive be the same
> as that of your script and documentation. My script file is usually
> released on the Internet with the filename of jf_q2cfg.zip.
>
> If you plan to include documentation with your script, I suggest you
> make it a regular text file. If the script is written in plain text I
> think that the documentation file should be too. Please, avoid releasing
> your file in any other format since not everybody can read Word
> documents or Rich Text Files.
> 7. Afterword
>
> If you are reading this part I guess that you didn't fall asleep yet. By
> now if you understood everything mentioned above you should have a
> pretty clear picture of how the console works and what you can do with
> it. Make sure that you take a look at that Quake 2 Console Commands
> document that I mentioned to get all the information about all of those
> Quake 2 commands and variables which have been used throughout this
> document. You should also know a little about my script and the setup
> that I use to play.
>
> If you are interested in obtaining my script and other scripts for Quake
> 2 please visit Walnut Creek (ftp.cdrom.com) by using the link
> ftp://ftp.cdrom.com/pub/quake2/console/.
>
> If you found any problems with this document such as spelling, grammar,
> or technical errors please contact me so I could fix them. Also, I would
> like to mention that even though I wrote this alias to help others learn
> about the console I am not a personal tutor. Please do not send me email
> asking me to help you with console problems because I will not answer
> such email.
> 8. Version Information
> May 18, 2000
> Updated the legal and licensing terms of this document and it is now
> released under the Free Software Foundation's GNU Free Documentation
> License, Version 1.1.
> Removed the links to the Cascading Style Sheet file which was providing
> the stylistic markup for this document in order to solve an existing
> major problem with troublesome web serving software and to promote
> better accessibility and availability of this document for the future at
> the price of removing the coloring and formatting markup from this 
> document.
> Changed the format of my email address from URL format to a proprietary
> format in order to defeat the automatic gathering of my email address by
> web crawler software and to prevent the increasingly annoying barrage of
> unsolicited commercial advertisements that I have been receiving.
> Removed all other HTML LINK tags to prevent future problems with web
> serving software.
> Renamed the Index section to Table Of Contents to correct this long
> lasting mistake.
> November 6, 1998
> New legal terms for this document. It is now released under the Free
> Software Foundation's GNU General Public License Version 2.
> Changed the definition list formatting in sections 1.2. Document
> Conventions and 1.3. Definitions from bold to italic.
> September 29, 1998
> Updated the HTML markup in the document. This should be the last such
> update because I think I solved all of the previous problems with HTML
> and the correct display of this document.
> Updated the HTML 4.0 deceleration to include the URI of the DTD, as
> stated in the standard.
> Added the MIME Content-Type and Content-Language fields to explicitly
> set the character set encoding and language information.
> Added HTML meta information to each document to include all necessary
> header information to help search engines.
> Changed the Modified: field to Last Modified:, and Location: to Source:
> to avoid ambiguity.
> Changed the usage of bold and italic stylistic markup in order to
> facilitate better display of this document in browsers which do not
> support Cascading Style Sheets.
> July 20, 1998
> I have removed my email address from this document because I was getting
> unwanted emails. If you want to contact me, go to my web site.
> July 16, 1998
> Changed the internal HTML style for indentations and also to space out
> the fields for easier reading.
> Added subsection 9.4. Trademarks in the 9. Legal section to take care of
> any trademark legalities.
> Added a copyright notice to the Abstract section along with a short
> description about this document.
> March 13, 1998
> Made some formatting changes.
> March 1, 1998
> Fixed a lot of spelling and grammatical errors thank to the careful eye
> of David "Veritas" Luntz. Without readers like him, my bad grammar and
> spelling would be free to roam the 'net unchecked. I extend my greatest
> thanks to David for his proofreading. :)
> February 24, 1998
> Changed the description of "Double-Backslash" to "Double-Slash" thanks
> to Martin Kuhne for noticing this huge blunder. I'm surprised that I
> didn't catch this error a very long time ago when I was writing the
> Quake Console Tutorial.
> Switched the sections 2.3.2 and 2.3.3 around because of the above
> mentioned change to keep the sections in alphabetical order.
> February 22, 1998
> Added the dollar sign special character which reappeared in the Quake 2
> v3.12 code to the console syntax section.
> Added my email address to the Abstract section. It was been removed long
> time ago because of too many emails, and I hope that this isn't the case
> this time.
> Updated the outdated comments in the alias displayed in section 2.3.2.
> Changed all of the Quick Hook aliases to Quick Grapple because of the
> new Quake 2 CTF release.
> Updated the example of my script file to my current settings.
> Added a sentence to each of the special console characters to show what
> they look like.
> Substituted the old Rocket Jump and Sniper Zoom aliases for newer
> versions of those aliases which use the dollar sign special character
> for storing variable values.
> Moved the Abstract section to the top of the document above the Table Of
> Contents.
> February 5, 1998
> Fixed a few grammatical errors in the document, thanks to Clambake.
> February 2, 1998
> Added the Legal sections to allow free distribution of this tutorial.
> Added the Location: field in the Abstract so people can find the
> original location of this document.
> February 1, 1998
> Fixed two spelling errors thanks to KingWolf.
> January 23, 1998
> Original release.
> 9. Legal
> 9.1. Copyright
>
> This work is copyrighted pseudonymously by the author under all
> applicable laws. The author reserves all rights to this work. The
> copyright statement for this work is "Copyright (C) 1998-2000 JakFrost,
> All Rights Reserved".
> 9.2. License
>
> Permission is granted to copy, distribute and/or modify this document
> under the terms of the GNU Free Documentation License, Version 1.1 or
> any later version published by the Free Software Foundation; with no
> Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. You
> can access the license at http://www.gnu.org/copyleft/fdl.html or you
> can write to the Free Software Foundation, Inc., 59 Temple Place, Suite
> 330, Boston, MA 02111-1307, USA to request a copy. Please preserve all
> authorship and contact information when distributing or modifying this
> work. All derivative works or works containing parts of this work must
> be released under the same license or a later version of it.
> 9.3. Trademarks and Servicemarks
>
> All trademarks and servicemarks used in this work are acknowledged and
> are the property of their rightful owners.
> 9.4. Warranty Disclaimer
>
> THIS WORK IS PROVIDED "AS IS" WITHOUT ANY WARRANTY; WITHOUT EVEN THE
> IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> THE AUTHOR IS NOT LIABLE FOR ANY RESULTS ARRISING FROM THE USE OF THIS
> WORK. ALL RISKS AND RESULTS THEREOF FALL ON THE USER.
>
> Copyright (C) 1998-2000 JakFrost, All Rights Reserved
>
>
> --------------------------------------------------------------------------