Mod Wiki - User contributions [en-gb]

Enemy Territory: QUAKE Wars Competition Mod Guide

2008-02-05T15:04:35Z

192.168.0.152: /* Auto Demo Recording and Screenshots */

The Enemy Territory: QUAKE Wars Competition Mod allows tournament organizers to easily implement and enforce specific rule-sets and enhances other competition related features of the game, such as ETQW:TV. It does this by providing additional Cvars and commands to both the players and server admins.

This is a brief guide explaining some of those Cvars and commands and providing examples where necessary.

==Weapon and Upgrade Unlocks==

Some weapons and proficiency upgrades can be unlocked for all players from the match start in Competition Mod, despite proficiency being turned off. Setting the following Cvars to 1 will unlock these weapons and upgrades.

{{consolecmd|g_unlockGrenadeLauncher}} – unlocks the Grenade/Plasma Launcher for the Engineer/Constructor 
{{consolecmd|g_unlockScopedRifle}} – unlocks the Scoped Assault Rifle/Accurised Lacerator for the Field Ops/Oppressor 
{{consolecmd|g_unlockExtraClip}} – unlocks extra ammo for all player classes 
{{consolecmd|g_unlockFasterSprint}} – unlocks faster movement speed for all player classes 
{{consolecmd|g_unlockWeaponSpread}} – unlocks reduced weapon spread for all weapons

==Class, Weapon and Deployable Limits==

Competition Mod also allows admins to set restrictions on the number of classes and deployables available to a team, as well as limiting some weapon types. The value placed against any of the following Cvars is the maximum number of that game element allowed. A value of -1 makes means there is no limit.

===Class Limits===

{{consolecmd|g_maxSoldiers}} – sets the number of GDF Soldiers allowed 
{{consolecmd|g_maxMedics}} – sets the number of GDF Medics allowed 
{{consolecmd|g_maxEngineers}} – sets the number of GDF Engineers allowed 
{{consolecmd|g_maxFieldOps}} – sets the number of GDF Field Ops allowed 
{{consolecmd|g_maxCovertOps}} – sets the number of GDF Covert Ops allowed 
{{consolecmd|g_maxAggressors}} – sets the number of Strogg Aggressors allowed 
{{consolecmd|g_maxTechnicians}} – sets the number of Strogg Technicians allowed 
{{consolecmd|g_maxConstructors}} – sets the number of Strogg Constructors allowed 
{{consolecmd|g_maxOppressors}} – sets the number of Strogg Oppressors allowed 
{{consolecmd|g_maxInfiltrators}} – sets the number of Strogg Infiltrators allowed

===Weapon Limits===

{{consolecmd|g_maxGPMGs}} – sets the number of GPMGs/Hyperblasters allowed per team 
{{consolecmd|g_maxRocketLaunchers}} – sets the number of Rocket Launchers/Obliterators allowed per team 
{{consolecmd|g_maxSniperRifles}} – sets the number of Sniper Rifle/Railguns allowed per team 
{{consolecmd|g_maxHeavyWeapons}} – limits the total number of GPMGs/Hyperblasters and Rocket Launchers/Obliterators allowed per team 
{{consolecmd|g_maxGrenadeLaunchers}} – sets the number of Grenade/Plasma Launchers allowed per team

===Engineer/Constructor Turrets===

{{consolecmd|g_maxAITs}} – sets the number of Artillery Interceptor Turrets allowed per team 
{{consolecmd|g_maxAPTs}} – sets the number of Anti-Personnel Turrets allowed per team 
{{consolecmd|g_maxAVTs}} – sets the number of Anti-vehicle Turrets allowed per team

===Field Ops/Oppressor Artillery===

{{consolecmd|g_maxArtillery}} – sets the number of Artillery/Rail Howitzers allowed per team 
{{consolecmd|g_maxHammers}} – sets the number of Hammers/Dark Matter Cannons allowed per team 
{{consolecmd|g_maxRocketArtillery}} – sets the number of Rocket Artillery/Plasma Mortars allowed per team

===Covert Ops/Infiltrator Radar===

{{consolecmd|g_maxRadars}} – sets the number of Radars/Psi-Radars allowed per team

===Mines===

{{consolecmd|g_maxMines}} – sets the total number of mines a team is allowed to have deployed at any one time

===Example Server Config===

This is an example of a server config file limiting deployables, weapons, class, and mines:

<code><pre>
// **************************************************************
// ******* ********
// ******* Example class, dep and weapon limits config ********
// ******* ********
// **************************************************************

// Turret restrictions

set g_maxAITs 1 // Allows 1 Artillery Interceptor Turret per team
set g_maxAPTs 1 // Allows 1 Anti-Personnel Turret per team
set g_maxAVTs 1 // Allows 1 Anti-Vehicle Turret per team

// Artillery Restrictions

set g_maxArtillery 1 // Allows 1 Artillery or Rail Howitzer per team
set g_maxRocketArtillery 1 // Allows 1 Rocket Artillery or Plasma Mortar per team
set g_maxHammers 1 // Allows 1 Hammer or Dark Matter Cannon per team

// Weapon Restrictions

set g_maxRocketLaunchers 1 // Allows 1 Rocket Launcer or Obliterator per team
set g_maxGPMGs 2 // Allows 2 GPMGs or Hyperblasters per team
set g_maxGrenadeLaunchers -1 // Allows unlimited Grenade Launchers per team if the Grenade Launcher is available
set g_maxHeavyWeapons -1 // Set no limit to Heavy Weapons
set g_maxSniperRifles 1 // Allows 1 Sniper Rifle or Rail Gun per team

// Mine Limit

set g_maxMines 8 // Allows each team to only have a maximum 8 mines deployed at one time

// Radar Limit

set g_maxRadars 1 // Allows each team to deploy only 1 Radar at a time

// Strogg Class Limits

set g_maxAggressors 2 // Limits Strogg to 2 Aggressors at any one time
set g_maxTechnicians 2 // Limits Strogg to 2 Technicians at any one time
set g_maxConstructors 3 // Limits Strogg to 3 Constructors at any one time
set g_maxOppressors 2 // Limits Strogg to 2 Oppressors at any one time
set g_maxInfiltrators 2 // Limits Strogg to 2 Infiltrators at any one time

// GDF Class Limits

set g_maxSoldiers 2 // Limits GDF to 2 Soldiers at any one time
set g_maxMedics 2 // Limits GDF to 2 Medics at any one time
set g_maxEngineers 2 // Limits GDF to 2 Engineers at any one time
set g_maxFieldOps 4 // Limits GDF to 4 Field Ops at any one time
set g_maxCovertOps 1 // Limits GDF to 1 Covert Op at any one time
</pre></code>

==Pausing and Time Outs==

Further support has been added for pausing matches as well as a new Team Timeout feature. Any player on either team can call a time out at any time during a game (if allowed on the server), this will pause the game for a set amount of time before counting the game back in and restarting it. Related Cvars and Commands are listed below.

{{consolecmd|admin pause}} – Command to pause a game indefinitely 
{{consolecmd|admin unpause}} – Command to un-pause a game 
{{consolecmd|g_unpauseTimer}} – Sets the duration, in seconds, of the match restart countdown that plays after a pause or time out has ended 
{{consolecmd|g_maxTeamTimeouts}} – Determines how many timeouts a team can use per match, value of -1 turns timeouts off 
{{consolecmd|g_teamTimeoutLength}} – Sets the duration, in minutes, a timeout will last 
{{consolecmd|callTimeout}} – Command used to start a timeout, any player is able to call a time out

==Spectating and 'Spec Labels'==

With Competition Mod spectators are now able to view players in free fly mode with much greater control and feedback. Support is added for pre-set cameras, binding hot keys for viewing specific clients and for clicking on individual players to jump into their first person perspective. In addition labels can now be added to players when spectating, allowing much easier identification of individuals. These spec labels are customized via client side Cvars.

===Spectate Position===

This command allows the user to jump to a specific point on the map, looking in a pre-set direction, essentially jumping to user defined camera. The command is set in the following format:

{{consolecmd|Spectate Position <x> <y> <z> <yaw> <pitch> <roll>}}

Here X, Y and Z are the coordinates at which the camera will be placed, Yaw, Pitch and Roll set the direction in which it will be looking. The easiest way to obtain these values is to start ETQW, launch Play Computer, fly to the position at which you'd like the camera to be placed and then use the command 'getviewpos'. This will capture the coordinates for your current point of view to the clipboard and you can use these for your camera. You will need net_allowcheats to be set to 1 to be able to use the getviewpos command.

Obviously this is not very easy to do on the fly so it is best to make a series of binds for each map and then store them in a config file. An example of a bind for a ready made camera for the map Valley is:

{{consolecmd|bind k "spectate position 9044.66 -4553.08 1891.27 24.87 -334.34 0.00"}}

===Other spectate commands===

{{consolecmd|Spectate Client}} - Jumps to spectating a specific player based on the client number or the player name entered e.g. "Specate Client 1" or "Spectate Client Tapir" for a player called Tapir 
{{consolecmd|Spectate next}} – Jumps to the next player 
{{consolecmd|Spectate prev}} – Jumps to the previous player 
{{consolecmd|Spectate objective}} – Jumps to a player currently attempting to complete the objective or jumps to view a planted HE/Plasma charge (only works on Primary Objectives)

Pressing the use key ({{consolecmd|_activate}}) whilst a player is under the spectators crosshair will now jump to that players point of view, allowing for more fluid transitions between first person and free fly mode

===Example spectator config===

This is an example of a client config file set up to jump to specific clients, map locations, and objectives.

<code><pre>
// **********************************
// ******* ********
// ******* Specator Config ********
// ******* ********
// **********************************

// Number keys are bound to specific clients based on client number (ignores clients that are also spectating)

bind 1 "spectate client 1"
bind 2 "spectate client 2"
bind 3 "spectate client 3"
bind 4 "spectate client 4"
bind 5 "spectate client 5"
bind 6 "spectate client 6"
bind 7 "spectate client 7"
bind 8 "spectate client 8"
bind 9 "spectate client 9"
bind 0 "spectate client 10"
bind - "spectate client 11"
bind = "spectate client 12"

// Keys bound to specific clients based on the player's name

