This document contains descriptions of the new Cvars and console commands that have been added to the game Q3MIN.
This Cvar (default value is the empty string "") defines a custom color to be used for the crosshair. Set it so that it contains the RGB components of the desired crosshair color:
set cg_crosshairColor "R G B"
where R, G and B must be floating point numbers in the range 0.0 to 1.0 (inclusive). Please note that in case if the Cvar 'cg_crosshairHealth' is non-zero, then setting a custom color for the crosshair is disabled (for obvious reasons).
100 -> hour:min:sec (12-hour format) 101 -> hour:min:sec (24-hour format) 102 -> month:day:year 103 -> month:day:year + hour:min:sec (12-hour format) 104 -> month:day:year + hour:min:sec (24-hour format) 105 -> day:month:year 106 -> day:month:year + hour:min:sec (12-hour format) 107 -> day:month:year + hour:min:sec (24-hour format) 108 -> year:month:day 109 -> year:month:day + hour:min:sec (12-hour format) 110 -> year:month:day + hour:min:sec (24-hour format)
Default value is zero. If you set this Cvar to non-zero, then your current speed of movement (in game units per second) is displayed in the upper right corner of the screen.
Default value is the empty string "". If the Cvar is not empty, then its content is used to replace 'You fragged..." in the message displayed when you kill someone.
These Cvars control weapon grouping and ranking. The order of weapons (i.e. their 'rank') is controlled by 'cg_weaponRank' (default value is the empty string ""). The default means that the order (ranking) of weapons is the same as in the original game. You may specify a different weapon order by setting this Cvar as follows:
set cg_weaponRank "w1 w2 w3 w4 w5 w6 w7 w8 w9"
where w1, w2, etc. are weapon ID strings from the following sets:
ga mg sg gl rl lg rg pg bf GA MG SG GL RL LG RG PG BF
There must be exactly nine weapon IDs, one for each weapon. The order of weapons in the game will follow the order in which they appear in the Cvar's string.
The standard weapons available in the game (from gauntlet to BFG) are now divided into weapon groups. There are four groups and there may be up to four weapons in each group. The default grouping is as follows:
Group 1: LG PG SG close quarter fighting Group 2: RG MG LG middle to long range, instant hit Group 3: BF RL GL explosive projectiles, self-damage Group 4: GA best left alone :)
Four additional Cvars are provided for overriding the default definitions of weapon groups:
cg_weaponGroup1 cg_weaponGroup2 cg_weaponGroup3 cg_weaponGroup4
The default value for these Cvars is the empty string "". You may set any of them in the same way as 'cg_weaponRank' above. For example:
set cg_weaponGroup2 "RL LG SG"
This will redefine weapon group 2 to have the rocket launcher, the lighntning gun and the shotgun. You may add up to four weapons to each group, but no group may contain the same weapon twice. Weapons in the groups should be specified in a descending order (most powerful listed first, this is the order of selection within the group). If you set the Cvar to "" then the corresponding weapon group becomes undefined (empty).
The command 'weapon N' has been extended to take advantage of weapon grouping. It accepts arguments in the range 101 to 104. These numbers correspond to the four weapon groups. Passing the number of a weapon group (+ 100) results in the following actions depending on which weapon you currently use:
If the ammo of your current weapon runs out, the game tries to select the best available weapon from the same group. If that is not possible, then the best available weapon from the full set is selected.
The working of the commands 'weapnext' and 'weapprev' can also be changed by setting the new Cvar 'cg_newWeaponSelect' to non-zero (default is zero). Zero means that weapon selection works in the same way as in the original Q3A game. A non-zero value causes weapon selection to be changed: the commands do not wrap around (they stop at the respective end of the weapon list) and the gauntlet can also be selected.
Default value is zero. If you set this cvar to non-zero, UT-style smooth zooming is enabled. In this case the old zooming commands are disabled and the following new commands become available:
togglezoom toggle between zoomed and normal views +zoomin increase zoom factor while zoomed +zoomout decrease zoom factor while zoomed
The zoom mechanism retains the last set zoom factor between zoom activations. A new telescope-like crosshair is used with the new zooming scheme.
Default value is zero. If you set this Cvar to non-zero, the annoying up/down bobbing of items is stopped.
Default value is zero. If you set this Cvar to non-zero, the various medal icons (excellent, impressive, etc.) are not displayed over the models' head.
These Cvars are all part of the PM skin system (originally developed for the CPMA mod). The use of PM skins is controlled by the Cvar 'cg_forceModel' (default value zero, i.e. PM skins are not used).
The PM skin system allows you to set specific player models and colors (head, body and legs) for your opponents and teammates. This feature helps in eliminating some of the unfair advantages of using certain models/colors that blend into the background or that have hit boxes of non-standard size or shape (e.g. the model Orbb in the original Q3A game).
If 'cg_forceModel' is set to non-zero, then the four Cvars discussed in this section become active (used). Their purpose and usage is described below.
cg_enemyModelThe values of these Cvars specify the names of the models that should be used for opponents and (in case of team games) for members of your team when the PM skin system is enabled. The format of specification is the following:
set cg_enemyModel "[model-name]" set cg_teamModel "[model-name]"
where [model-name] is the name of one of the installed player models (i.e. Beret, Crakho, Major, Sarge, Skelebot or Tony). Model names are case insensitive.
Note: Model name specification is not compatible with the original PM skin system of CPMA (i.e. the format 'modelname/pm' is not recognized as valid). I don't think that this is a serious problem. When old config settings are used, the values of these Cvars must be adjusted anyway because Q3MIN does not have the player models used by Q3A and CPMA. If any old-style model specification is found, it is ignored and the appropriate default value is used.
The default values of model Cvars are the following:
cg_enemyModel "Sarge" cg_teamModel "Beret"cg_enemyColors
These Cvars specify the color values to use for the head, torso and leg parts of the enemy and of team members (in team games), respectively. The format is like this:
set cg_enemyColors "head-color torso-color leg-color" set cg_teamColors "head-color torso-color leg-color"
where 'head-color', etc. must be decimal numbers between 0 and 32 (inclusive).
You may chose from a set of 32 distinct colors. There are eight predefined shades of each red, green, blue and yellow colors. Color indexes are grouped as follows:
1 to 8 shades of red 9 to 16 shades of green 17 to 24 shades of blue 25 to 32 shades of yellow
The intensity of color in each group is increasing with increasing index values. However, you cannot set full bright colors (i.e. RGB values of 255). The colors at the lowest indexes are still clearly visible, and those at the highest indexes are fairly bright.
The color index zero specifies a normal pale yellow skin color intended to be used for the head parts of the models (the models look a bit more natural if this head color is used).
Note: Setting normal head color for the model 'crakho' does not work. I have no idea why. If you have a friend who has experience with MD3 models, you might ask him to have a look at the stuff. ;)
CPMA-style color definition strings (format 'NNN' or 'NNNN') are also accepted in order to maintain compatibility and allow the usage ('dropping in') of previously used config settings. Colors are defined using the following format:
set enemyColors "RHBL" set teamColors "RHBL"
or
set enemyColors "HBL" set teamColors "HBL"
where 'R', 'H', 'B' and 'L' must be single decimal digits in the range '0' to '7'. The colors specified by these digits are:
0 black 1 red 2 green 3 yellow 4 blue 5 cyan 6 magenta 7 white
Note: The reason for including this feature is that many people are lazy and reuse old config settings, instead of properly setting up their configuration files for a new game or mod. Argh...
The default values of color Cvars are the following:
cg_enemyColors "0 32 32" (head normal, body & legs bright yellow) cg_teamColors "0 8 8" (head normal, body & legs bright red)
The scoreboard and status line drawing code has also been modified. If the PM skin system is enabled, then player icons are shown in a rectangle that has the same color as the body part of the player model.
If you switch to spectator mode, the colors are modified (because it is not possible to tell any more who is your enemy and who is your teammate). In FFA the models are displayed using the default enemy color, while in team games the normal red and blue colors are used. When you rejoin the game the colors defined in the Cvars 'cg_pmEnemyColors' and 'cg_pmTeamColors' are restored.
Default value is zero. Unless it is set to a non-zero value, a lot of junk messages (mostly from the SDL module) are suppressed. Log file size shrinks to one-third, it is much easier to find important messages (those are not suppressed of course).
Default value is zero. If you set this Cvar to non-zero, the game will use user specific folders in the 'Documents and Settings" system directory for storing config files and other stuff. Otherwise the install directory of the game is used (old behavior, before XP). The Cvar should be set on the command line to have the desired effect. This works only under Windows XP. Under Linux file system use is the same as in the original game regardless of the value of this Cvar.
Default value is zero. If this Cvar is set to non-zero, your weapon change will become (almost) instantaneous (actually about 10-15 ms). The default value results in the original 300-400 ms change time. This is a server side Cvar (type SYSTEMINFO): this means that when you connect to a remote server then the server's setting will determine whether fast weapon switching is enabled or not.
Please note that for technical reasons in some situations (notably when the current weapon was just fired) the change takes a bit more time. For example, when you fire the railgun or the rocket launcher and immediately change the weapon, the switch does not occur until the previous weapon becomes ready. This has probably something to do with weapon & torso animation. May do an effort to fix this later if it is considered a serious problem.
The default value for 'sv_instagib' is zero. If this Cvar is set to non-zero, the following game play rules are added:
To add some flexibility, the fire rate (delay between shots) can be controlled by setting the Cvar 'sv_instaFireDelay' to any value in the range 500 to 1500 (these are milliseconds, so it comes to 0.5 to 1.5 seconds). The value is checked and forced into this range if necessary. The default value is 1500 (same as in the original game).
Note: Bots are rather lame in instagib unless you set their skill to 5. Then they give a decent fight.
The default value for 'sv_mapRotate' is the empty string "". If you set this Cvar to the name of the CFG file that specifies the maps (see below) then after startup the server will load the first map specified and then it will rotate them using the order in which they have been specified.
It is possible to specify a random order of rotation by setting the Cvar 'sv_mapRotateRandom' to non-zero (default value is zero). In this case the server will select the maps in a random order , but it is guaranteed that the same nap will not be selected twice in a row.
The maps to be rotated should be specified in an ASCII text file (DON'T USE MS Word for making it!). The format of the file is the following:
# Lines starting with '#' and empty lines are ignored. # Next is a map definition line: [mapname] [gametype] [fraglimit] [timelimit] [minplayers] [maxplayers] [botskill] ... ... [up to 32 map definition lines] ...
Explanation of terms used:
[mapname] = name of the map (w/o '.bsp') [gametype] = game mode (ffa team ctf insta-ffa insta-team insta-ctf) [fraglimit] [timelimit] = same as the corresponding Cvars [minplayers] [maxplayers] = minimum and maximum number of players [botskill] = skill of bots if they have to be added
You may use spaces or TAB(s) as separators between the elements. In the normal case every parameter is specified for each map int the file. It is allowed, however, to omit some or all parameters. In this case the server will supply the following default values:
gametype = ffa fraglimit = 15 timelimit = 15 minplayers = 2 maxplayers = 6 botskill = 3 (except for instagib where it is 5)
There is one limitation: if you do want to specify a parameter explicitly, then all the previous parameters must also be present (no holes in the list). In the simplest case the map definition line consists of a single map name and all parameters have default values.
Notes:
Desired player counts (minimum or maximum) may not exceed the current value of
'sv_maxclients'. And of course 'minplayers' must not be larger than 'maxplayers'
(it's OK if they are equal).
For team games (TDM and CTF) the minimum and maximum player counts should be even. If
you specify an odd value, the server prints a warning and adjusts the value (increments
it by one to make it even). Minimum and maximum team sizes will be half of the minimum
and maximum player counts, respectively.
The 'maxplayer' parameter is just a hint. It may not be possible to maintain it
in some cases. For example, if the current map allows six players and there are
actually six human players on the map, the server is not allowed to kick a human
client even if the 'maxplayer' setting of the next map is lower.
If 'maxplayer' human players are already on the map, then the server will not
allow another player to connect even if the value of 'sv_maxclients' would allow
another player.
When map rotation is active, voting is disabled because it could interfere with
the correct functioning of the map rotation system.
When map rotation is active, the server manages the actual number of clients connected according to the 'minplayers' and 'maxplayers' parameters specified for the currently used map. The number of clients is checked at one second intervals and adjustments are performed if necessary. The following sections describe the rules (algorithm) used for client management in FFA and team games.
In the case of FFA games no client management is done if 'minplayers' is set to zero (because in this case only human clients will play and we let them manage client count). The maximum number of allowed clients is still controlled by the value of 'maxplayers'. If 'minplayers' is non-zero, then the server adds bot(s) if there are less then 'minplayers' clients, and removes bot(s) if there are more then 'maxplayers' clients (if possible).
In the case of team games (TDM and CTF) the following algorithm is used:
# Test map rotation file aggressor ffa 12 10 2 4 4 hyperblast-q3 team 15 0 4 6 3 rpg3dm2 insta-ffa ztn3dm1 insta-team 20 15 4 8 2
This Cvar controls whether spawn protection is enabled (non-zero) or disabled (zero, default value). This is a server side Cvar which means that when you connect to a server the status of spawn protection (enabled or disabled) is controlled by the Cvar setting of the server.
When spawn protection is enabled, you (re)spawn into the game invulnerable to damage inflicted by other players (gunfire). This invulnerability period lasts for 5 seconds, after that you become vulnerable. You are not invulnerable to other types of damages (e.g. falling damage, lava, slime).
During the invulnerability period your weapons are inhibited, that is you cannot fire. You can switch to another weapon if you pick up one, but the switch is actually performed only after the protected period is over. The crosshair displayed during this period is the universal 'do not enter' traffic sign (horizontal white bar in a red circle). When the protected period is over, the crosshair you selected in your config file is displayed.
You can detect when other players have just been spawned and are invulnerable, because the 'spawn protected' icon (a crossed out target sign) is displayed over their heads as long as the protected period lasts.