Q3F Map Entity Documentation

Q3F Map Entity Documentation
$Id: q3f_entdocs.html,v 1.59 2002/08/25 02:20:49 rr2do2 Exp $

1. Overview
   1.1. What it's all about
   1.2. Basic principles
   1,4. What it can do
   1.4. What it can't do
2. Examples
   2.1. Different trigger types
   2.2. A sample flag
   2.3. A sample capture point
   2.4. A sample command point
   2.5. A sample HUD entity
3. Reference
   3.1. Entity States
   3.2. Messages
   3.3. Flaginfo
   3.4. Give
   3.5. Flags
   3.6. Targets
   3.7. Criteria
   3.8. Map Info
   3.9. Gameindices
   3.10. Custom Infoparms
4. Entities
   4.1. func_*
      4.1.1. func_commandpoint
      4.1.2. func_damage
      4.1.3. func_door_rotating
      4.1.4. func_explosion
      4.1.5. func_forcefield
      4.1.6. func_goalinfo
      4.1.7. func_goalitem
      4.1.8. func_hud
      4.1.9. func_nobuild
      4.1.10. func_train and path_corner
      4.1.11. func_wall
   4.2. target_*
      4.2.1. target_cycle
      4.2.2. target_location
      4.2.3. target_multiport
      4.2.4. target_respawn
      4.2.5. target_semitrigger
   4.3. info_*
      4.3.1. info_notnull
      4.3.2. info_player_start
   4.4. misc_*
      4.4.1. misc_beam
      4.4.2. misc_flare
      4.4.3. misc_onkill
      4.4.4. misc_onprotect
      4.4.5. misc_sunflare
   4.5. path_*
      4.5.1. path_spline
   4.6. panel_*
      4.6.1. Panel entities
      4.6.2. panel_location
      4.6.3. panel_message
      4.6.4. panel_name
      4.6.5. panel_radar
      4.6.6. panel_scoresummary
      4.6.7. panel_timer
   4.7. Other Entities
      4.7.1. Worldspawn (classlimits and atmospheric effects)
      4.7.2. CTF compatability entities

1. Overview

1.1. What it's all about
The Q3F entities are intended to be an extension to existing entities rather than replacing the current entities (at least, as far as possible). Currently, they're both incomplete and potentially bug-ridden. Many features we'd like to add haven't yet been added, and some entity types will not coexist happily with the extensions.

Lastly, before we begin, I'd just like to say I'm a great believer in programming first and documenting as late and as little as possible, in the grand tradition. Blame that if this document makes no sense. :)

- Golliwog

Right, since I've taken over since then, some quick remarks om big changes. Initially the entities info_notnull, func_goalitem, func_commandpoint and func_goalinfo defaulted to a 30 second wait. Also when there was NO wait field given. This default wait has been removed since Beta1f to stop some serious issues and make the entities more logical. If your map was based around this default wait, a recompile is needed.

Also, some of the worldspawn fields have changed, to make them shorter. Q3 couldn't parse the long keys and gave errors on compile. Finally, the ammo_bullets is now called ammo_nails, which is more logically too ;)

- RR2DO2

1.2. Basic principles
Essentially, each entity has a 'state', as follows:

Invisible This entity is not triggerable, nor is it visible (although this has some odd side effects, e.g. invisible doors still stop people walking through them).

Disabled This entity is not triggerable.

Inactive This entity is idle (and can be thought of as 'touchable'). For goalitems, this means 'back at base'.

Active This entity is active, and (depending on its settings), will go back to inactive after a set time. For goalitems, this means 'lying on the ground'.

Carried This state only applies to goalitems.

When successfully touched by a player, an entity will attempt to go to carried/active state. After a set time, active entities will automatically go back to inactive.

Entities can also trigger other entities in a 'cascade' of triggers, by using <state>target keys, e.g. on a flag entity you might have "carriedtarget" "alarms" - that would activate all 'alarms' entities when a flag became carried.

There are a set of criteria checked before an entity can be triggered (although triggers can also be 'forced' to ignore criteria, more on this later).

In addition to this, players can be 'given' bonuses, and teams can be given scores, as well as having messages and sounds played.

1.3. What it can do
It can be used to create complex map effects and the like (think of Team Fortress), as well as some degree of 'scripting'.

1.4. What it can't do
It can't be used as a language in it's own right - it will maintain no variables, parse no scripts. This may become available in a future release, but not right now (also, there would be performance questions in a scripting language).

2. Examples

2.1. Different trigger types
There are six main sorts of triggers you'll use:

Brush triggers	This is something like a trigger_multiple - an area brush that triggers when you walk over it.
Point triggers	These are used as func_goalinfo entities, and can have mins and maxs set to define their actual size. They trigger when you walk into the defined area surrounding the entity - they can also do other effects, such as showing a model that becomes invisible while active, etc.
Untouchable triggers	These are usually set as info_notnull, and act as relays or simply alternative triggers (i.e. two entities with the same name, one only triggerable by blue and one only triggerable by red).
Flags	These are used as func_goalitem entities (or func_flag, same thing), and are 'carried' by the player when successfully touched.
Standard entities	These are things like func_door, or info_player_start entities - they act in more or less the usual fashion, but the criteria and cascading triggers still operate.
Special entities	These are things like the func_commandpoint - new entities that have special behaviour defined by the entity. (More on these later).

2.2. A sample flag
A 'flag' is a carryable entity that can only be carried by one team, and does various effects when carried.

{
	// The red flag 

	"classname" "func_goalitem"
	"origin" "1248 1984 -328"

	// What it looks like
	"model" "models/flags/r_flag.md3"	// Model to use
	"light" "200"				// Dynamic light
	"color" "1 0 0"				// Pure red
	"sparkle" "1 0 0"			// Generate smoke puffs around carrier

	// What it's called
	"groupname" "redflag"

	// Criteria
	"allowteams" "blue"			// Only blue players can trigger (i.e. carry)

	// Messages on trigger
	"carried_message" "~You've got the red flag! Run!"	// Centerprint message to activator
	"carried_all_message" "%N took the red flag!"		// Tell everyone activator has done it
	"carried_all_sound" "sound/teamplay/flagtk_red.wav"	// Play a sound to everyone (w/ attenuation)
	"inactive_all_message" "the red flag has returned"

	// Flaginfo (shown on \flaginfo command)
	"carried_flaginfo" "%N has the red flag"
	"active_flaginfo" "The red flag is lying at %l"
	"inactive_flaginfo" "The red flag is in the red base"

	// Misc
	"flags" "revealagent,showcarry"				// Reveal spies on trigger, show flag above player when carried
	"wait" "10"						// Wait 10 seconds before going inactive (i.e. back to base)
}

2.3. A sample capture point
Now we have a flag, we need somewhere to capture it.

{
	// The capture point in the blue base

	"classname" "trigger_multiple"
	"model" "*10"						// Origin/size defined by brush

	// Criteria
	"holding" "redflag"					// Only trigger if activator holds redflag

	// Messages
	"active_all_message" "~%N CAPTURED the red flag!"	// Centerprint message to everyone
	"active_sound" "sound/teamplay/flagcap_blu.wav"		// Play sound to activator
	"active_team_sound" "sound/teamplay/flagcap_blu.wav"	// Play sound to activator's team (apart from activator)

	// 'Give' bonuses
	"flags" "affectteam"					// Affect activator's entire team
	"give" "gren1=+2,gren2=+2,quad=+6"			// Give affected players two more of each grenade, and 6 seconds more of quad
	"teamscore" "10"					// Give activator's team 10 points (the teamscore, not the players on the team)

	"activetarget" "redflag=~inactive,scorer"		// When activated, force redflag to inactive (back to base), trigger scorer (optional extra 10 points entity)
}

2.4. A sample command point
To make things a little more interesting, why don't we have a 'scorer' command point that gives players an extra 10 points when they capture the flag?