bind q "spectate client AO"
bind w "spectate client 'Bongo Boy'"
bind e "spectate client ducks"
bind r "spectate client Digibob"
bind t "spectate client RR2DO2"
bind y "spectate client Wils"
bind u "spectate client MoP"
bind i "spectate client Anti"
bind o "spectate client Smooth"
bind p "spectate client Jose"
bind [ "spectate client Huntle"
bind ] "spectate client JFK"

// Keys bound to toggle through clients

bind rightarrow "spectate next"
bind leftarrow "spectate prev"

// Pre-set cameras for Valley

bind kp_end "spectate position 9044.66 -4553.08 1891.27 24.87 -334.34 0.00" // Views obj. 1
bind kp_downarrow "spectate position 3862.32 1435.13 1879.86 131.09 -353.98 0.00" // Views Tunnel Spawn
bind kp_pgdn "spectate position 1085.68 8092.22 1955.78 274.70 -337.35 0.00" // Views obj. 2
bind kp_leftarrow "spectate position -6847.38 -4325.94 2230.2 244.78 -340.67 0.00" // Views obj. 3
bind kp_5 "spectate position -5549.77 -9793.78 1934.23 174.49 -330.27 0.00" // Views obj. 4

// Jumps to spectating any player currently achieving the objective

bind a "spectate objective"
</pre></code>

===Spec Labels===

Spec Labels are fully customizable name tags that hover next to players in-world when spectating them to aid a viewers understanding of who they are watching. They are also used to display the amount of time remaining on a planted HE/Plasma charge. The labels are controlled client side and are usable with ETQW:TV. The following Cvars are used for editing spec labels:

{{consolecmd|g_showPlayerNames}} – cvar used to toggle player spec labels on/off 
{{consolecmd|g_showChargeTimers}} – cvar used to toggle in-world HE/Plasma charge timers on/off 
{{consolecmd|g_specLabelAlpha}} – adjusts the alpha of the text on the spec label 
{{consolecmd|g_specLabelBackground}} – cvar used to toggle the label background on/off 
{{consolecmd|g_specLabelBackgroundColor}} – adjusts the background color of the label, format "<nowiki><R> <G> <Alpha></nowiki>" 
{{consolecmd|g_specLabelDropShadow}} – adds or removes drop shadow on the label text 
{{consolecmd|g_specLabelMaxDistance}} – adjusts the distance at which spec labels become visible 
{{consolecmd|g_specLabelPosition}} – adjusts where a label appears in relation to a player (0 = above, 1 = center, 2 = below) 
{{consolecmd|g_specLabelSize}} – adjusts the size of the label 
{{consolecmd|g_specLabelShowAll}} - cvar used to show labels even for players that are hidden (eg behind a wall) 
{{consolecmd|g_specLabelTeamColors}} - enables the names to be coloured based on the team 
{{consolecmd|g_specLabelGDFColor}} – adjusts the text color on GDF labels, format "<nowiki><R> <G> <Alpha></nowiki>" 
{{consolecmd|g_specLabelStroggColor}} – adjusts the text color on Strogg labels, format "<nowiki><R> <G> <Alpha></nowiki>" 
{{consolecmd|g_showFreeFlyText}} – cvar used to add/remove the 'free fly mode' text that appears in the center of the screen 

==Vampire/Violator Team Charge Bar==

Competition Mod makes it possible to have a shared charge bar on the Vampire/Violator for each team. When turned on this can be used to prevent teams from 'spamming' fire support at the same time or in quick succession.

{{consolecmd|g_teamAirstrikeCost}} - This cvar sets the percentage of the team's charge bar a single air strike will use, set to 100 a single Vampire strike would use the whole charge bar and it would have to fully re-fill before another Vampire could be used. Set to 50 a single Vampire being thrown would cause the charge bar to re-fill from half way, halving the time before another strike could be made. If the cvar is set to -1 then no shared team charge bar is set. 
{{consolecmd|g_teamAirstrikeRechargeTime}} – Sets the time in seconds it takes for the whole charge bar to re-fill

==Signed Configs==

Support is also available for checking configs between the client and the server, this allows players to ensure that the config that is being run on the server is the correct one. For example if the server is supposed to be running OfficialComp.cfg for a tournament players would be able to download it to their own machine and then check it against the server's version, comparing checksums to see if they are the same. The following commands are used to compare configs, in each case the name of the config to check is entered after the command.

{{consolecmd|getConfigChecksum}} - generates a checksum for a config stored on the client and prints it to the player requesting it 
{{consolecmd|getServerConfigChecksum}} - generates a checksum for a config stored on the server and prints it to the player requesting it 
{{consolecmd|admin configChecksum}} - generates a checksum for a config stored on the server and prints it to all players on the server 
{{consolecmd|compareConfigs}} - compares a config stored on the client with one on the server and tells the player if they match or not 
{{consolecmd|admin compareConfigs}} - compares a config stored on the client with one on the server and tells all players on the server if they match or not

==General Changes==

===Force Limbo Spectate===

These cvars allow server admins to prevent 'gibbed' players from viewing the battlefield from their corpse.

{{consolecmd|g_forceLimboSpectate}} – when set to 1 this forces gibbed players to spectate team mates until they re-spawn, or if all team mates are dead forces them to the limbo menu 
{{consolecmd|g_forceLimboSpectateMenuSticky}} – cvar sets if the limbo menu should automatically close if a player forced to the limbo menu re-spawns

===setSpawnPoint Commands===

Competition Mod provides a series of commands that allow players to select spawn points across the map without having to use the limbo menu. These commands can be bound to keys to allow very fast spawn point selection.

{{consolecmd|setSpawnPoint next}} – selects one spawn ahead of the player's current selection 
{{consolecmd|setSpawnPoint prev}} – selects one spawn back from the player's current selection 
{{consolecmd|setSpawnPoint default}} – selects the current front-line spawn point 
{{consolecmd|setSpawnPoint base}} – sets the player's spawn point to the main base (Command Center/Domination Hub)

===Auto Demo Recording and Screenshots===

It is possible for players to auto record their own demo files and generate screenshots of the end game scoreboard using Competition Mod. These files can also be given a customized naming format.

{{consolecmd|g_autoRecordDemos}} – set to 1 this cvar starts demo recording automatically when the match is started
{{consolecmd|g_autoScreenshot}} – set to 1 this cvar will automatically take a screenshot of the end game scoreboard

Auto recorded demos and auto screenshots can also have a user defined name format applied to them using the cvars {{consolecmd|g_autoDemoNameFormat}} and {{consolecmd|g_autoScreenshotNameFormat}}. These default to the following formats:

<code>scoreboard_$year$$month$$day$_$hour$$min$$sec$_$map$_$rules$_$name$_build_$srcrev$_$mediarev$.tga</code>

<code>$year$$month$$day$_$hour$$min$$sec$_$map$_$rules$_$name$_build_$srcrev$_$mediarev$.ndm</code>

These would result in the following file names respectively:

<code>scoreboard_20080205_103901_maps_sewer_competition_first_Player_build_12095_33034.tga</code>

<code>20080205_103617_sewer_competition_first_Player_build_12095_33034.ndm</code>

===Separate Vehicle Sensitivity Settings===

In Competition Mod it's possible to adjust mouse sensitivity for specific vehicles, allowing players to have high sensitivity in some vehicles with low sensitivity in others, all without effecting their sensitivity when playing as Infantry. The Cvars used to scale the sensitivity in the various vehicles are listed below. Each vehicle has two sensitivity cvars, one for vertical movement, one for horizontal. To adjust the general sensitivity then the value of both cvars should be the same.

{{consolecmd|m_bumblebeePitchScale}} – adjusts the vertical sensitivity in the Bumblebee 
{{consolecmd|m_bumblebeeYawScale}} – adjusts the horizontal sensitivity in the Bumblebee 
{{consolecmd|m_heavyVehiclePitchScale}} – adjusts the vertical sensitivity in the Titan, Cyclops and Desecrator 
{{consolecmd|m_heavyVehicleYawScale}} – adjusts the horizontal sensitivity in the Titan, Cyclops and Desecrator 
{{consolecmd|m_helicopterPitchScale}} – adjusts the vertical sensitivity in the Anansi and Tormentor 
{{consolecmd|m_helicopterYawScale}} – adjusts the horizontal sensitivity in the Anansi and Tormentor 
{{consolecmd|m_lightVehiclePitchScale}} – adjusts the vertical sensitivity in the Trojan, Armadillo, Hog and Husky 
{{consolecmd|m_lightVehicleYawScale}} – adjusts the horizontal sensitivity in the Trojan, Armadillo, Hog and Husky 
{{consolecmd|m_playerPitchScale}} – adjusts the vertical sensitivity as infantry and in the Icarus 
{{consolecmd|m_playerYawScale}} – adjusts the horizontal sensitivity as infantry and in the Icarus

Players are also able to switch yaw and roll between the keyboard and the mouse if they choose to using the cvar {{consolecmd|ui_swapFlightYawAndRoll}}. Setting this to a value of 1 causes the mouse to become the control for yaw and the keys to become the control for roll.

===Look at Killer/Medic===

Normally a dead players point of view will snap to look towards their killer or a nearby medic, this feedback is to help the user understand who just killed them or if they should tap out or not. With Competition Mod the player is now able to turn off this functionality if they choose to.

{{consolecmd|g_lookAtKiller}} – set this to a value of 0 to turn off the camera tracking a killer 
{{consolecmd|g_lookAtMedic}} – set this to a value of 0 to turn off the camera tracking nearby Medics/Technicians

Enemy Territory: QUAKE Wars Competition Mod Guide

2008-02-05T15:02:22Z

192.168.0.152: /* Spec Labels */

The Enemy Territory: QUAKE Wars Competition Mod allows tournament organizers to easily implement and enforce specific rule-sets and enhances other competition related features of the game, such as ETQW:TV. It does this by providing additional Cvars and commands to both the players and server admins.

This is a brief guide explaining some of those Cvars and commands and providing examples where necessary.

==Weapon and Upgrade Unlocks==

Some weapons and proficiency upgrades can be unlocked for all players from the match start in Competition Mod, despite proficiency being turned off. Setting the following Cvars to 1 will unlock these weapons and upgrades.

{{consolecmd|g_unlockGrenadeLauncher}} – unlocks the Grenade/Plasma Launcher for the Engineer/Constructor 
{{consolecmd|g_unlockScopedRifle}} – unlocks the Scoped Assault Rifle/Accurised Lacerator for the Field Ops/Oppressor 
{{consolecmd|g_unlockExtraClip}} – unlocks extra ammo for all player classes 
{{consolecmd|g_unlockFasterSprint}} – unlocks faster movement speed for all player classes 
{{consolecmd|g_unlockWeaponSpread}} – unlocks reduced weapon spread for all weapons

==Class, Weapon and Deployable Limits==

Competition Mod also allows admins to set restrictions on the number of classes and deployables available to a team, as well as limiting some weapon types. The value placed against any of the following Cvars is the maximum number of that game element allowed. A value of -1 makes means there is no limit.

===Class Limits===

{{consolecmd|g_maxSoldiers}} – sets the number of GDF Soldiers allowed 
{{consolecmd|g_maxMedics}} – sets the number of GDF Medics allowed 
{{consolecmd|g_maxEngineers}} – sets the number of GDF Engineers allowed 
{{consolecmd|g_maxFieldOps}} – sets the number of GDF Field Ops allowed 
{{consolecmd|g_maxCovertOps}} – sets the number of GDF Covert Ops allowed 
{{consolecmd|g_maxAggressors}} – sets the number of Strogg Aggressors allowed 
{{consolecmd|g_maxTechnicians}} – sets the number of Strogg Technicians allowed 
{{consolecmd|g_maxConstructors}} – sets the number of Strogg Constructors allowed 
{{consolecmd|g_maxOppressors}} – sets the number of Strogg Oppressors allowed 
{{consolecmd|g_maxInfiltrators}} – sets the number of Strogg Infiltrators allowed

===Weapon Limits===

{{consolecmd|g_maxGPMGs}} – sets the number of GPMGs/Hyperblasters allowed per team 
{{consolecmd|g_maxRocketLaunchers}} – sets the number of Rocket Launchers/Obliterators allowed per team 
{{consolecmd|g_maxSniperRifles}} – sets the number of Sniper Rifle/Railguns allowed per team 
{{consolecmd|g_maxHeavyWeapons}} – limits the total number of GPMGs/Hyperblasters and Rocket Launchers/Obliterators allowed per team 
{{consolecmd|g_maxGrenadeLaunchers}} – sets the number of Grenade/Plasma Launchers allowed per team

===Engineer/Constructor Turrets===

{{consolecmd|g_maxAITs}} – sets the number of Artillery Interceptor Turrets allowed per team 
{{consolecmd|g_maxAPTs}} – sets the number of Anti-Personnel Turrets allowed per team 
{{consolecmd|g_maxAVTs}} – sets the number of Anti-vehicle Turrets allowed per team

===Field Ops/Oppressor Artillery===

{{consolecmd|g_maxArtillery}} – sets the number of Artillery/Rail Howitzers allowed per team 
{{consolecmd|g_maxHammers}} – sets the number of Hammers/Dark Matter Cannons allowed per team 
{{consolecmd|g_maxRocketArtillery}} – sets the number of Rocket Artillery/Plasma Mortars allowed per team

===Covert Ops/Infiltrator Radar===

{{consolecmd|g_maxRadars}} – sets the number of Radars/Psi-Radars allowed per team

===Mines===

{{consolecmd|g_maxMines}} – sets the total number of mines a team is allowed to have deployed at any one time

===Example Server Config===

This is an example of a server config file limiting deployables, weapons, class, and mines:

<code><pre>
// **************************************************************
// ******* ********
// ******* Example class, dep and weapon limits config ********
// ******* ********
// **************************************************************

// Turret restrictions

set g_maxAITs 1 // Allows 1 Artillery Interceptor Turret per team
set g_maxAPTs 1 // Allows 1 Anti-Personnel Turret per team
set g_maxAVTs 1 // Allows 1 Anti-Vehicle Turret per team

// Artillery Restrictions

set g_maxArtillery 1 // Allows 1 Artillery or Rail Howitzer per team
set g_maxRocketArtillery 1 // Allows 1 Rocket Artillery or Plasma Mortar per team
set g_maxHammers 1 // Allows 1 Hammer or Dark Matter Cannon per team

// Weapon Restrictions

set g_maxRocketLaunchers 1 // Allows 1 Rocket Launcer or Obliterator per team
set g_maxGPMGs 2 // Allows 2 GPMGs or Hyperblasters per team
set g_maxGrenadeLaunchers -1 // Allows unlimited Grenade Launchers per team if the Grenade Launcher is available
set g_maxHeavyWeapons -1 // Set no limit to Heavy Weapons
set g_maxSniperRifles 1 // Allows 1 Sniper Rifle or Rail Gun per team

// Mine Limit

set g_maxMines 8 // Allows each team to only have a maximum 8 mines deployed at one time

// Radar Limit

set g_maxRadars 1 // Allows each team to deploy only 1 Radar at a time

// Strogg Class Limits

set g_maxAggressors 2 // Limits Strogg to 2 Aggressors at any one time
set g_maxTechnicians 2 // Limits Strogg to 2 Technicians at any one time
set g_maxConstructors 3 // Limits Strogg to 3 Constructors at any one time
set g_maxOppressors 2 // Limits Strogg to 2 Oppressors at any one time
set g_maxInfiltrators 2 // Limits Strogg to 2 Infiltrators at any one time

// GDF Class Limits

set g_maxSoldiers 2 // Limits GDF to 2 Soldiers at any one time
set g_maxMedics 2 // Limits GDF to 2 Medics at any one time
set g_maxEngineers 2 // Limits GDF to 2 Engineers at any one time
set g_maxFieldOps 4 // Limits GDF to 4 Field Ops at any one time
set g_maxCovertOps 1 // Limits GDF to 1 Covert Op at any one time
</pre></code>

==Pausing and Time Outs==

Further support has been added for pausing matches as well as a new Team Timeout feature. Any player on either team can call a time out at any time during a game (if allowed on the server), this will pause the game for a set amount of time before counting the game back in and restarting it. Related Cvars and Commands are listed below.

{{consolecmd|admin pause}} – Command to pause a game indefinitely 
{{consolecmd|admin unpause}} – Command to un-pause a game 
{{consolecmd|g_unpauseTimer}} – Sets the duration, in seconds, of the match restart countdown that plays after a pause or time out has ended 
{{consolecmd|g_maxTeamTimeouts}} – Determines how many timeouts a team can use per match, value of -1 turns timeouts off 
{{consolecmd|g_teamTimeoutLength}} – Sets the duration, in minutes, a timeout will last 
{{consolecmd|callTimeout}} – Command used to start a timeout, any player is able to call a time out

==Spectating and 'Spec Labels'==

With Competition Mod spectators are now able to view players in free fly mode with much greater control and feedback. Support is added for pre-set cameras, binding hot keys for viewing specific clients and for clicking on individual players to jump into their first person perspective. In addition labels can now be added to players when spectating, allowing much easier identification of individuals. These spec labels are customized via client side Cvars.

===Spectate Position===

This command allows the user to jump to a specific point on the map, looking in a pre-set direction, essentially jumping to user defined camera. The command is set in the following format:

{{consolecmd|Spectate Position <x> <y> <z> <yaw> <pitch> <roll>}}

Here X, Y and Z are the coordinates at which the camera will be placed, Yaw, Pitch and Roll set the direction in which it will be looking. The easiest way to obtain these values is to start ETQW, launch Play Computer, fly to the position at which you'd like the camera to be placed and then use the command 'getviewpos'. This will capture the coordinates for your current point of view to the clipboard and you can use these for your camera. You will need net_allowcheats to be set to 1 to be able to use the getviewpos command.

Obviously this is not very easy to do on the fly so it is best to make a series of binds for each map and then store them in a config file. An example of a bind for a ready made camera for the map Valley is:

{{consolecmd|bind k "spectate position 9044.66 -4553.08 1891.27 24.87 -334.34 0.00"}}

===Other spectate commands===

{{consolecmd|Spectate Client}} - Jumps to spectating a specific player based on the client number or the player name entered e.g. "Specate Client 1" or "Spectate Client Tapir" for a player called Tapir 
{{consolecmd|Spectate next}} – Jumps to the next player 
{{consolecmd|Spectate prev}} – Jumps to the previous player 
{{consolecmd|Spectate objective}} – Jumps to a player currently attempting to complete the objective or jumps to view a planted HE/Plasma charge (only works on Primary Objectives)

Pressing the use key ({{consolecmd|_activate}}) whilst a player is under the spectators crosshair will now jump to that players point of view, allowing for more fluid transitions between first person and free fly mode

===Example spectator config===

This is an example of a client config file set up to jump to specific clients, map locations, and objectives.

<code><pre>
// **********************************
// ******* ********
// ******* Specator Config ********
// ******* ********
// **********************************

// Number keys are bound to specific clients based on client number (ignores clients that are also spectating)

bind 1 "spectate client 1"
bind 2 "spectate client 2"
bind 3 "spectate client 3"
bind 4 "spectate client 4"
bind 5 "spectate client 5"
bind 6 "spectate client 6"
bind 7 "spectate client 7"
bind 8 "spectate client 8"
bind 9 "spectate client 9"
bind 0 "spectate client 10"
bind - "spectate client 11"
bind = "spectate client 12"

// Keys bound to specific clients based on the player's name

bind q "spectate client AO"
bind w "spectate client 'Bongo Boy'"
bind e "spectate client ducks"
bind r "spectate client Digibob"
bind t "spectate client RR2DO2"
bind y "spectate client Wils"
bind u "spectate client MoP"
bind i "spectate client Anti"
bind o "spectate client Smooth"
bind p "spectate client Jose"
bind [ "spectate client Huntle"
bind ] "spectate client JFK"

// Keys bound to toggle through clients

bind rightarrow "spectate next"
bind leftarrow "spectate prev"

// Pre-set cameras for Valley

bind kp_end "spectate position 9044.66 -4553.08 1891.27 24.87 -334.34 0.00" // Views obj. 1
bind kp_downarrow "spectate position 3862.32 1435.13 1879.86 131.09 -353.98 0.00" // Views Tunnel Spawn
bind kp_pgdn "spectate position 1085.68 8092.22 1955.78 274.70 -337.35 0.00" // Views obj. 2
bind kp_leftarrow "spectate position -6847.38 -4325.94 2230.2 244.78 -340.67 0.00" // Views obj. 3
bind kp_5 "spectate position -5549.77 -9793.78 1934.23 174.49 -330.27 0.00" // Views obj. 4