{
	// A button to press to claim the command point

	"classname" "func_button"
	"model" "*1"
	"angle" "-2"
	"wait" "5"
	"activetarget" "scorer_cp"	// Trigger the scorer command point when activated
}

{
	// The scorer command point (no model, so must be triggered by another entity)

	"classname" "func_commandpoint"
	"origin" "448 832 -128"

	// Misc
	"groupname" "scorer_cp"

	// Messages
	"active_all_message" "~%N has claimed the\ncapture bonus for the %T!"

	// On activation (i.e. touch if we have a model, or trigger by a button or something otherwise)
	"teamset" "scorer"			// All entities named 'scorer' are locked to activators team
	"activetarget" "scorer=inactive"	// Set scorer to inactive (i.e. ready to be activated)
}

{
	// An untouchable 'scorer' entity
	"classname" "info_notnull"
	"origin" "444 828 -84"			// Hardly 'essential' in this case...

	// Misc
	"groupname" "scorer"			// So other entities can reference
	"initialstate" "disabled"		// Prevent scorer from being triggered initially (i.e. until command point is claimed)

	// On activation
	"teamscore" "10"				// Give the activator's team 10 points
	"wait" "1"				// Go inactive after 1 second (the chances of someone capturing twice in under a second are pretty slim...)
}

2.5. A sample HUD entity
We've forgotten something - we need to show a player if he's carrying the flag or not, or he's liable to get confused (and upset if he finds he's had it for the last 5 minutes without capturing). We need a HUD entity.

{
	// A HUD entity shown to the red flag carrier
	"classname" "func_hud"
	"origin" "1252 1980 -292"

	"inactive_model" "models/flags/r_flag.md3"	// Entity never actually activates, just show this model
	"slot" "1"					// Display it in slot 1 (top left)
	"holding" "redflag"				// Only player holding redflag can see this entity
}

3. Reference.

3_1. Entity States
Essentially, each entity has a 'state', as follows:

Invisible	This entity is not triggerable, nor is it visible (although this has some odd side effects, e.g. invisible doors still stop people walking through them).
Disabled	This entity is not triggerable.
Inactive	This entity is idle (and can be thought of as 'touchable'). For goalitems, this means 'back at base'.
Active	This entity is active, and (depending on its settings), will go back to inactive after a set time. For goalitems, this means 'lying on the ground'.
Carried	This state only applies to goalitems.