// Jumps to spectating any player currently achieving the objective

bind a "spectate objective"
</pre></code>

===Spec Labels===

Spec Labels are fully customizable name tags that hover next to players in-world when spectating them to aid a viewers understanding of who they are watching. They are also used to display the amount of time remaining on a planted HE/Plasma charge. The labels are controlled client side and are usable with ETQW:TV. The following Cvars are used for editing spec labels:

{{consolecmd|g_showPlayerNames}} – cvar used to toggle player spec labels on/off 
{{consolecmd|g_showChargeTimers}} – cvar used to toggle in-world HE/Plasma charge timers on/off 
{{consolecmd|g_specLabelAlpha}} – adjusts the alpha of the text on the spec label 
{{consolecmd|g_specLabelBackground}} – cvar used to toggle the label background on/off 
{{consolecmd|g_specLabelBackgroundColor}} – adjusts the background color of the label, format "<nowiki><R> <G> <Alpha></nowiki>" 
{{consolecmd|g_specLabelDropShadow}} – adds or removes drop shadow on the label text 
{{consolecmd|g_specLabelMaxDistance}} – adjusts the distance at which spec labels become visible 
{{consolecmd|g_specLabelPosition}} – adjusts where a label appears in relation to a player (0 = above, 1 = center, 2 = below) 
{{consolecmd|g_specLabelSize}} – adjusts the size of the label 
{{consolecmd|g_specLabelShowAll}} - cvar used to show labels even for players that are hidden (eg behind a wall) 
{{consolecmd|g_specLabelTeamColors}} - enables the names to be coloured based on the team 
{{consolecmd|g_specLabelGDFColor}} – adjusts the text color on GDF labels, format "<nowiki><R> <G> <Alpha></nowiki>" 
{{consolecmd|g_specLabelStroggColor}} – adjusts the text color on Strogg labels, format "<nowiki><R> <G> <Alpha></nowiki>" 
{{consolecmd|g_showFreeFlyText}} – cvar used to add/remove the 'free fly mode' text that appears in the center of the screen 

==Vampire/Violator Team Charge Bar==

Competition Mod makes it possible to have a shared charge bar on the Vampire/Violator for each team. When turned on this can be used to prevent teams from 'spamming' fire support at the same time or in quick succession.

{{consolecmd|g_teamAirstrikeCost}} - This cvar sets the percentage of the team's charge bar a single air strike will use, set to 100 a single Vampire strike would use the whole charge bar and it would have to fully re-fill before another Vampire could be used. Set to 50 a single Vampire being thrown would cause the charge bar to re-fill from half way, halving the time before another strike could be made. If the cvar is set to -1 then no shared team charge bar is set. 
{{consolecmd|g_teamAirstrikeRechargeTime}} – Sets the time in seconds it takes for the whole charge bar to re-fill

==Signed Configs==

Support is also available for checking configs between the client and the server, this allows players to ensure that the config that is being run on the server is the correct one. For example if the server is supposed to be running OfficialComp.cfg for a tournament players would be able to download it to their own machine and then check it against the server's version, comparing checksums to see if they are the same. The following commands are used to compare configs, in each case the name of the config to check is entered after the command.

{{consolecmd|getConfigChecksum}} - generates a checksum for a config stored on the client and prints it to the player requesting it 
{{consolecmd|getServerConfigChecksum}} - generates a checksum for a config stored on the server and prints it to the player requesting it 
{{consolecmd|admin configChecksum}} - generates a checksum for a config stored on the server and prints it to all players on the server 
{{consolecmd|compareConfigs}} - compares a config stored on the client with one on the server and tells the player if they match or not 
{{consolecmd|admin compareConfigs}} - compares a config stored on the client with one on the server and tells all players on the server if they match or not

==General Changes==

===Force Limbo Spectate===

These cvars allow server admins to prevent 'gibbed' players from viewing the battlefield from their corpse.

{{consolecmd|g_forceLimboSpectate}} – when set to 1 this forces gibbed players to spectate team mates until they re-spawn, or if all team mates are dead forces them to the limbo menu 
{{consolecmd|g_forceLimboSpectateMenuSticky}} – cvar sets if the limbo menu should automatically close if a player forced to the limbo menu re-spawns

===setSpawnPoint Commands===

Competition Mod provides a series of commands that allow players to select spawn points across the map without having to use the limbo menu. These commands can be bound to keys to allow very fast spawn point selection.

{{consolecmd|setSpawnPoint next}} – selects one spawn ahead of the player's current selection 
{{consolecmd|setSpawnPoint prev}} – selects one spawn back from the player's current selection 
{{consolecmd|setSpawnPoint default}} – selects the current front-line spawn point 
{{consolecmd|setSpawnPoint base}} – sets the player's spawn point to the main base (Command Center/Domination Hub)

===Auto Demo Recording and Screenshots===

It is possible for players to auto record their own demo files and generate screenshots of the end game scoreboard using Competition Mod. These files can also be given a customized naming format.

{{consolecmd|g_autoRecordDemos}} – set to 1 this cvar starts demo recording automatically when the match is started
{{consolecmd|g_autoScreenshot}} – set to 1 this cvar will automatically take a screenshot of the end game scoreboard

Auto recorded demos and auto screenshots can also have a user defined name format applied to them using the cvars {{consolecmd|g_autoDemoNameFormat}} and {{consolecmd|g_autoScreenshotNameFormat}}. These default to the following formats:

<code>scoreboard_$year$$month$$day$_$hour$$min$$sec$_$map$_$rules$_$name$_build_$srcrev$_$mediarev$.tga</code>

<code>$year$$month$$day$_$hour$$min$$sec$_$map$_$rules$_$name$_build_$srcrev$_$mediarev$.ndm</code>

These would result in the following file names respectively:

<code>scoreboard_20080205_103901_maps_sewer_tournament_first_Player_build_12095_33034.tga</code>

<code>20080205_103617_sewer_tournament_first_Player_build_12095_33034.ndm</code>

===Separate Vehicle Sensitivity Settings===

In Competition Mod it's possible to adjust mouse sensitivity for specific vehicles, allowing players to have high sensitivity in some vehicles with low sensitivity in others, all without effecting their sensitivity when playing as Infantry. The Cvars used to scale the sensitivity in the various vehicles are listed below. Each vehicle has two sensitivity cvars, one for vertical movement, one for horizontal. To adjust the general sensitivity then the value of both cvars should be the same.

{{consolecmd|m_bumblebeePitchScale}} – adjusts the vertical sensitivity in the Bumblebee 
{{consolecmd|m_bumblebeeYawScale}} – adjusts the horizontal sensitivity in the Bumblebee 
{{consolecmd|m_heavyVehiclePitchScale}} – adjusts the vertical sensitivity in the Titan, Cyclops and Desecrator 
{{consolecmd|m_heavyVehicleYawScale}} – adjusts the horizontal sensitivity in the Titan, Cyclops and Desecrator 
{{consolecmd|m_helicopterPitchScale}} – adjusts the vertical sensitivity in the Anansi and Tormentor 
{{consolecmd|m_helicopterYawScale}} – adjusts the horizontal sensitivity in the Anansi and Tormentor 
{{consolecmd|m_lightVehiclePitchScale}} – adjusts the vertical sensitivity in the Trojan, Armadillo, Hog and Husky 
{{consolecmd|m_lightVehicleYawScale}} – adjusts the horizontal sensitivity in the Trojan, Armadillo, Hog and Husky 
{{consolecmd|m_playerPitchScale}} – adjusts the vertical sensitivity as infantry and in the Icarus 
{{consolecmd|m_playerYawScale}} – adjusts the horizontal sensitivity as infantry and in the Icarus

Players are also able to switch yaw and roll between the keyboard and the mouse if they choose to using the cvar {{consolecmd|ui_swapFlightYawAndRoll}}. Setting this to a value of 1 causes the mouse to become the control for yaw and the keys to become the control for roll.

===Look at Killer/Medic===

Normally a dead players point of view will snap to look towards their killer or a nearby medic, this feedback is to help the user understand who just killed them or if they should tap out or not. With Competition Mod the player is now able to turn off this functionality if they choose to.

{{consolecmd|g_lookAtKiller}} – set this to a value of 0 to turn off the camera tracking a killer 
{{consolecmd|g_lookAtMedic}} – set this to a value of 0 to turn off the camera tracking nearby Medics/Technicians

Vehicle Tutorial Part 3

2007-12-04T11:25:34Z

192.168.0.152: /* Collision Damage */

== '''More Advanced Joints''' ==
[[Image:buggy_rough_rig2.jpg|frame|right|More advanced vehicle rig showing the joint positions and names.]]
You can now add extra joints as needed for more passengers, gunners, suspension, effects locations and exit points.
* '''Passengers''' - For each passenger you want to add, you will need a joint for the player location, and a joint for their first-person camera view.
* '''Gunners''' - This can be set up like a passenger, but with more scripting needed, as described in the Scripting section below.
* '''Suspension''' - These joints should be parented to the origin joint, and have the related wheel joint as a child.
* '''Exit points''' - These joints define more places that players may appear when they exit the vehicle.
* '''Effects locations''' - Used as an attachment location for effects such as smoke and fire when the vehicle is damaged.

=== '''Related Files''' ===
----
* [[Media:buggy_rig_advanced_max8.zip|More advanced rig example (3ds max 8 format)]]
* [[Media:buggy_rig_advanced_maya7.zip|More advanced rig example (Maya 7 format)]]

== '''More Scripting''' ==

In Part 2 you learnt how to get your vehicle into the game in a very rough state. Here we are going to expand on what we developed last time to improve it

=== Suspension ===
----
Now that we have suspension joints we can hook them up so that we can see the wheels moving up and down, following the ground. To the <tt>text</tt> part of the wheel template add the following line:
<tt>
"suspension" "vehicle_buggy_tute_FrontBackParm_LeftRightParm_suspension"
</tt>

This makes the wheel look for a <tt>stringMap</tt> to describe the suspension. The simplest type is <tt>vertical</tt>, which is the one we are going to use here:
<tt>
stringMap vehicle_buggy_tute_front_right_suspension {
"type" "vertical"
"joint" "front_right_suspension"
}
stringMap vehicle_buggy_tute_front_left_suspension {
"type" "vertical"
"joint" "front_left_suspension"
}
stringMap vehicle_buggy_tute_rear_right_suspension {
"type" "vertical"
"joint" "rear_right_suspension"
}
stringMap vehicle_buggy_tute_rear_left_suspension {
"type" "vertical"
"joint" "rear_left_suspension"
}
</tt>

These can go in the vscript file, outside the <tt>vehicleDef</tt>

=== Shooting it ===
----
At the moment your vehicle will not take damage when people shoot it - this is because it does not fit in any of the target lists used by the bullet damage definitions. To put it into these target lists we need to add the vehicle to some "collections". You'll need to add it to the following collections by adding these keys to the <tt>entityDef</tt>:
<tt>
"collection_antivehicle" "antivehicle"
"collection_vehicles_light" "vehicles_light"
"collection_vehicles_gdf" "vehicles_gdf"
</tt>

The first of these allows it to be targeted by anti-vehicle turrets. The second marks it as being a light vehicle - this means it will take more damage from bullets than if it were markes as a heavy vehicle. The last one allows it to be damaged by various map entities, for example Strogg energy walls.

=== Damage Effects ===
----
You'll probably now notice that your vehicle will have flames/smoke coming from the origin of the model when it gets significantly damaged. This is where your damage effect joint comes in - again, these keys go in the <tt>entityDef</tt>:
<tt>
"joint_damage_smoke" "effects"
"joint_damage_fire" "effects"
</tt>

This will make the damage effects play at the joint named <tt>effects</tt>. You can adjust the effects that play, and when they play, with the following keys:
<tt>
"damage_smoke" "70"
"damage_level1" "50"
"damage_level2" "30"
"damage_level3" "10"

"fx_damage_level_smoke" "effects/vehicles/generic_smoke"
"fx_damage_level1" "effects/vehicles/vehicle_flames_small"
"fx_damage_level2" "effects/vehicles/vehicle_flames_medium"
"fx_damage_level3" "effects/vehicles/vehicle_flames_large"
</tt>

The smoke effect will play at the same time as the damage level 1, 2, or 3 effects. When the vehicle's health drops below the value specified by <tt>"damage_smoke"</tt> etc the corresponding effect will be played. I have given the default values here.

=== Collision Damage ===
----
Your vehicle will not currently do any damage to anything else in a collision. For this you'll need to make a new damage type for the collision:
<tt>
damageDef damage_buggy_tute_collide {
damage "damage_buggy_tute_collide"

team_kill_cvar "g_allowComplaint_vehicles"

tt_obituary "tooltips/killmsgs/vehicles/buggy_tute"
tt_obituary_unknown "tooltips/killmsgs/vehicles/buggy_tute/empty"
tt_obituary_team_kill "tooltips/killmsgs/vehicles/buggy_tute/teamkill"
tt_obituary_self "tooltips/killmsgs/vehicles/driving"
}

damageFilter damage_buggy_tute_collide {
type {
target "target_player_all"
damage 100
}
type {
target "target_veh_all"
damage 100
}
type {
target "target_supply_crate"
damage 200
}
type {
target "target_deployables_all"
damage 100
}
}
</tt>

I put these in the <tt>buggy_tute.def</tt> file, below the vehicle's <tt>entityDef</tt>. Then you'll need to add the following key to the vehicle's <tt>entityDef</tt>:

<tt>
"dmg_collide" "damage_buggy_tute_collide"
</tt>

This sets up a damage filter listing the target sets that are damaged by the vehicle, and values that scale the damage caused - the damage caused varies with the speed of the collision. The damage definition also specifies a cvar that can be used to enable and disable complaints for team kills by this damage type, and obituary names. I'll describe how to set the obituaries up below.

=== Name ===
----
Anything to be displayed on the HUD needs to be a localized string. Its pretty easy to create new strings, but there are a few files involved. First of all you'll want to create a few directories under your mod directory: <tt>localization</tt>, <tt>localization/locstr</tt>, <tt>localization/english</tt>, and <tt>localization/english/strings</tt>. Now create a couple of files to put your new strings in: <tt>localization/locstr/buggy_tute.locstr</tt>, and <tt>localization/english/strings/buggy_tute.lang</tt>. Into the <tt>locstr</tt> files go <tt>locString</tt> definitions, which are named strings that can have arguments. Into <tt>lang</tt> files go tables of string values. This allows there to be <tt>lang</tt> files for each language, having different strings for each language but with them all looking the same from the rest of the game's code & data.

Into the <tt>locstr</tt> file add:
<tt>
locString game/vec/buggy_tute {
text "#str_10000100"
}
</tt>

The number in the string is used to identify the number of the localized string in the <tt>lang</tt> file. All strings in retail ETQW are numbered less than 10000000, so values over that are safe. I like to set aside a range of values for a category of strings - in this case I'm setting aside the range 10000100 -> 10000200 for this vehicle. This helps prevent the situation where you have to search through all the files to find an unused number.
* '''Note:''' You do not have to use this exact numbering scheme, for example to prevent conflicts you could call your string ''"#str_buggy_001"'' etc. This is slightly easier to remember and less potential string conflicts to worry about.

In the <tt>lang</tt> file all the strings must be between a pair of braces, so add:
<tt>
{
"#str_10000100" "Buggy!"
}
</tt>

Any further strings I add for this car I'll be adding in between the two braces.
You can now hook this up to the vehicle entity by changing the value of its <tt>"info_name"</tt> key to <tt>"game/vec/buggy_tute"</tt>. When you look at the vehicle in the game you should now see "Buggy!" :)

=== Obituaries ===
----
There are three obituaries we need to fill in (we referenced them above when we made a collision damage definition). The strings for these are referenced via a tooltip definition, so we need to make those:
<tt>
tooltip tooltips/killmsgs/vehicles/buggy_tute {
text "game/obit/buggy_tute"
}

tooltip tooltips/killmsgs/vehicles/buggy_tute/empty {
text "game/obit/buggy_tute_empty"
}

tooltip tooltips/killmsgs/vehicles/buggy_tute/teamkill {
text "game/obit/buggy_tute_team"
}
</tt>

I added these at the end of the <tt>buggy_tute.def</tt> file. Next we need to set up the localized string definitions for these:
<tt>
locString game/obit/buggy_tute {
text "#str_10000101"
}

locString game/obit/buggy_tute_empty {
text "#str_10000102"
}

locString game/obit/buggy_tute_team {
text "#str_10000103"
}
</tt>

And finally the actual localized strings:
<tt>
"#str_10000101" "%b^0 &lbrBuggy&rbr %a"
"#str_10000102" "&lbrBuggy&rbr %a"
"#str_10000103" "%b^1 &lbrBuggy&rbr ^0%a"
</tt>

These strings have some interesting escape sequences in them. <tt>%a</tt> and <tt>%b</tt> are replaced with the names of the name of the killer and the killed respectively, <tt>&lbr</tt> and <tt>&rbr</tt> are replaced by left square brackets and right square brackets respectively, and the caret ( <tt>^</tt> ) symbol allows the text colour to be changed.

=== Command Map ===
----
At the moment your vehicle won't be visible on the command map. This is easy fixed:
<tt>
"icon_size_cm" "16"
"mtr_commandmap" "guis/assets/commandmap/icon_vehicle"
"mtr_commandmap_unknown" "guis/assets/commandmap/icon_vehicle"
</tt>

The first key sets the size of the icon and the other two set the material to be used for the icon. The unkown material isn't really important in this case, you should just set it to the same as the normal material as I have done here.

=== Control Binding Context ===
----
In ETQW bindings can be context sensitive, and by using a series of cvars (one for each vehicle type) you can customize the control layout for each vehicle. To set the name of the context cvar your vehicle uses you can add the following key to your vehicle's <tt>entityDef</tt>:
<tt>
"control_context" "g_bind_context_buggy"
</tt>

Note that you can call the cvar whatever you like. To create the cvar you will need to pull the console down and set it by typing something like <tt>set g_bind_context_buggy vehicle</tt>. This can be included in config files with your mod to ensure people have the cvars created.

=== Tuning the Steering ===
----
The default values for the steering tend to be pretty good for most cases. The steering works on the principle that there is a direction in which the player wants to go - by pressing left and right they alter the direction they want to go in. The game then tries to steer towards that direction. When driving a real car you automatically adjust the steering wheel as you go over bumps etc by feel - you do not get any of this feeling from a keyboard, normally by the time you see your car veering to one side from hitting a bump its already too late to correct it neatly. Keyboards are also an on/off input device, so making subtle corrections is very difficult. The game is essentially trying to compensate for your lack of this feeling of the road surface and make all the subtle adjustments you aren't able to make.

There are a number of keys that can be set on the vehicle's <tt>entityDef</tt> to adjust the behaviour of the steering:

{|border="1" cellpadding="4" cellspacing="0"
| style="background:#dfdfdf" | '''Key''' || style="background:#dfdfdf" | '''Default Value''' || style="background:#dfdfdf" | '''Description'''
|-
| <tt>steering_angle</tt> || n/a || The maximum steering angle.
|-
| <tt>simplesteer_forward_speed</tt> || 2 || The speed at which the desired direction of movement will change due to player input while moving forward.
|-
| <tt>simplesteer_reverse_speed</tt> || -4 || The speed at which the desired direction of movement will change due to player input while moving in reverse.
|-
| <tt>simplesteer_centering_speed_min</tt> || 2 || The minimum speed at which the steering will tend to center back towards the current movement direction.
|-
| <tt>simplesteer_centering_speed_max</tt> || 15 || The maximum speed at which the steering will tend to center back towards the current movement direction.
|-
| <tt>simplesteer_centering_ramp_threshold</tt> || 20 || The vehicle speed at which the centering speed will drop to the minimum value (as the vehicle speeds up the steering becomes less twitchy).
|-
| <tt>simplesteer_centering_speed_air</tt> || 0.5 || The speed at which the steering will tend to center back towards the current movement direction while the vehicle is airborne (so it doesn't lose the direction of movement too fast when jumping).
|-
| <tt>simplesteer_reverse_angle_scale</tt> || -0.5 || Scales the amount/direction of steering when moving in reverse.
|}

For example if you wish the player's input to result in the vehicle turning faster you can increase <tt>simplesteer_forward_speed</tt>.

=== Engine Sounds ===
----
One thing thats our vehicle lacks so far is sound. ETQW wheeled vehicles use three looping samples that are cross-faded and pitched with varying speeds and accelerator input values. In addition to this there is an engine start sound and an engine stop sound for when the driver gets in or out. All of these things are defined in the <tt>entityDef</tt>.

Firstly you'll need to set the sound control method:
<tt>
"sound_control" "wheeled"
</tt>

You need to specify the samples to be used. We use an idle sample & a drive sample, where idle is cross-faded with the drive as speed increases, and a "hard acceleration" sample which is faded in and out with speed and input. This is meant to emulate the ferocious exhaust note you hear on a vehicle that is accelerating hard.

<tt>
"snd_engine_start" "sounds/vehicles/badger/engine/start"
"snd_engine_stop" "sounds/vehicles/badger/engine/stop"
"snd_engine_idle" "sounds/vehicles/badger/engine/idle"
"snd_engine_drive" "sounds/vehicles/badger/engine/drive"
"snd_engine_hardaccel" "sounds/vehicles/husky/engine/hardaccel"
</tt>

In my case I'm reusing most of the sounds of the badger, but mixing in the husky acceleration sound to hopefully make it sound a bit more raw.

The first few parameters control the change in pitch of the samples as the vehicle changes pitch:
<tt>
"engine_pitch_low" "1.5"
"engine_pitch_high" "2"
"engine_speed_low" "10"
"engine_speed_high" "150"
</tt>

This sets the high & low levels of the pitch and the speeds at which they occur. At <tt>engine_speed_low</tt> the pitch will be <tt>engine_pitch_low</tt> and similarly for high speed. The pitch is linearly ramped between those two. The original pitch in the sample is 1, so 1.5 is 50% faster, and 0.5% is 50% slower.

The next few parameters control engine "spooling" - this is meant to emulate the fact that an engine does not speed up or slow down instantly:
<tt>
"engine_accel_spool_time" "0.033"
"engine_decel_spool_time" "0.033"
</tt>

This is how long it takes for the "engine speed" to reach the actual speed of movement, in seconds. 0.033 is instant (1 / 30 - ie, one 30fps game frame).

Next are the volume settings for the idle and drive samples:
<tt>
"engine_idle_min_speed" "5.0"
"engine_idle_max_speed" "50.0"
"engine_idle_min_vol" "0.0"
"engine_idle_max_vol" "-50.0"
"engine_idle_power" "1.0"
"engine_idle_fade_time" "0.066"

"engine_drive_min_speed" "20.0"
"engine_drive_max_speed" "80.0"
"engine_drive_min_vol" "-20.0"
"engine_drive_max_vol" "-5.0"
"engine_drive_power" "0.3"
"engine_drive_fade_time" "0.066"
</tt>

At the min speed the sample will be at min volume - at max speed the sample will be at max volume. The sample will change between the two depending on the power value. This adjusts the linearity of the curve - 1 is linear, greater than 1 is exponential (slow change at first, fast change later), and less than 1 (but greater than zero) changes fast at first and slowly later. The fade time governs how long it takes the sound to fade away when the engine is shut off. All volume settings are measured in decibels, with zero being the original sample volume.

Next are the acceleration sound tuning parameters - these are much more complicated. First of all there are parameters to allow the pitch to be adjusted semi-independently of the idle and drive samples:
<tt>
"engine_accel_pitch_mult" "1.0"
"engine_accel_pitch_offset" "0.5"
</tt>

The pitch used for the other samples is subtracted from the minimum pitch, multiplied by the pitch multiplier and added to the offset. This effectively allows the pitch to change over a different range of values, given the same speed range, with the offset value giving the minimum. The pitch and the volume can also be adjusted based on the yaw speed of the vehicle (see the Titan/MCP for examples).

The volume of the acceleration sound has three key points - a min, mid and a max value. Each has a speed and a corresponding volume, and the transition between min & mid and mid & max each have their own power values to adjust the linearity of the transition. It is also increased when going up steep slopes and when the player is accelerating, to emulate the engine straining.
<tt>
"engine_accel_min_speed" "1.0"
"engine_accel_mid_speed" "20.0"
"engine_accel_max_speed" "80.0"
"engine_accel_min_vol" "-5.0"
"engine_accel_mid_vol" "5.0"
"engine_accel_max_vol" "-3.0"
"engine_accel_power_low" "0.1"
"engine_accel_power_high" "5.0"
"engine_accel_fade_time" "0.0"
</tt>

==== Overdrive Sounds ====

There are default overdrive sound settings, but you may want to tweak those. They support pitch shifting much like the engine sounds:
<tt>
"snd_overdrive" "sounds/vehicles/husky/overdrive"
"snd_overdrive_stop" "sounds/vehicles/husky/overdrive/stop"

"overdrive_pitch_low" "0.9"
"overdrive_pitch_high" "1.5"
"overdrive_speed_low" "20"
"overdrive_speed_high" "90"
</tt>

=== Miscellaneous Sounds ===
----
There are a couple of other sounds used by vehicles - the horn, and the low health warning. These are dead easy to configure:
<tt>
"snd_horn_loop" "sounds/vehicles/husky/horn"
"snd_horn_stop" "sounds/vehicles/husky/horn/stop"

"snd_health_warn" "sounds/vehicles/misc/warning/ground/gdf"
</tt>

The keys used should be pretty self-explanatory for these!

<noinclude>'''[[Vehicle Tutorial Part 4|Click here to continue on to Part 4 of the Vehicle Tutorial.]]'''
[[Category:Models]]
[[Category:Vehicles]]
[[Category:Tutorials]]
</noinclude>

Vehicle Tutorial Part 3

2007-12-04T11:25:24Z

192.168.0.152: /* Collision Damage */

== '''More Advanced Joints''' ==
[[Image:buggy_rough_rig2.jpg|frame|right|More advanced vehicle rig showing the joint positions and names.]]
You can now add extra joints as needed for more passengers, gunners, suspension, effects locations and exit points.
* '''Passengers''' - For each passenger you want to add, you will need a joint for the player location, and a joint for their first-person camera view.
* '''Gunners''' - This can be set up like a passenger, but with more scripting needed, as described in the Scripting section below.
* '''Suspension''' - These joints should be parented to the origin joint, and have the related wheel joint as a child.
* '''Exit points''' - These joints define more places that players may appear when they exit the vehicle.
* '''Effects locations''' - Used as an attachment location for effects such as smoke and fire when the vehicle is damaged.

=== '''Related Files''' ===
----
* [[Media:buggy_rig_advanced_max8.zip|More advanced rig example (3ds max 8 format)]]
* [[Media:buggy_rig_advanced_maya7.zip|More advanced rig example (Maya 7 format)]]

== '''More Scripting''' ==

In Part 2 you learnt how to get your vehicle into the game in a very rough state. Here we are going to expand on what we developed last time to improve it

=== Suspension ===
----
Now that we have suspension joints we can hook them up so that we can see the wheels moving up and down, following the ground. To the <tt>text</tt> part of the wheel template add the following line:
<tt>
"suspension" "vehicle_buggy_tute_FrontBackParm_LeftRightParm_suspension"
</tt>

This makes the wheel look for a <tt>stringMap</tt> to describe the suspension. The simplest type is <tt>vertical</tt>, which is the one we are going to use here:
<tt>
stringMap vehicle_buggy_tute_front_right_suspension {
"type" "vertical"
"joint" "front_right_suspension"
}
stringMap vehicle_buggy_tute_front_left_suspension {
"type" "vertical"
"joint" "front_left_suspension"
}
stringMap vehicle_buggy_tute_rear_right_suspension {
"type" "vertical"
"joint" "rear_right_suspension"
}
stringMap vehicle_buggy_tute_rear_left_suspension {
"type" "vertical"
"joint" "rear_left_suspension"
}
</tt>

These can go in the vscript file, outside the <tt>vehicleDef</tt>

=== Shooting it ===
----
At the moment your vehicle will not take damage when people shoot it - this is because it does not fit in any of the target lists used by the bullet damage definitions. To put it into these target lists we need to add the vehicle to some "collections". You'll need to add it to the following collections by adding these keys to the <tt>entityDef</tt>:
<tt>
"collection_antivehicle" "antivehicle"
"collection_vehicles_light" "vehicles_light"
"collection_vehicles_gdf" "vehicles_gdf"
</tt>

The first of these allows it to be targeted by anti-vehicle turrets. The second marks it as being a light vehicle - this means it will take more damage from bullets than if it were markes as a heavy vehicle. The last one allows it to be damaged by various map entities, for example Strogg energy walls.

=== Damage Effects ===
----
You'll probably now notice that your vehicle will have flames/smoke coming from the origin of the model when it gets significantly damaged. This is where your damage effect joint comes in - again, these keys go in the <tt>entityDef</tt>:
<tt>
"joint_damage_smoke" "effects"
"joint_damage_fire" "effects"
</tt>

This will make the damage effects play at the joint named <tt>effects</tt>. You can adjust the effects that play, and when they play, with the following keys:
<tt>
"damage_smoke" "70"
"damage_level1" "50"
"damage_level2" "30"
"damage_level3" "10"

"fx_damage_level_smoke" "effects/vehicles/generic_smoke"
"fx_damage_level1" "effects/vehicles/vehicle_flames_small"
"fx_damage_level2" "effects/vehicles/vehicle_flames_medium"
"fx_damage_level3" "effects/vehicles/vehicle_flames_large"
</tt>

The smoke effect will play at the same time as the damage level 1, 2, or 3 effects. When the vehicle's health drops below the value specified by <tt>"damage_smoke"</tt> etc the corresponding effect will be played. I have given the default values here.

=== Collision Damage ===
----
Your vehicle will not currently do any damage to anything else in a collision. For this you'll need to make a new damage type for the collision:
<tt>
damageDef damage_buggy_tute_collide {
damage "damage_buggy_tute_collide"

team_kill_cvar "g_allowComplaint_vehicles"

tt_obituary "tooltips/killmsgs/vehicles/buggy_tute"
tt_obituary_unknown "tooltips/killmsgs/vehicles/buggy_tute/empty"
tt_obituary_team_kill "tooltips/killmsgs/vehicles/buggy_tute/teamkill"
tt_obituary_self "tooltips/killmsgs/vehicles/driving"
}

damageFilter damage_buggy_tute_collide {
type {
target "target_player_all"
damage 100
}
type {
target "target_veh_all"
damage 100
}
type {
target "target_supply_crate"
damage 200
}
type {
target "target_deployables_all"
damage 100
}
}
</tt>

I put these in the <tt>buggy_tute.def</tt> file, below the vehicle's <tt>entityDef</tt>. Then you'll need to add the following key to the vehicle's <tt>entityDef</tt>:

<tt>
"dmg_collide" "damage_buggy_tute_collide"
</tt

This sets up a damage filter listing the target sets that are damaged by the vehicle, and values that scale the damage caused - the damage caused varies with the speed of the collision. The damage definition also specifies a cvar that can be used to enable and disable complaints for team kills by this damage type, and obituary names. I'll describe how to set the obituaries up below.

=== Name ===
----
Anything to be displayed on the HUD needs to be a localized string. Its pretty easy to create new strings, but there are a few files involved. First of all you'll want to create a few directories under your mod directory: <tt>localization</tt>, <tt>localization/locstr</tt>, <tt>localization/english</tt>, and <tt>localization/english/strings</tt>. Now create a couple of files to put your new strings in: <tt>localization/locstr/buggy_tute.locstr</tt>, and <tt>localization/english/strings/buggy_tute.lang</tt>. Into the <tt>locstr</tt> files go <tt>locString</tt> definitions, which are named strings that can have arguments. Into <tt>lang</tt> files go tables of string values. This allows there to be <tt>lang</tt> files for each language, having different strings for each language but with them all looking the same from the rest of the game's code & data.

Into the <tt>locstr</tt> file add:
<tt>
locString game/vec/buggy_tute {
text "#str_10000100"
}
</tt>

The number in the string is used to identify the number of the localized string in the <tt>lang</tt> file. All strings in retail ETQW are numbered less than 10000000, so values over that are safe. I like to set aside a range of values for a category of strings - in this case I'm setting aside the range 10000100 -> 10000200 for this vehicle. This helps prevent the situation where you have to search through all the files to find an unused number.
* '''Note:''' You do not have to use this exact numbering scheme, for example to prevent conflicts you could call your string ''"#str_buggy_001"'' etc. This is slightly easier to remember and less potential string conflicts to worry about.

In the <tt>lang</tt> file all the strings must be between a pair of braces, so add:
<tt>
{
"#str_10000100" "Buggy!"
}
</tt>

Any further strings I add for this car I'll be adding in between the two braces.
You can now hook this up to the vehicle entity by changing the value of its <tt>"info_name"</tt> key to <tt>"game/vec/buggy_tute"</tt>. When you look at the vehicle in the game you should now see "Buggy!" :)