When a player touches an entity and the criteria are passed, it will be triggered to carried (if it's a carryable entity), or active.

Unless forced (see targets), only certain state changes are permitted (note that you cannot change state to the current state (nothing at all will happen):

invisible disabled inactive active carried

invisible * *

disabled * *

inactive * * * *

active * *

carried * *

When an entity changes state, it will trigger any messages or sounds for that state, as well as executing give (only when in carried/active state, depending on whether it can be carried), teamscore (again, only in carried/active) and <state>target (see targets).

An entity can have it's state changed a maximum of 5 times (currently) per-frame single frame - this is to prevent infinite loops from hanging the server - but you would be wiser to avoid any situations where this kicks in (since you cannot always be sure what state the entity will end up in, particularly if the limit changes).

3.2. Messages
When an entity changes state, messages and sounds can be sent out to various players, optionally with the 'force' flag (prefixing the string with a ~ symbol). The force flag causes messages to be centerprinted and sounds to be global (i.e. no attenuation). Messages can be sent to four different groups: The activator, the activator's team (excluding activator), all players not on the activator's team, or all players.

<state>_message Send a message to the activator.

<state>_team_message Send a message to the activator's teammates.

<state>_nonteam_message Send a message to all players not on the activator's team.

<state>_all_message Send a message to all players.

<state>_sound Play a sound to the activator (currently, plays globally as though ~ was specified).

<state>_team_sound Play a sound to the activator's teammates (currently, plays globally as though ~ was specified).

<state>_nonteam_sound Play a sound to all players not on the activator's team (currently, plays globally as though ~ was specified).

<state>_all_sound Play a sound to all players.*

<state>_dict Parse and play sound to the activator.*

<state>_team_dict Parse and play a sound to the activator's teammates.*

<state>_nonteam_dict Parse and play a sound to all players not on the activator's team.*

<state>_all_dict Parse and play a sound to all players.*

<state> in the above strings means the state to play on, e.g. active_message. For sounds, currently only sounds everyone can hear (<state>_all_sound) can be played 'unforced' (i.e. fades with distance from the entity).

Additionally, there is another prefix that is not a state. This is the kill prefix. It is used just as the other messages, but usefull for o.a. trigger_hurt entities. Example: "kill_all_message" "%n shouldn't have been here." as a keypair on a trigger_hurt will display "Dummy shouldn't have been here." as a deathmessage when the player called Dummy gets killed by the trigger_hurt.

*The _dict functions are still in development. The string is split into words, which are then checked against the contents of sound/sounddict.txt. If the word or the actual sample isn't found, it will attempt to play the word as single letters - don't use player name tokens in _dict strings, they're almost certainly going to come out as single letters. Also, not all sounds are currently present, and the dictionary will probably be expanded.

Messages can also contain tokens that are expanded as required. Tokens in UPPERCASE represent the activator (if present). Tokens in lowercase represent the entity itself:

%H Health

%A Armour

%L Location (returns 'unknown location' if unable to work it out)

%D Location of last death.

%R Last reported location (i.e. identical to last %L)

%T Team name (e.g. "Red Team", "Blue Team" etc.)

%C Team colour (e.g. red, blue etc.)

%G Disguise (returns 'not disguised' if not wearing a disguise)

%N Name (player name / entity groupname (or one of them)

%E State (e.g. "active", "carried" etc.)

%S Class (e.g. "soldier", "medic" etc.)

For example, you could say:

"active_nonteam_message" "%N has the red flag at %L (and only %H health left)"

Incidentally, you can use these tokens in communications as well (with UPPERCASE being the sender and lowercase being each individual recipient), save that you require $ instead of %. If you want to annoy everyone on the server, just say "Hello $n, I'm $N of the $T." (I wouldn't really recommend it, though).

3.3. Flaginfo
Flaginfo is sent to players who execute a \flaginfo command. All entities that have a <state>_flaginfo will have that info sent to the client. Normally, it's flags and the like that keep flaginfo, hence the command name. For flags, you'd expect a carried, active, and inactive flaginfo string, e.g.

"carried_flaginfo" "%N has the red flag at %L (and only %H health left)"
"active_flaginfo" "The red flag is lying in the field at %l" (note the lowercase, there's no carrier!)
"inactive_flaginfo" "The red flag is safe at base"

3.4. Give
Entities can 'give' bonuses to affected players when set to carried (if a carryable entity) or active (if not). The give string is of the form "give" "stat=value,stat=value,stat=value". The following stats are available:

health Health

armor Armor

damage Deal damage to the target

ammo_shells Shells

ammo_bullets Bullets

ammo_rockets Rockets

ammo_cells Cells

ammo_medikit Medikit ammo

ammo_charge HE Charge

score Player score (not teamscore)

gren1 Grenade type 1

gren2 Grenade type 2

quad Seconds of quad damage

regen Seconds of regen

flight Seconds of flight

battlesuit Seconds of battlesuit

invis Seconds of invisibility (shimmer invis, not agent invis)

haste Seconds of haste

invuln Seconds of invulnerability

aqualung Seconds of aqualung

ceasefire Seconds a player is unable to shoot

gas Seconds of gas

stun Seconds of stun

flash Seconds of flash

tranq Seconds of tranq

fire Amount of fire counters, every counter does a certain amount of burn damage every few seconds

armortype Armour type (as a number from 0-100). This is the amount of damage the armour saves you from*

aclass_shell If true, give 15% extra protection against shells (otherwise remove)

aclass_bullet If true, give 15% extra protection against nailgun / sniper rifle (otherwise remove)

aclass_explosive If true, give 15% extra protection against explosions (otherwise remove)

aclass_shock If true, give 15% extra protection against emp/electrical attacks (otherwise remove)

aclass_fire If true, give 15% extra protection against fire and prevent burning (otherwise remove)

aclass_all If true, set all armour classes. (other wise, remove all armour classes)

If not forced (with a ~ prefix), these values are limited to player maximums. If + or - is prefixed, they're added or removed from existing values rather than set, e.g.

"give" "health=~500,armour=+50,score=+3,quad=10,haste=10,aclass_fire=1"

Would give a player 500 health (no matter their class max), 50 more armour (up to class max), 3 points, ten seconds of quad and haste (no matter what they had before), and fire-restant armour.

*If armortype is not specified and armour is given (i.e. the player gets more armour than they had before the command), it is automatically assumed that their armour type should be set to the maximum. If you want their armour type to remain unchanged, put in a key like "armortype=+0".

There are also a set of entity keys that affect the command:

affectteams Affect the named teams, (e.g. "red,blue") regardless of which team activated this entity

effectradius Affect only those players within the specified radius

holding Affect only those players holding these goalitems

notholding Affect only those players not holding these goalitems

clientstats Affect only those matching these clientstats

Note that the way the criteria work, it first checks affectteams and the affectteam/affectnonteam flags for players to affect, and them limits this based on the lineofsight/environment flags.

At some future time invincibility (i.e. pent), and holding (i.e. affect those holding a named goalitem) will probably be added in.

On a related note, entities can also give 'teamscore', which is simply a value added or removed from the activator's team (rather than the players personal 'frag' score).

3.5. Flags
There are a set of boolean flags that can be used to affect the entity's behavior in multiple areas, as follows. These can be categorised as criteria/effect/command flags:

hideactive command Cause the entity to be invisible while active (e.g. for refill goalinfos)

affectteam effect Cause the 'give' command to affect everyone on the activator's team.

affectnonteam effect Cause the 'give' command to affect everyone not on the activator's team.

dropoff effect 'give' values 'drop off' with distance (requires a 'range' key in the entity).

lineofsight effect only entities in line of sight will be affected.

environment effect only entities in the same environment will be affected.

shootable command Allow shooting the entity to be equivalent to touching it (only for func_doors).

reversecriteria criteria Causes the entity to only be triggered if the criteria are NOT met.

orclientstats criteria Causes the clientstats criteria to be OR instead of AND.

revealagent command If triggered, the activator will lose his disguise.

showcarry command On carryable entities, cause it to be shown above the player, as with CTF flags.

chargeable command Allow HE charging the entity to be equivalent to touching it.

rotating command Cause the model to rotate and bob like an item (only for goalinfo/goalitems).

noshrink command Goal does not grow or shrink when appearing/disappearing

nodrop command On carryable entities, stop the 'dropflag' command affecting it.

keepondeath command On carryable entities, don't drop on death.

usegauntlet command Entity must be gauntleted instead of touched.

allowdead command Allow dead players to be selected in target_cycle use.

allowsame command Allow same player to be selected in target_cycle use.

faildirection command Forcefield direction field applies to those failing the criteria.

allowsentrylock command Sentry is allowed to lock on through forcefields (bad idea :)

disguisecriteria criteria Criteria work on agent's apparent team/class rather than real.

3.6. Targets
The targeting system is what binds all the entities together into something more. When an entity changes state, it checks for <state>target and then attempts to set each named target to the specified state (default state if not specified is always 'active'). If forced by prefixing the state with a ~ character, criteria (and 'give'/'teamscore') are ignored, e.g.

"carriedtarget" "redalarms,escapedoors=~disabled"

Will cause the alarms to go to active (default if not specified), and forces all escape doors to be disabled, even if they're currently active (i.e. open).

To be targetable, entities must have either a targetname or a groupname key, the differences are as follows:

targetname Can only hold a single name, affects some entities - e.g. targetname will stop doors opening when players touch them, and teleporters will only look at targetnames for a destination, etc.

groupname Can hold any number of names, seperated by commas, and will respond to triggers on any of them - this allows much more complex entity interactions. It will not affect entities as having a targetname will.

Wherever possible, please use groupname instead of targetname - it's much more flexible and less prone to side-effects.

Please note that unforced triggers (i.e. without a ~) will pass the same activator on to the triggered entity (i.e. the player rather than the entity passing the trigger on). Also, the criteria are still check against the activator).

If you find yourself having problems with this, try setting g_mapentDebug to 1 at the console - be warned that you'll get a lot of junk out of this, and it may not help much.

See the Entity States section for more information.

3.7. Criteria
Criteria are checks on whether or not the activator can actually trigger this entity. The following fields apply, as well as some flags:

allowteams Only the specified teams (e.g. "red,blue") are allowed

allowclasses Only the specified classes (e.g. "recon,grenadier,agent") are allowed

holding Only players holding all the specified entities (e.g. "redkey1,redkey2") are allowed.

notholding Only players not holding all the specified entities (e.g. "redkey1,redkey2") are allowed.

clientstats Only players matching the specified clientstats (e.g. "health<50,gren1=0,armour<!") are allowed (see below).

checkstate The trigger is only valid if at least one of each named entity is in the specified state, e.g. "redalarms=inactive,redflag=carried"). If you want want to ensure all named entities are in a certain state, simply give each entity a unique group and check those.

disguisecriteria Criteria work on agent's apparent team/class rather than real.

The clientstats value is a list of evaluators build up like this: [keyword][evaluator][value], with the evaluator being '=', '<', '>', '<=' or '>='. The value is an integer or '!' (indicates activators' class maximum) and the keys can be the following: health, armor, ammo_shells, ammo_nails, ammo_rockets, ammo_cells, score, gren1, gren2, quad, regen, flight, battlesuit, invis, haste, ammo_medikit, ammo_charge, invuln, aqualung, gas, stun, flash, tranq, fire, skill.

If the criteria fail (after the reversecriteria flag is applied), the 'failtarget' key will be executed - note that there's no 'wait' on failures, so don't do anything processor intensive.

3.8. Map Info
Each map should be accompanied by a "mapinfo" file, which lives in the maps directory with it's map, e.g. maps/q3f_forts.bsp should be accompanied by a maps/q3f_forts.mapinfo file.

The mapinfo defines assorted properties describing the map, as well as overriding world-spawn attributes. The file format is something like:

mapinfo {
	map		"q3f_forts";					// BSP name
	longname	"Forts";					// Long name for map, general description of it
	type		"q3f";						// Game it is for (all q3f maps are marked with "q3f")
	gameindices	"1,2,3";					// Available gameindices
	atmosphere	"T=RAIN,B=5 10,C=0.5,G=0.5 2,BV=0,GV=0 100,W=1 2,D=300";	// Atmospheric effects

	gameindexDef 1 {						// Gameindex Definition
		longname	"Urban Warfare C&H";	// Long name for this gameindex

		// Map info (former .mpi)
		mapinfo		"Blablabladebladebla";

		// Class limits etc
		green_limit		"0";
		yellow_limit		"0";
		sniper_limit		"2";
		grenadier_limit		"3";
		red_soldier_limit	"5";
		blue_soldier_limit	"6";

		atmosphere	"T=SNOW";
	}

	gameindexDef 2 {
		longname	"Urban Warfare CTF";
		mapinfo		"Blablabladebladebla";
		green_limit	"0";
		yellow_limit	"0";
	}
}

Entries in gameIndexDef blocks override the default entries (which are not associated with any particular gameindex, and apply to all). Note that the gameindices field is required, and will default to "1" if not specified (however many gameIndexDef blocks there are).

map The name of the map it is associated with (not used, merely for completeness).

longname The "human" name of the map.

mapinfo A brief description of the map and how it is played.

type Should always be "q3f".

gameindices Should indicate all valid indices.

minplayers The minimum number of players recommended on the map.

maxplayers The maximum number of players recommended on the map.

Each map+gameindex combination is treated as a completely seperate map in voting lists. gameindexes should be a single digit from 1 to 9.

Any fields not mentioned here will override worldspawn keys instead (for example atmosphere).

3.9. Gameindices
Gameindices make it possible to have multiple scenarios in one map. Basically, all entities with a 'gameindex' key spawn only when the server has g_gameindex set to the same value.

For example, when an entity has "gameindex" "1,2", it will only spawn when g_gameindex (which defaults to 1) is 1 or 2 on the server.

Also, for the server to know which gameindices are allowed for this map, there is a new key for the .arena file. This key is called 'gameindices' and has as value an array of the allowed gameindices. For example "1,2,3", which results in g_gameindex 1, 2 and 3 being valid for this map. If it has a different value during the loading of the map, it defaults to 1.

3.10. Custom Infoparms
Q3F uses the -custinfoparms parameter of q3map 1.1-TA-beta and newer being distributed with GtkRadiant to extend Quake3's shader language.

Current custom infoparms:

particleclip Particles collide with this surface.

forcefield Used in combination with the func_forcefield entity to create forcefields.

footprints If a client walks over a shader with the footprints parameter set, he leaves a trail of footprints.

stone Stone footstep and ricochet sounds.

wood Wood footstep and ricochet sounds.

seethrough Translucent surface a sentry can track through even if it's solid.

To use these parameters, you need to add a 'custinfoparms.txt' file to your scripts directory (where your shaders live) and execute the bsp stage of the compile process with the additional -custinfoparms command line parameter.

The contents of the textfile used with Q3F:

// Custom Surfaceparms file

// Custom Contentsflags
{
	particleclip 0x2000
	forcefield 0x4000
}
// Custom Surfaceflags
{
	footprints 0x80000
	stone 0x100000
	wood 0x200000
	seethrough 0x400000
}

4. Entities.

4.1. func_*.

4.1.1. func_commandpoint
This is currently the most complex entity in the game. For those unfamiliar with the basic concept, a command point is a point you touch (or otherwise activate) and then attempt to keep (i.e. kill any enemies attempting to touch it).

The command point can perform a few actions:

If given a model (see func_goalinfo) it is touchable, otherwise can only be triggred by another entity (e.g. a button).
It will return to inactive immediately on activation (so enemies can get back at it without waiting).
If 'teamset' is set, all named entities will have their 'allowteams' criteria key set to the activator's team.
If 'nonteamset' is set, all named entities will have their 'allowteams' criteria key set to all teams but the activator's team.>
If 'overrideteams' is set, all named entities will have their 'allowteams' criteria key set to the teams listed here once the command point is activated. e.g. "overrideteams" "red,green"
Every 'wait' seconds it will execute 'pulsegive', 'pulseteamscore', and 'pulsetarget' (like the normal varieties of each). The first pulse is after 'wait' seconds, not immediately on trigger.
If 'pulsecount' is specified, it will pulse this many times and then execute 'expiretarget' and become free to all takers again. All teamset/nonteamset entities will have their 'allowteams' field cleared altogether (so anyone can trigger these entities unless expiretarget disabled them.)

Did that make sense? No? Well, read it again a few times and see if it becomes clearer. This entity has the problem that more complexity means less usefulness, simply because less people understand how to use it... the current status is a tradeoff between function and ease-of-use, and it's unlikely to get much simpler.

See the command point example for more information.

4.1.2. func_damage
This brush entity vanishes when 'damaged', either from being attacked or activated (which removes a set amount of health) until it's health disappears. The entity can also have a 'regen' speed, measured in health regained per second. After being damaged, it will be 'restored' after a set time. Only players matching the usual criteria can damage it. When damaged, the ent will also trigger itself invisible.

The ent will open and close area portals properly.

Fields are:

damage_<team>_message/sound/dict Played when damaged.

damagetarget Executed when damaged.

health_<team>_message/sound/dict Played when full health is regenerated.

healthtarget Executed when full health is regenerated.

restore_<team>_message/sound/dict Played when ent is restored after damage.

restoretarget Executed when ent is restored after damage.

regen Health regenerated per second (default 1).

restore Seconds before damaged ent is restored (default 30).

4.1.3. func_door_rotating
Just like a door, except you need an origin brush (a seperate brush as part of the door model, with all surfaces common/origin) to indicate the pivot point.

The lip and height fields are gone, instead you have an angles field, containing three numbers: pitch, yaw and roll. The default is "0 90 0", which means rotate 90 degrees (a normal door, in other words).

Speed means 'degrees per second'.

4.1.4. func_explosion
This ent simply generates an exposion effect when activated. You supply the impact vibration level, as well as an optional model / shader. If you want the explosion to do _real_ damage, just specify something like:

"give" "health=-100"
"flags" "lineofsight,dropoff"
"effectradius" "100"

Default wait time on this ent is 1 second.

Fields are:

radius Radius of the explosion.

impact Used for the impact vibration level.

light Ammount of light the entity emits.

color Lightcolor the entity emits.

wait The wait on the entity, defaults to 1.

model Model to display when exploding.

shader Shader to display when exploding.

4.1.5. func_forcefield
Forcefields are conditional walls, which are only solid to players/weapons failing criteria. The criteria can be anything that would apply to a trigger (team/class/entity states/holding/notholding/clientstats, etc.), as well as directional barriers.

The forcefield should be created as a func_forcefield entity, with all faces of brush marked with:

	surfaceparm nonsolid
	surfaceparm forcefield

(Where forcefield is specified as forcefield 0x4000 in the custinfoparms.txt file.)

The entity can then take the following keys:

<q3f criteria keys> Normal criteria keys used to define who the field will allow through.

angles Specified as PITCH YAW, fields with this key will only allow players through in the specified direction (in fact, in a hemisphere with the direction in the middle).

flags See below for modifier flags.

Behaviour modifier flags are:

faildirection The angles key applies to those who _fail_ the criteria, so that forcefields can be made to allow, e.g. one team free access, and others one-way access.

allowsentrylock Normally, sentries cannot track targets through forcefields, but mappers may want to disable this to allow, e.g. "defence turrets" where sentries can fire with impunity until a forcefield generator is destroyed.

The forcefield is not suited for normal state setting - states should always be forced to ensure they go into the desired state, although it's not required.

Invisible: Forcefields have no effect, all players can pass through.
Disabled: Forcefields act as normal, but fail to trigger.
Inactive: Forcefields act as normal, and trigger when someone passing the criteria passes through.
Active: See above, drops back to inactive after a default of 2 seconds).

Notes:

- Weapons can travel through forcefields if their owners can, and in the same directions.
- Only team/class/direction prediction is possible client-side, any other criteria will cause the client to mispredict (and a 'judder' effect will occur) - clients cannot finesse this to pass through the field.
- Pulse and Flash grenades are still effective through forcefields.
- Players within a forcefield who fail the criteria will be trapped as long as the forcefield is present.
- Players travelling through an 'upward' forcefield will rise up until they're standing on the surface, or cannot rise any further.
- Forcefields can be used to support player's weight, and form, e.g. one-team bridges.

4.1.6. func_goalinfo
The func_goalinfo is the basic 'point entity' of Q3F. It will activate when a player enters it's bounding box (specified as mins and maxs for the coordinages (x y z) of two diagonally opposing corners). The bounding box defaults to "-15 -15 -15" "15 15 15".

It will 'wait' in the active state before going back to inactive (if a wait key is given). If a 'model' key is specified, it will display that model, rotated 'angle' degrees.

Check the flags for more things you can do with it.

4.1.7. func_goalitem
The func_goalitem operates much like the func_goalinfo, with the notable exception that you can pick up and carry it. This entity will go to the carried state when touched rather than the active. When active, it's lying around, and when the 'wait' time is up, it will become inactive again (returns to base).

Additional keys of interest might be:

bouncefactor The amount of 'bounce' the goalitem has, as a value between 0 and 1.

sparkle Generate smoke around the holder of the goalitem, in the specified colour.

sparkleshader The shader for the sparkles. Defaults to 'hasteSmokePuff'.

speedscale Alter the speed of the holder of the goalitem, as a value between 0 and 1 (or higher, if you want to make them faster).

usegive If useitem is pressed when the goalitem is carried, apply this give-string to the carrier.

usetarget If useitem is pressed when the goalitem is carried, this target key is executed.

use_<team>_<broadcast> If useitem is pressed when the goalitem is carried, this message string is executed ( see 'messages')

Flags of interest might include:

showcarry Show goalitem above holder.

nodrop Prevent them from getting rid of it with the 'dropflag' command.

keepondeath Don't drop when dead - still gets dropped if they disconnect.

4.1.8. func_hud
The hud is a largely untested attempt at a flexible HUD entity system. Essentially, HUD entities can be display in a slot (in two columns of five, with 1/6 at the top and 5/10 at the bottom).

They will only be displayed to players who match the 'holding' criteria (note that the usual criteria will not be honoured, although they may make it difficult to change the HUD status unless you force them).

If teamset/nonteamset by a func_commandpoint the entity will only be visible to members of those team(s). Shaders using "rgbgen entity" in their definition should get team colours (or light grey). If the 'color' key is specified, the entity will set that instead, allowing you to have multiple entities with the same model but a different colour.

The HUD itself will display <state>_model, e.g.

"inactive_model" "models/flags/r_flag.md3"

Now also understands <state>_shader fields, which display a (flat) shader instead of a model. The <state>_model will be used instead if both are present. To use in a CTF situation, you might say:

inactive_shader hud/redflagbase

active_shader hud/redflagdropped

carried_shader hud/redflagcarried

And then the goalitem it is linked to would say:

inactivetarget redflaghud=~inactive

activetarget redflaghud=~active

carriedtarget redflaghud=~carried

4.1.9. func_nobuild
This entity can be used to prevent players building objects. Within it's area, it will stop players of any teams specified in allowteams (default all teams) from building type buildings (default is "autosentry,charge,supplystation"). This entity cannot be targeted or disabled.

4.1.10. func_train and path_corner
The func_train and path_corner entities have been extended from their standard Quake3 implementation. When a func_train reaches a path_corner, it first checks if there is a next path_corner is available. This means that the next path_corner exists, and is in state active or inactive. Also, when it finds multiple valid targets, it randomly chooses between then. With this you can, say, let a train switch between track A and B using a switch.

Next to that, the path_corner entity has now an "angles" key. This key has as values "PITCH YAW ROLL" where pitch, yaw and roll are three integers. The func_train entity interpolates between the angles of the path_corner entities it's moving between.

Also added is the "dmg" key which defaults to 2. This is the damage inflicted to an object that is crushed by a train (per frame). Set to something high to instagib a player that is so stupid to fall between a func_train and a wall. Next to that, opposed to the standard Q3 implementation of the func_train, the Q3F version has proper collision with entities, and will push them forward till they are crushed. (Goalitems will return to their spawn position, in other words, go back to their inactive state.)

4.1.11. func_wall
Basically this is the most stupid brush entity you can imagine. When it's in state inactive or active it is visible and solid, when it's in invisible or disabled it's invisible and nonsolid. The entity works properly with all state triggers (like an info_notnull) and makes proper use of areaportals.

4.2. target_*.

4.2.1. target_cycle
When activated, this entity will cycle through the player list looking for players which match it's criteria. If it finds one, it will execute cycletarget as the player found. It it fails, it will execute cyclefailtarget as the original activator.

The criteria it checks for are:

cycleallowteams Only teams in this list are allowed.

cycleallowclasses Only classes in this list are allowed.

cycleholding Only players holding these goalitems are allowed.

cyclenotholding Only players not holding these goalitems are allowed.

cycleclientstats Only players matching these clientstats are allowed.

In addition to these, there are two flags that modify the behavior: allowdead allows currently dead players to be the cycle selection, and allowsame allows the original activator to be chosen (if nobody else matches it first). Note that it is always possible for this ent to fail to find a target - even if you have criteria that would match the original activator, they might have disconnected (e.g. imagine a goalitem that activates a target_cycle when dropped).

4.2.2. target_location
This entity has been changed from the default Q3A version. Now, it only understands the 'message' key, but you have an unlimited number of them rather than the 64-location limit of before. If you want to embed colours in them, using the ^* string will 'cancel' the colour to the default for the message (which can be different colours depending on the cirumcstances it's displayed in), e.g. "west ^1red^* water tunnel".

Incidentallly, performing a "\dumploc <area name>" at the console will dump a target_location to the <mapname>.loc file in a format suitable to be copied into a .map file.

4.2.3. target_multiport
Works much like target_respawn, except attempts to teleport players to any teleport destinations or respawns specified by the target key. Will attempt to avoid telefragging players.

4.2.4. target_respawn
When activated, all players matching the affect criteria (identical to those used for give commands) will be respawned. No points will be deducted, no backpack will be dropped, all goalitems not marked 'keepondeath' will be dropped.

4.2.5. target_semitrigger
When activated, it will trigger 'count' (or if 'count2' is specified, a random number between 'count' and 'count2' of the ents specified in semitrigger, which follows the usual format.

It will continue triggering until it has successfully (i.e. the trigger didn't fail because the state was already identical or criteria didn't match) triggered the specified number of ents at random, or run out of ents to trigger.

It will trigger itself back to inactive immediately.

4.3. info_*.

4.3.1. info_notnull
This entity is being used for extended trigger relaying and similar (which it really shouldn't be, we should be using a new entity class for the job). The only change here is that it can be given light/color values for dynamic lighting.

4.3.2. info_player_start
This entity (and its variants) is used much as before, except that that players can only spawn on it if they pass the 'allowteams' and 'allowclasses' critera. When a player spawns on it, it will trigger active as normal.

The 'wait' key defaults to 0.1 seconds on this entity. Be very careful with this! Spawnpoints only honour the wait key if they have extended mapdata (e.g. a groupname, or an allowteams field). If you set the wait time up too long, you may run out of useable spawnpoints when the action hots up (and, needless to say, the game crashes if this happens).

The spawn points are checked to see what teams are valid - if there are no "team locked" spawnpoints, then all four teams will be playable.

4.4. misc_*.

4.4.1. misc_beam
This entity draws a beam, straight or waving depending on settings, between 'target' and target2'. These can be all kind of entities, such as simple info_notnull ents but also func_train or func_bobbing ents (Use an origin brush in those, else the beam will target to (0,0,0).).

All fields are:

target Start entity of beam. If this key is not used, there will be a beam going out from target2 into random directions.

target2 End entity of beam. If this key is not used, the misc_beam entity itself will be used.

dmg When set, lets the beam damage any hurtable objects that touch it. This also sets the state of the beam to active.

shader Points to a shader to be used for the beam. Defaults to 'lightningBolt'.

color Color of the beam, if the shader is colourable by code.

segments Number of segments the beam exists off (0 is a beam like the shaft).

scale Width of the beam (works with segments >= 1).

maxamp Maximum amplitude of the beam (works with segments >= 1).

wavescale Sets the speed at which the beam waves, > 1 is faster, < 1 is slower (works with segments >= 1).

Also this ent has some spawnflags, controlling the type of beam (note that these use the key 'spawnflags' and work as a bitfield):

1 (BEAM_STRAIGHT) Straight beam, shaft style.

2 (BEAM_WAVE) Beam in a 2d wave along the beams direction.

4 (BEAM_WAVE_3D) Beam in a 3d wave along the beams direction.

8 (BEAM_TILESHADER) Tile the shader along the beam.

4.4.2. misc_flare
This entity draws a light- or lensflare, optionally blinding the screen of the person who looks at it.

All fields are:

light Flare intensity, equiv to light. Defaults to 300.

_color Flare colo/r, equiv to light. Defaults to 1.0 1.0 1.0.

shader Path to shader. Defaults to "flareshader".

radius Flare radius. Defaults to 1.0, about 64x64 pixels @ 640x480.

rotation Initial rotation of light flare. Defaults to 0.

Also this ent has some spawnflags, controlling the type of flare (note that these use the key 'spawnflags' and work as a bitfield):

1 (LENSFLARE) Makes it a lensflare.

2 (LENSBLIND) Makes it blinds the screen.

2 (LENSFLAREBLIND) Makes it a lensflare that blinds the screen.

4.4.3. misc_onkill
Whenever a player is killed, all misc_onkill ents are triggered. For the attacker, they check allowteams, allowclasses, holding, notholding, clientstats, and checkstate. For the victim, they check victimallowteams, victimallowclasses, victimholding, victimnotholding and victimclientstats.

If the criteria pass, attacker_<team>_message/sound/dict, victim_<team>_message/sound/dict, attackertarget and victimtarget are executed, using the two players involved. Suicides / world kills have the victim as the attacker also.

Next to this, the ent has an optional "watch" and a "watchrange" key. Watch targets an entity, range sets a range around this. If both ar set, the misc_onkill will only trigger when the attacker is within a range of watchrange around the watch entity. Some spawnflags also have affect this behaviour:

1 (CANSEEVICTIM) Only trigger if watch has the victim in line of sight.

2 (CANSEEATTACKER) Only trigger if watch has the attacker in line of sight.

4 (WATCHRANGEFROMVICTIM) Check watchrange against victim instead of attacker.

4.4.4. misc_onprotect
Whenever a player is killed, all misc_onprotect ents are triggered. This can be used, e.g. for "protect bonuses", by setting: "victimholding enemyflag", "attackertarget flagprotectbonus".

Note this isn't how the CTF protection system works (it bases it on fragging people who have actually damaged the flag carrier).

4.4.5. misc_sunflare
This entity draws a sunflare, optionally blinding the screen of the person who looks at it. It has a special feature over the 'misc_flare' entity, namely that it can be put in a skybox and still renders properly.

All fields are:

Also this ent has some spawnflags, controlling the type of flare (note that these use the key 'spawnflags' and work as a bitfield):

1 (LENSFLARE) Makes it a lensflare.

2 (LENSBLIND) Makes it blinds the screen.

4 (LENSFLAREBLIND) Makes it a lensflare that blinds the screen.

4.5. path_*.

4.5.1. path_spline
This entity is used in combination with the Chilli plugin for GtkRadiant to make bezier spline paths.

The fields are:

targetname Name of this entity, used for targetting.

target Target entity, this is the next entity in the spline path.

pathname The name of the spline path this entity is a member off. Chilli and Q3F support up to 16 different paths. (Remark: the path used for the flyby camera ALWAYS needs to have the name 'flyby'.)

origin Origin of the entity.

dir Direction of outgoing path. This is a vector key, meaning the value is like "0.2 -0.3 0.6" where the numbers are respectively X Y and Z directions.

speed In Q3F an entity can follow a spline, from this path_spline entity till the next one in the path, the entity that follows the path will have a speed of 'speed' units/second. Also this is used to control the shape of the path (Try this in GtkRadiant to see how different numbers affect the path).

roll In Q3F an entity can follow a spline, at this path_spline entity it will have a roll of 'roll' degrees. Positive roll is clockwise, negative is counter clockwise. The entity that follows the path interpolates it's roll between path_spline entities.

The path_spline that has spawnflag 1 will be the first entity on that path. At least one of the path_spline entities needs this spawnflag for the path to be valid.

When you've created a path in GtkRadiant, you can use the option "Scan and Go..." in Chilli to see the path in radiant itself. If the statuswindow reports checksum errors, one of the fields above (all path_spline entities in a path must have all of the keys) is missing, the path isn't closed, or an other error has emerged so a path cannot be rendered properly.

To use the paths in a map, use the "Export SPD..." option in Chilli to export a <mapname>.spd file, which can be read by Q3F to use the paths in the code. The SPD (SPline Data) file will be exported to the same dir as your .map file exists in. For Q3F to be able to read it, it must exist in the same directory as the <mapname>.bsp file is in.

4.6. panel_*

4.6.1. Panel entities
Panels are simply 640x480 virtual screens that get mapped onto the world somewhere.

To use, simply create a panel_* near a wall, and it will be automatically mapped onto it.

Shared panel keys include:

backshader the shader drawn behind the panel itself

frontshader the shader drawn on top of the panel

transition the 'transition' between shown and notshown (currently, only 'fade' or 'none'). Back and frontshaders are always drawn

width the width of the panel in world units (default 100)

width the height of the panel in world units (default 75)

distance the distance the transition kicks in (default is automatically calculated)

angle the angle at which the panel is rotated on the surface

4.6.2. panel_location
Displays the contents of the closest Location.

Extra fields are:

xborder horizontal border offsets in panel coords (640x480)

yborder horizontal border offsets in panel coords (640x480)

color the colour of the text drawn on the panel

4.6.3. panel_message
Displays the specified message, based on current state.

Extra fields are:

<state>message the (centered, coloured) message to display for the current state

<state>colour the colour for the message (overrides internal colour codes)

All states except invisible can be used (since invisible will not be shown to the client at all). If no message is specified for a state, the back and fore shaders will be shown without any text.

4.6.4. panel_name
Simply displays the player's name, although currently it displays a scrolling string "Peter Piper Picked a peck of pickled peppers", etc. (for debug purposes).

4.6.5. panel_radar
Displays all players matching criteria on a 'radar sweep' board. The sweep graphic should be displayed on the foreshader, with a time base of zero (to ensure that the sweep is in sync with the dots appearing. The sweep is non-negotiable, to save on bandwidth :)

Extra fields are:

speed Number of sweeps per second (default 0.5)

colour The colour of the dots, or team colour if not specified.

range The range the sweep is effective to.

attenuation A float ranging from 0 to 1 indicating how strong the signal is, also affecting detection of non-moving entities (the default 1 means perfect detection, 0 means no detection of non-moving entities). A negative value indicates that walls increase attenuation.

flags 'showheight' indicates that height is shown on the radar.

4.6.6. panel_scoresummary
Displays the current team scores, and highest scoring player in team. Needs a graphical makeover :)

4.6.7. panel_timer
Displays an animated digital timer. Types are currently numeric, due to laziness on the part of the author :)

Available fields are:

color Colour of the timer text.

type The type of timer.

The types available are:
  1 - Elapsed time, as "MM:SS".
  2 - Elapsed time, as "MM:SS.mmm".
  3 - Remaining time, as "MM:SS".
  4 - Remaining time, as "MM:SS.mmmm".
  5 - 12 hour clock, as "HH:MM:SS"
  6 - 24 hour clock, as "HH:MM:SS"
  7 - 12 hour clock, as "HH:MM:SS AM"

4.7. Other Entities

4.7.1. Worldspawn (classlimits and atmospheric effects)
The worldspawn entity has been extended with some extra fields. The following table will make everything regarding it pretty easy:

<class>_limit Maximum of players of this class (overridden by team specific value)

<class>_name Name of this class (overridden by team specific value)

<colour>_name Name of the team (default: "<colour> Team")

<colour>_limit Maximum of players on this team (default: -1 (unlimited))

<colour>_maxlives Maximum lives per player on this team (default: -1 (unlimited))

<colour>_allies Allied teams (e.g. team_red_allies = "blue,yellow")
REMARK: if you have this field in the worldspawn, but NOT have the name of the <colour> team in this field, a team will be able to damage it's own members. This means, if you have this flag with NO entries, you can deal damage to EVERYONE.

<colour>_<class>_limit Maximum of players of this class on this team (default: -1 (unlimited))

<colour>_<class>_name Name of this class on this team (default: <class>)

atmosphere Atmospheric effects to use.

Note that the team_ prefix on team-specific playerlimits has been removed.

The "gravity" field now works properly for all ents (not just players).

The supported atmospheric effects are 'rain' and 'snow'. The format string is something like:

T=RAIN,B=5 10,C=0.5,G=0.5 2,BV=0,GV=0 100,W=1 2,D=300

The type must always come first (T=RAIN). The fields are as follows:

Key Default Description

T RAIN Type of effect (supports 'RAIN' or 'SNOW')

B 5 10 Base times (X seconds, or between X and Y seconds)

C 1 1 Time to move from base to gust (X seconds, or between X and Y seconds)

G 0 2 Gust times (X seconds, or between X and Y seconds)

BV 0 100 Base vector (x and y units/sec).

GV 0 100 Gust vector (x and y units/sec).

W 1 2 Weight of drops (X, or from X to Y depending on base/gust position)

S 1 1 Water and Splash shader. This are two boolean values, the first enables impactshaders on water (0 = off, 1 = on), the second on land.

D 300 300 Number of drops (X, or from X to Y depending on base/gust position)

4.7.2. CTF compatability entities
While their use is not recommended, you can use standard CTF entities and they will be 'translated' into Q3F equivalents. Standard CTF maps will not play quite as they do on normal CTF, but they will be playable.

	invisible	disabled	inactive	active	carried
invisible		*	*
disabled	*		*
inactive	*	*		*	*
active			*		*
carried			*	*

<state>_message	Send a message to the activator.
<state>_team_message	Send a message to the activator's teammates.
<state>_nonteam_message	Send a message to all players not on the activator's team.
<state>_all_message	Send a message to all players.
<state>_sound	Play a sound to the activator (currently, plays globally as though ~ was specified).
<state>_team_sound	Play a sound to the activator's teammates (currently, plays globally as though ~ was specified).
<state>_nonteam_sound	Play a sound to all players not on the activator's team (currently, plays globally as though ~ was specified).
<state>_all_sound	Play a sound to all players.*
<state>_dict	Parse and play sound to the activator.*
<state>_team_dict	Parse and play a sound to the activator's teammates.*
<state>_nonteam_dict	Parse and play a sound to all players not on the activator's team.*
<state>_all_dict	Parse and play a sound to all players.*

%H	Health
%A	Armour
%L	Location (returns 'unknown location' if unable to work it out)
%D	Location of last death.
%R	Last reported location (i.e. identical to last %L)
%T	Team name (e.g. "Red Team", "Blue Team" etc.)
%C	Team colour (e.g. red, blue etc.)
%G	Disguise (returns 'not disguised' if not wearing a disguise)
%N	Name (player name / entity groupname (or one of them)
%E	State (e.g. "active", "carried" etc.)
%S	Class (e.g. "soldier", "medic" etc.)

health	Health
armor	Armor
damage	Deal damage to the target
ammo_shells	Shells
ammo_bullets	Bullets
ammo_rockets	Rockets
ammo_cells	Cells
ammo_medikit	Medikit ammo
ammo_charge	HE Charge
score	Player score (not teamscore)
gren1	Grenade type 1
gren2	Grenade type 2
quad	Seconds of quad damage
regen	Seconds of regen
flight	Seconds of flight
battlesuit	Seconds of battlesuit
invis	Seconds of invisibility (shimmer invis, not agent invis)
haste	Seconds of haste
invuln	Seconds of invulnerability
aqualung	Seconds of aqualung
ceasefire	Seconds a player is unable to shoot
gas	Seconds of gas
stun	Seconds of stun
flash	Seconds of flash
tranq	Seconds of tranq
fire	Amount of fire counters, every counter does a certain amount of burn damage every few seconds
armortype	Armour type (as a number from 0-100). This is the amount of damage the armour saves you from*
aclass_shell	If true, give 15% extra protection against shells (otherwise remove)
aclass_bullet	If true, give 15% extra protection against nailgun / sniper rifle (otherwise remove)
aclass_explosive	If true, give 15% extra protection against explosions (otherwise remove)
aclass_shock	If true, give 15% extra protection against emp/electrical attacks (otherwise remove)
aclass_fire	If true, give 15% extra protection against fire and prevent burning (otherwise remove)
aclass_all	If true, set all armour classes. (other wise, remove all armour classes)

affectteams	Affect the named teams, (e.g. "red,blue") regardless of which team activated this entity
effectradius	Affect only those players within the specified radius
holding	Affect only those players holding these goalitems
notholding	Affect only those players not holding these goalitems
clientstats	Affect only those matching these clientstats

hideactive	command	Cause the entity to be invisible while active (e.g. for refill goalinfos)
affectteam	effect	Cause the 'give' command to affect everyone on the activator's team.
affectnonteam	effect	Cause the 'give' command to affect everyone not on the activator's team.
dropoff	effect	'give' values 'drop off' with distance (requires a 'range' key in the entity).
lineofsight	effect	only entities in line of sight will be affected.
environment	effect	only entities in the same environment will be affected.
shootable	command	Allow shooting the entity to be equivalent to touching it (only for func_doors).
reversecriteria	criteria	Causes the entity to only be triggered if the criteria are NOT met.
orclientstats	criteria	Causes the clientstats criteria to be OR instead of AND.
revealagent	command	If triggered, the activator will lose his disguise.
showcarry	command	On carryable entities, cause it to be shown above the player, as with CTF flags.
chargeable	command	Allow HE charging the entity to be equivalent to touching it.
rotating	command	Cause the model to rotate and bob like an item (only for goalinfo/goalitems).
noshrink	command	Goal does not grow or shrink when appearing/disappearing
nodrop	command	On carryable entities, stop the 'dropflag' command affecting it.
keepondeath	command	On carryable entities, don't drop on death.
usegauntlet	command	Entity must be gauntleted instead of touched.
allowdead	command	Allow dead players to be selected in target_cycle use.
allowsame	command	Allow same player to be selected in target_cycle use.
faildirection	command	Forcefield direction field applies to those failing the criteria.
allowsentrylock	command	Sentry is allowed to lock on through forcefields (bad idea :)
disguisecriteria	criteria	Criteria work on agent's apparent team/class rather than real.

targetname	Can only hold a single name, affects some entities - e.g. targetname will stop doors opening when players touch them, and teleporters will only look at targetnames for a destination, etc.
groupname	Can hold any number of names, seperated by commas, and will respond to triggers on any of them - this allows much more complex entity interactions. It will not affect entities as having a targetname will.

allowteams	Only the specified teams (e.g. "red,blue") are allowed
allowclasses	Only the specified classes (e.g. "recon,grenadier,agent") are allowed
holding	Only players holding all the specified entities (e.g. "redkey1,redkey2") are allowed.
notholding	Only players not holding all the specified entities (e.g. "redkey1,redkey2") are allowed.
clientstats	Only players matching the specified clientstats (e.g. "health<50,gren1=0,armour<!") are allowed (see below).
checkstate	The trigger is only valid if at least one of each named entity is in the specified state, e.g. "redalarms=inactive,redflag=carried"). If you want want to ensure all named entities are in a certain state, simply give each entity a unique group and check those.
disguisecriteria	Criteria work on agent's apparent team/class rather than real.

map	The name of the map it is associated with (not used, merely for completeness).
longname	The "human" name of the map.
mapinfo	A brief description of the map and how it is played.
type	Should always be "q3f".
gameindices	Should indicate all valid indices.
minplayers	The minimum number of players recommended on the map.
maxplayers	The maximum number of players recommended on the map.

particleclip	Particles collide with this surface.
forcefield	Used in combination with the func_forcefield entity to create forcefields.
footprints	If a client walks over a shader with the footprints parameter set, he leaves a trail of footprints.
stone	Stone footstep and ricochet sounds.
wood	Wood footstep and ricochet sounds.
seethrough	Translucent surface a sentry can track through even if it's solid.

damage_<team>_message/sound/dict	Played when damaged.
damagetarget	Executed when damaged.
health_<team>_message/sound/dict	Played when full health is regenerated.
healthtarget	Executed when full health is regenerated.
restore_<team>_message/sound/dict	Played when ent is restored after damage.
restoretarget	Executed when ent is restored after damage.
regen	Health regenerated per second (default 1).
restore	Seconds before damaged ent is restored (default 30).

radius	Radius of the explosion.
impact	Used for the impact vibration level.
light	Ammount of light the entity emits.
color	Lightcolor the entity emits.
wait	The wait on the entity, defaults to 1.
model	Model to display when exploding.
shader	Shader to display when exploding.

<q3f criteria keys>	Normal criteria keys used to define who the field will allow through.
angles	Specified as PITCH YAW, fields with this key will only allow players through in the specified direction (in fact, in a hemisphere with the direction in the middle).
flags	See below for modifier flags.

faildirection	The angles key applies to those who _fail_ the criteria, so that forcefields can be made to allow, e.g. one team free access, and others one-way access.
allowsentrylock	Normally, sentries cannot track targets through forcefields, but mappers may want to disable this to allow, e.g. "defence turrets" where sentries can fire with impunity until a forcefield generator is destroyed.

bouncefactor	The amount of 'bounce' the goalitem has, as a value between 0 and 1.
sparkle	Generate smoke around the holder of the goalitem, in the specified colour.
sparkleshader	The shader for the sparkles. Defaults to 'hasteSmokePuff'.
speedscale	Alter the speed of the holder of the goalitem, as a value between 0 and 1 (or higher, if you want to make them faster).
usegive	If useitem is pressed when the goalitem is carried, apply this give-string to the carrier.
usetarget	If useitem is pressed when the goalitem is carried, this target key is executed.
use_<team>_<broadcast>	If useitem is pressed when the goalitem is carried, this message string is executed ( see 'messages')

showcarry	Show goalitem above holder.
nodrop	Prevent them from getting rid of it with the 'dropflag' command.
keepondeath	Don't drop when dead - still gets dropped if they disconnect.

inactive_shader	hud/redflagbase
active_shader	hud/redflagdropped
carried_shader	hud/redflagcarried

inactivetarget	redflaghud=~inactive
activetarget	redflaghud=~active
carriedtarget	redflaghud=~carried

cycleallowteams	Only teams in this list are allowed.
cycleallowclasses	Only classes in this list are allowed.
cycleholding	Only players holding these goalitems are allowed.
cyclenotholding	Only players not holding these goalitems are allowed.
cycleclientstats	Only players matching these clientstats are allowed.

target	Start entity of beam. If this key is not used, there will be a beam going out from target2 into random directions.
target2	End entity of beam. If this key is not used, the misc_beam entity itself will be used.
dmg	When set, lets the beam damage any hurtable objects that touch it. This also sets the state of the beam to active.
shader	Points to a shader to be used for the beam. Defaults to 'lightningBolt'.
color	Color of the beam, if the shader is colourable by code.
segments	Number of segments the beam exists off (0 is a beam like the shaft).
scale	Width of the beam (works with segments >= 1).
maxamp	Maximum amplitude of the beam (works with segments >= 1).
wavescale	Sets the speed at which the beam waves, > 1 is faster, < 1 is slower (works with segments >= 1).

1 (BEAM_STRAIGHT)	Straight beam, shaft style.
2 (BEAM_WAVE)	Beam in a 2d wave along the beams direction.
4 (BEAM_WAVE_3D)	Beam in a 3d wave along the beams direction.
8 (BEAM_TILESHADER)	Tile the shader along the beam.

light	Flare intensity, equiv to light. Defaults to 300.
_color	Flare colo/r, equiv to light. Defaults to 1.0 1.0 1.0.
shader	Path to shader. Defaults to "flareshader".
radius	Flare radius. Defaults to 1.0, about 64x64 pixels @ 640x480.
rotation	Initial rotation of light flare. Defaults to 0.

1 (LENSFLARE)	Makes it a lensflare.
2 (LENSBLIND)	Makes it blinds the screen.
2 (LENSFLAREBLIND)	Makes it a lensflare that blinds the screen.

1 (CANSEEVICTIM)	Only trigger if watch has the victim in line of sight.
2 (CANSEEATTACKER)	Only trigger if watch has the attacker in line of sight.
4 (WATCHRANGEFROMVICTIM)	Check watchrange against victim instead of attacker.

targetname	Name of this entity, used for targetting.
target	Target entity, this is the next entity in the spline path.
pathname	The name of the spline path this entity is a member off. Chilli and Q3F support up to 16 different paths. (Remark: the path used for the flyby camera ALWAYS needs to have the name 'flyby'.)
origin	Origin of the entity.
dir	Direction of outgoing path. This is a vector key, meaning the value is like "0.2 -0.3 0.6" where the numbers are respectively X Y and Z directions.
speed	In Q3F an entity can follow a spline, from this path_spline entity till the next one in the path, the entity that follows the path will have a speed of 'speed' units/second. Also this is used to control the shape of the path (Try this in GtkRadiant to see how different numbers affect the path).
roll	In Q3F an entity can follow a spline, at this path_spline entity it will have a roll of 'roll' degrees. Positive roll is clockwise, negative is counter clockwise. The entity that follows the path interpolates it's roll between path_spline entities.

backshader	the shader drawn behind the panel itself
frontshader	the shader drawn on top of the panel
transition	the 'transition' between shown and notshown (currently, only 'fade' or 'none'). Back and frontshaders are always drawn
width	the width of the panel in world units (default 100)
width	the height of the panel in world units (default 75)
distance	the distance the transition kicks in (default is automatically calculated)
angle	the angle at which the panel is rotated on the surface

xborder	horizontal border offsets in panel coords (640x480)
yborder	horizontal border offsets in panel coords (640x480)
color	the colour of the text drawn on the panel

<state>message	the (centered, coloured) message to display for the current state
<state>colour	the colour for the message (overrides internal colour codes)

speed	Number of sweeps per second (default 0.5)
colour	The colour of the dots, or team colour if not specified.
range	The range the sweep is effective to.
attenuation	A float ranging from 0 to 1 indicating how strong the signal is, also affecting detection of non-moving entities (the default 1 means perfect detection, 0 means no detection of non-moving entities). A negative value indicates that walls increase attenuation.
flags	'showheight' indicates that height is shown on the radar.

<class>_limit	Maximum of players of this class (overridden by team specific value)
<class>_name	Name of this class (overridden by team specific value)
<colour>_name	Name of the team (default: "<colour> Team")
<colour>_limit	Maximum of players on this team (default: -1 (unlimited))
<colour>_maxlives	Maximum lives per player on this team (default: -1 (unlimited))
<colour>_allies	Allied teams (e.g. team_red_allies = "blue,yellow") REMARK: if you have this field in the worldspawn, but NOT have the name of the <colour> team in this field, a team will be able to damage it's own members. This means, if you have this flag with NO entries, you can deal damage to EVERYONE.
<colour>_<class>_limit	Maximum of players of this class on this team (default: -1 (unlimited))
<colour>_<class>_name	Name of this class on this team (default: <class>)
atmosphere	Atmospheric effects to use.