=== Obituaries ===
----
There are three obituaries we need to fill in (we referenced them above when we made a collision damage definition). The strings for these are referenced via a tooltip definition, so we need to make those:
<tt>
tooltip tooltips/killmsgs/vehicles/buggy_tute {
text "game/obit/buggy_tute"
}

tooltip tooltips/killmsgs/vehicles/buggy_tute/empty {
text "game/obit/buggy_tute_empty"
}

tooltip tooltips/killmsgs/vehicles/buggy_tute/teamkill {
text "game/obit/buggy_tute_team"
}
</tt>

I added these at the end of the <tt>buggy_tute.def</tt> file. Next we need to set up the localized string definitions for these:
<tt>
locString game/obit/buggy_tute {
text "#str_10000101"
}

locString game/obit/buggy_tute_empty {
text "#str_10000102"
}

locString game/obit/buggy_tute_team {
text "#str_10000103"
}
</tt>

And finally the actual localized strings:
<tt>
"#str_10000101" "%b^0 &lbrBuggy&rbr %a"
"#str_10000102" "&lbrBuggy&rbr %a"
"#str_10000103" "%b^1 &lbrBuggy&rbr ^0%a"
</tt>

These strings have some interesting escape sequences in them. <tt>%a</tt> and <tt>%b</tt> are replaced with the names of the name of the killer and the killed respectively, <tt>&lbr</tt> and <tt>&rbr</tt> are replaced by left square brackets and right square brackets respectively, and the caret ( <tt>^</tt> ) symbol allows the text colour to be changed.

=== Command Map ===
----
At the moment your vehicle won't be visible on the command map. This is easy fixed:
<tt>
"icon_size_cm" "16"
"mtr_commandmap" "guis/assets/commandmap/icon_vehicle"
"mtr_commandmap_unknown" "guis/assets/commandmap/icon_vehicle"
</tt>

The first key sets the size of the icon and the other two set the material to be used for the icon. The unkown material isn't really important in this case, you should just set it to the same as the normal material as I have done here.

=== Control Binding Context ===
----
In ETQW bindings can be context sensitive, and by using a series of cvars (one for each vehicle type) you can customize the control layout for each vehicle. To set the name of the context cvar your vehicle uses you can add the following key to your vehicle's <tt>entityDef</tt>:
<tt>
"control_context" "g_bind_context_buggy"
</tt>

Note that you can call the cvar whatever you like. To create the cvar you will need to pull the console down and set it by typing something like <tt>set g_bind_context_buggy vehicle</tt>. This can be included in config files with your mod to ensure people have the cvars created.

=== Tuning the Steering ===
----
The default values for the steering tend to be pretty good for most cases. The steering works on the principle that there is a direction in which the player wants to go - by pressing left and right they alter the direction they want to go in. The game then tries to steer towards that direction. When driving a real car you automatically adjust the steering wheel as you go over bumps etc by feel - you do not get any of this feeling from a keyboard, normally by the time you see your car veering to one side from hitting a bump its already too late to correct it neatly. Keyboards are also an on/off input device, so making subtle corrections is very difficult. The game is essentially trying to compensate for your lack of this feeling of the road surface and make all the subtle adjustments you aren't able to make.

There are a number of keys that can be set on the vehicle's <tt>entityDef</tt> to adjust the behaviour of the steering:

{|border="1" cellpadding="4" cellspacing="0"
| style="background:#dfdfdf" | '''Key''' || style="background:#dfdfdf" | '''Default Value''' || style="background:#dfdfdf" | '''Description'''
|-
| <tt>steering_angle</tt> || n/a || The maximum steering angle.
|-
| <tt>simplesteer_forward_speed</tt> || 2 || The speed at which the desired direction of movement will change due to player input while moving forward.
|-
| <tt>simplesteer_reverse_speed</tt> || -4 || The speed at which the desired direction of movement will change due to player input while moving in reverse.
|-
| <tt>simplesteer_centering_speed_min</tt> || 2 || The minimum speed at which the steering will tend to center back towards the current movement direction.
|-
| <tt>simplesteer_centering_speed_max</tt> || 15 || The maximum speed at which the steering will tend to center back towards the current movement direction.
|-
| <tt>simplesteer_centering_ramp_threshold</tt> || 20 || The vehicle speed at which the centering speed will drop to the minimum value (as the vehicle speeds up the steering becomes less twitchy).
|-
| <tt>simplesteer_centering_speed_air</tt> || 0.5 || The speed at which the steering will tend to center back towards the current movement direction while the vehicle is airborne (so it doesn't lose the direction of movement too fast when jumping).
|-
| <tt>simplesteer_reverse_angle_scale</tt> || -0.5 || Scales the amount/direction of steering when moving in reverse.
|}

For example if you wish the player's input to result in the vehicle turning faster you can increase <tt>simplesteer_forward_speed</tt>.

=== Engine Sounds ===
----
One thing thats our vehicle lacks so far is sound. ETQW wheeled vehicles use three looping samples that are cross-faded and pitched with varying speeds and accelerator input values. In addition to this there is an engine start sound and an engine stop sound for when the driver gets in or out. All of these things are defined in the <tt>entityDef</tt>.

Firstly you'll need to set the sound control method:
<tt>
"sound_control" "wheeled"
</tt>

You need to specify the samples to be used. We use an idle sample & a drive sample, where idle is cross-faded with the drive as speed increases, and a "hard acceleration" sample which is faded in and out with speed and input. This is meant to emulate the ferocious exhaust note you hear on a vehicle that is accelerating hard.

<tt>
"snd_engine_start" "sounds/vehicles/badger/engine/start"
"snd_engine_stop" "sounds/vehicles/badger/engine/stop"
"snd_engine_idle" "sounds/vehicles/badger/engine/idle"
"snd_engine_drive" "sounds/vehicles/badger/engine/drive"
"snd_engine_hardaccel" "sounds/vehicles/husky/engine/hardaccel"
</tt>

In my case I'm reusing most of the sounds of the badger, but mixing in the husky acceleration sound to hopefully make it sound a bit more raw.

The first few parameters control the change in pitch of the samples as the vehicle changes pitch:
<tt>
"engine_pitch_low" "1.5"
"engine_pitch_high" "2"
"engine_speed_low" "10"
"engine_speed_high" "150"
</tt>

This sets the high & low levels of the pitch and the speeds at which they occur. At <tt>engine_speed_low</tt> the pitch will be <tt>engine_pitch_low</tt> and similarly for high speed. The pitch is linearly ramped between those two. The original pitch in the sample is 1, so 1.5 is 50% faster, and 0.5% is 50% slower.

The next few parameters control engine "spooling" - this is meant to emulate the fact that an engine does not speed up or slow down instantly:
<tt>
"engine_accel_spool_time" "0.033"
"engine_decel_spool_time" "0.033"
</tt>

This is how long it takes for the "engine speed" to reach the actual speed of movement, in seconds. 0.033 is instant (1 / 30 - ie, one 30fps game frame).

Next are the volume settings for the idle and drive samples:
<tt>
"engine_idle_min_speed" "5.0"
"engine_idle_max_speed" "50.0"
"engine_idle_min_vol" "0.0"
"engine_idle_max_vol" "-50.0"
"engine_idle_power" "1.0"
"engine_idle_fade_time" "0.066"

"engine_drive_min_speed" "20.0"
"engine_drive_max_speed" "80.0"
"engine_drive_min_vol" "-20.0"
"engine_drive_max_vol" "-5.0"
"engine_drive_power" "0.3"
"engine_drive_fade_time" "0.066"
</tt>

At the min speed the sample will be at min volume - at max speed the sample will be at max volume. The sample will change between the two depending on the power value. This adjusts the linearity of the curve - 1 is linear, greater than 1 is exponential (slow change at first, fast change later), and less than 1 (but greater than zero) changes fast at first and slowly later. The fade time governs how long it takes the sound to fade away when the engine is shut off. All volume settings are measured in decibels, with zero being the original sample volume.

Next are the acceleration sound tuning parameters - these are much more complicated. First of all there are parameters to allow the pitch to be adjusted semi-independently of the idle and drive samples:
<tt>
"engine_accel_pitch_mult" "1.0"
"engine_accel_pitch_offset" "0.5"
</tt>

The pitch used for the other samples is subtracted from the minimum pitch, multiplied by the pitch multiplier and added to the offset. This effectively allows the pitch to change over a different range of values, given the same speed range, with the offset value giving the minimum. The pitch and the volume can also be adjusted based on the yaw speed of the vehicle (see the Titan/MCP for examples).

The volume of the acceleration sound has three key points - a min, mid and a max value. Each has a speed and a corresponding volume, and the transition between min & mid and mid & max each have their own power values to adjust the linearity of the transition. It is also increased when going up steep slopes and when the player is accelerating, to emulate the engine straining.
<tt>
"engine_accel_min_speed" "1.0"
"engine_accel_mid_speed" "20.0"
"engine_accel_max_speed" "80.0"
"engine_accel_min_vol" "-5.0"
"engine_accel_mid_vol" "5.0"
"engine_accel_max_vol" "-3.0"
"engine_accel_power_low" "0.1"
"engine_accel_power_high" "5.0"
"engine_accel_fade_time" "0.0"
</tt>

==== Overdrive Sounds ====

There are default overdrive sound settings, but you may want to tweak those. They support pitch shifting much like the engine sounds:
<tt>
"snd_overdrive" "sounds/vehicles/husky/overdrive"
"snd_overdrive_stop" "sounds/vehicles/husky/overdrive/stop"

"overdrive_pitch_low" "0.9"
"overdrive_pitch_high" "1.5"
"overdrive_speed_low" "20"
"overdrive_speed_high" "90"
</tt>

=== Miscellaneous Sounds ===
----
There are a couple of other sounds used by vehicles - the horn, and the low health warning. These are dead easy to configure:
<tt>
"snd_horn_loop" "sounds/vehicles/husky/horn"
"snd_horn_stop" "sounds/vehicles/husky/horn/stop"

"snd_health_warn" "sounds/vehicles/misc/warning/ground/gdf"
</tt>

The keys used should be pretty self-explanatory for these!

<noinclude>'''[[Vehicle Tutorial Part 4|Click here to continue on to Part 4 of the Vehicle Tutorial.]]'''
[[Category:Models]]
[[Category:Vehicles]]
[[Category:Tutorials]]
</noinclude>

Main Page

2007-10-18T08:40:42Z

192.168.0.152: Modified Code section title

__NOTOC__= '''Tutorials''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Taking A Screenshot]] ===
|-
|
* '''[[Taking A Screenshot]]''' - Settings and options for making a great screenshot!
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Making a Terrain Model]] ===
|-
|
* '''[[Making a Terrain Model|Step 1]]''' - Create a terrain mesh for your map.
* More to go here, temp for now.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |

=== [[Vehicle Tutorial]] ===
|-
|
* '''[[Vehicle Tutorial Part 1|Step 1]]''' - Design considerations, before you do anything else!
* '''[[Vehicle Tutorial Part 2|Step 2]]''' - Initial rough model, rig and basic script.
* '''[[Vehicle Tutorial Part 3|Step 3]]''' - More advanced rig and scripting.
* '''[[Vehicle Tutorial Part 4|Step 4]]''' - Further technical setup ideas.
|-
|}
|}

= '''Script & Code''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Vehicle Scripting]] ===
|-
|
* '''[[Vehicle Scripting: Basic_Overview|Basic Overview]]''' - Introduction to vehicle setup.
* '''[[Vehicle Scripting: Entity_Definition|Entity Definition]]''' - One definition to rule them all!
* '''[[Vehicle Scripting: Vehicle_Definition|Vehicle Definition]]''' - Introduction to the ''.vscript'' file.
* '''[[Vehicle Scripting: Positions_&_Views|Positions & Views]]''' - Configuring player positions & camera views.
* '''[[Vehicle Scripting: Components|Components]]''' - Details of various vehicle components.
* '''[[Vehicle Scripting: Weapons|Weapons]]''' - Things that go boom!
* '''[[Vehicle Scripting: IK|IK]]''' - Inverse Kinematics & you...
* '''[[Vehicle Scripting: Cockpits|Cockpits]]''' - Cockpit setup.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Entity Scripting]] ===
|-
|
* '''[[EntityClass:Overview|Classes]]''' - Tree of entity types.
* '''[[ScriptEvent:List|Events]]''' - List of all script events.
* '''[[Scripting:Examples|Examples]]''' - Some example walkthoughs of building up a scripted entity.
* '''[[Script:Files|Script Files]]''' - List of the script files used by the game.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[GUIs]] ===
|-
|
* '''[[GUIs: Event Based Scripting|Event Based Scripting]]''' - GUIs are event-based.
* '''[[GUIs: Materials|Materials]]''' - Using materials in GUIs.
* '''[[GUIs: Transitions|Transitions]]''' - Transitions.
* '''[[GUIs: Templates|Templates]]''' - Using templates in GUIs.
* '''[[GUIs: List Enumeration|List Enumeration]]''' - List enumerations.
* '''[[GUIs: Properties|Properties]]''' - Player/Global properties and more.
* '''[[GUIs: Timelines|Timelines]]''' - GUI timelines.
* '''[[GUIs: Layouts|Layouts]]''' - Window layouts.
* '''[[Reference (GUIs)|Reference]]''' - GUI reference.
|-
|}
|}

= '''Design''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Introduction]] ===
|-
|
* '''[[Design: New In ETQW|What's new in ETQW]]''' - How ETQW mapping differs from Doom3/Quake4
* '''[[Design: editWorld Basics|editWorld Basics]]''' - A brief introduction to editWorld
* '''[[Design: editWorld from Radiant|editWorld for Radiant users]]''' - A guide for experienced Radiant users
* '''[[Design: editWorld from Worldcraft|editWorld for Worldcraft users]]''' - A guide for experienced Worldcraft users
* '''[[Design: ETQW from WET|ETQW or W:ET mappers]]''' - A guide to ETQW mapping for Wolfenstein: Enemy Territory mappers
* '''[[Design: References|'References']]''' - What are 'References', and how to create and edit them
* '''[[Design: Map files|Map files]]''' - List and description of files and file types that form a map
* '''[[Design: Troubleshooting|Troubleshooting]]''' - Common problems and how to fix or overcome them
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[editWorld]] ===
|-
|
* '''[[Design: editWorld Customisation|Customising editWorld]]''' - Customising editWorld's setup
* '''[[Design: How do I|How do I ...?]]''' - Quick reference for common and useful tasks
* '''[[Design: editWorld Bugs and Fixes|Bugs and Fixes]]''' - List of known and new bugs or issues with editWorld
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |

=== [[Primitives]] ===
|-
|
* '''[[Design: Brush Basics|Brush Basics]]''' - The basics of brush usage and editing
* '''[[Design: Portal Basics|Portal Basics]]''' - What portals are for and when to use them
* '''[[Design: Geometry Optimisation|Optimising Geometry]]''' - How to optimise map geometry for performance
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Entities]] ===
|-
|
* '''[[Design: Entity Basics|Entity Basics]]''' - The basics of entity usage and editing
* '''[[Design: Entity List|List of Entities]]''' - Descriptions and uses for all entities
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Lighting]] ===
|-
|
* '''[[Design: Lighting Basics|Lighting Basics]]''' - The basics of lighting and the different lights
|-
|}
|}

= '''Art''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Models]] ===
|-
|
* '''[[In-Game Models]]''' - Making models for use in the engine.
* '''[[High-Poly Models]]''' - Making source models for baking normal maps.
* '''[[Renderbump]]''' - Create normal maps from high-poly geometry.
* '''[[Imposters]]''' - Sprites used for rendering complex models cheaply at a distance.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Animation]] ===
|-
|
* '''[[MD5 Export Process]]''' - How to export an animated MD5.
* '''[[Vehicle Setup]]''' - How to set up a vehicle.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Textures]] ===
|-
|
* '''[[Basic Texture Overview]]''' - Supported texture types and implementations.
* '''[[Texturesheets]]''' - Overview of what texturesheets are, and when to use them.
* '''[[The Atlas Editor]]''' - Create environment texture sheets to improve performance.
* '''[[RenderBumpFlat]]''' - Create normal-maps from high-poly geometry.
* '''[[Detail Textures]]''' - Add high-frequency detail to your textures.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Terrain Editing]] ===
|-
|
* '''[[Making a Terrain Model]]''' - Create a terrain mesh for your map.
* '''[[Terrain Editor|EditWorld's Terrain Editor]]''' - Set up a Surface Tree for your MegaTexture.
* '''[[MegaBuild]]''' - Render and compile your MegaTexture.
* '''[[Water Surfaces#Water Models|Water Surfaces]]''' - Create water to go with your landscape.
* '''[[STUFF System]]''' - Procedurally distribute models over your terrain mesh.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Atmospheres and Effects]] ===
|-
|
* '''[[Atmosphere Editor|The Atmosphere Editor]]''' - Create and edit atmospheres for your map.
* '''[[Ambient Light Editor|The Ambient Light Editor]]''' - Create and edit ambient light setups.
* '''[[Environment Maps]]''' - Used for reflection effects.
* '''[[Water Surfaces]]''' - Creating water effects.
* '''[[Effects Editor|The Effects Editor]]''' - Create and edit particle effects.
* '''[[Cheap Decals]]''' - Bulletholes and other collision decals.
|-
|}
|}