EVOLUTION-MANAGER

Edit File: qstatdoc.html

<html>

<head>
<title>QStat 2.10 documentation</title>
</head>

<dl>
<H3><dt>NAME</H3>
<dd>
	qstat - Get statistics from on-line game servers

<H3><dt>SYNOPSIS</H3>
<dd>
 qstat [options ...]
		[-f file]
		[-of|-af output-file]
		[-server-option host[:port]]
 
		[-raw delimiter]
		[-default server-type]
		host[:port[-port_max]] ...

<H3><dt>Version 2.10</H3>

<H3><dt>DESCRIPTION</H3>
<dd>
 QStat is a command-line program that displays information about
	Internet game servers.
 The servers are either down, non-responsive, or running a
 game. For servers running a game, the server name, map name,
 current number of players, and response time are displayed.
	Server rules and player information may also be displayed.

	Games supported include Quake, QuakeWorld, Hexen II,
	Quake II, HexenWorld, Unreal, Half-Life, Sin, Shogo,
	Tribes, Tribes 2, Quake III: Arena, BFRIS, Kingpin, and
	Heretic II, Unreal Tournament, Soldier of Fortune, Rogue Spear,
	Redline, Turok II, Blood 2, Descent 3, Drakan, KISS, Nerf Arena Blast,
	Rally Master, Terminous, Wheel of Time, and Daikatana and many more.
	Note for Tribes 2: QStat only supports Tribes 2 builds
	numbered 22075 or higher.
	Note for Ghost Recon QStat only supports GhostRecon patch 1.2,
	1.3, 1.4, Desert Siege, and Island Thunder.

	Some games use query protocols compatible with an existing
	game. These servers can be queried using the flags for
	the compatible game. For instance, Turok2 should work
	using the -uns flag. Unreal Tournament is also
	supported by the -uns but is not really a different
	game. You can distinguish Unreal Tournament games with the
	"minnetver" server rule (standard Unreal servers have a
	"mingamever" server rule).

	The Quake servers can be divided into two categories: POQS
	(Plain Old Quake Server) and QuakeWorld. Quake shareware,
	Quake commercial (from CD), winquake, winded, unixded, and
	Hexen II are all POQS. The various versions of QuakeWorld
	and Quake II use a QuakeWorld type server. The distinction
	is based on network protocol used to query the servers, and
	affects the kind of information available for display.

	The different server types can be queried simultaneously.
	If QStat detects that this is being done, the output is
	keyed by the type of server being displayed. See DISPLAY
	OPTIONS.

	The game server may be specified as an IP address or a hostname.
	Servers can be listed on the command-line or, with the use
	of the -f option, a text file.

<H3><dt>DISPLAY MODES</H3>
<dd>
	One line will be displayed for each server queried. The first
	component of the line will be the server's address as given
	on the command-line or the file. This can be used as a key to
	match input addresses to server status. Server rules and player
	information are displayed under the server info, indented by
	one tab stop.

	QStat supports three additional display modes: raw,
	templates, and XML. In raw mode, the server information is
	displayed using simple delimiters and no formatting. This mode
	is good for programs that parse and reformat QStat's output.
	The template mode uses text files to layout the server information
	within existing text. This is ideal for generating web pages.
	The XML mode outputs server information wrapped in simple
	XML tags.
	The raw mode is enabled using the -raw option, template
	output is enabled using -Ts, and XML output is enabled
	with -xml.

<H3><dt>GAME OPTIONS</H3>

<dd>These options select which servers to query and what game type
they are running. Servers are specified by IP address (for example:
199.2.18.4) or hostname. Servers can be listed on the command-line
or in a file (see option -f.) The game type of a server
can be specified with its address, or a default game type can be
set for all addresses that don't have a game type.

The following table shows the command-line option and type strings
for the supported game types. The type string is used with the
-default option and in files with the -f option.

<table border=1 cellspacing=1>
<tr><th width=70>Option<th width=80>Type String<th>Default Port<th>Game Server
<tr><td>-qs<td>qs<td>26000<td>Quake
<tr><td>-h2s<td>h2s<td>26900<td>Hexen II
<tr><td>-qws<td>qws<td>27500<td>QuakeWorld
<tr><td>-hws<td>hws<td>26950<td>HexenWorld
<tr><td>-q2s<td>q2s<td>27910<td>Quake II
<tr><td>-uns<td>uns<td>7777<td>Unreal
<tr><td>-ut2s<td>ut2s<td>7777<td>Unreal Tournament 2003
<tr><td>-ut2004m<td>ut2004m<td>28902<td>Unreal Tournament 2004 Master requires CD Key
<tr><td>-hls<td>hls<td>27015<td>Half-Life
<tr><td>-sns<td>sns<td>22450<td>Sin
<tr><td>-sgs<td>sgs<td>27888<td>Shogo: Mobile Armor Division
<tr><td>-tbs<td>tbs<td>28001<td>Starsiege: Tribes
<tr><td>-t2s<td>t2s<td>28000<td>Tribes 2
<tr><td>-qwm<td>qwm<td>27000<td>QuakeWorld master
<tr><td>-hwm<td>hwm<td>26900<td>HexenWorld master
<tr><td>-q2m<td>q2m<td>27900<td>Quake II master
<tr><td>-hlm<td>hlm<td>27010<td>Half-Life master
<tr><td>-stm<td>stm<td>27010<td>Half-Life master (Steam)
<tr><td>-tbm<td>tbm<td>28000<td>Tribes master
<tr><td>-t2m<td>t2m<td>28002<td>Tribes 2 master
<tr><td>-q3s<td>q3s<td>27960<td>Quake III
<tr><td>-q3m<td>q3m<td>27950<td>Quake III master
<tr><td>-dm3s<td>dm3s<td>27666<td>Doom 3
<tr><td>-dm3m<td>dm3m<td>27650<td>Doom 3 master
<tr><td>-bfs<td>bfs<td>44001<td>BFRIS
<tr><td>-kps<td>kps<td>31510<td>Kingpin
<tr><td>-hrs<td>hrs<td>28910<td>Heretic II
<tr><td>-sfs<td>sfs<td>28910<td>Soldier of Fortune
<tr><td>-gsm<td>gsm<td>28900<td>Gamespy master
<tr><td>-gps<td>gps<td>-<td>Game using "Gamespy style" protocol 
<tr><td>-gps<td>gs2<td>-<td>Game using "Gamespy2 style" protocol 
<tr><td>-d3m<td>d3m<td>3445<td>Descent 3 PXO master
<tr><td>-d3p<td>d3p<td>2092<td>Descent 3, PXO server
<tr><td>-d3s<td>d3s<td>2092<td>Descent 3, LAN server
<tr><td>-d3g<td>d3g<td>20142<td>Descent 3, Gamespy protocol
<tr><td>-rws<td>rws<td>27960<td>Return to Castle Wolfestein
<tr><td>-rwm<td>rwm<td>27950<td>Return to Castle Wolfestein master
<tr><td>-efs<td>efs<td>27960<td>Star Trek: Elite Force
<tr><td>-efm<td>efm<td>27953<td>Star Trek: Elite Force master
<tr><td>-efs<td>efs<td>29070<td>Jedi Knight: Jedi Academy
<tr><td>-efm<td>efm<td>29060<td>Jedi Knight: Jedi Academy master
<tr><td>-grs<td>grs<td>2346<td>Ghost Recon
<tr><td>-etqws<td>etqws<td>27733<td>QuakeWars server
</table>

The command-line options can be specified multiple times, one for
each server to be queried.

<h4>Configuration Files</h4>

The games supported by QStat can be customized with configuration
files. The query parameters
of built-in game types can be modified and new games can be defined.

For built-in game types, certain parameters can be modified. The
parameters are limited to the master server protocol and master
server query string.

New game types can be defined as a variation on an existing game
type. Most new games use a Quake 3 or Gamespy/Unreal based
network engine. These games can already be queried using -q3s
or -gps, but they don't have game specific details such as the
correct default port, the game name, and the correct "game" or "mod"
server rule. And, mostly importantly, they don't get their own
game type string (e.g. q3s, rws, t2s). All of these details
can be specified in the QStat config file.

QStat comes with a default configuration file called 'qstat.cfg'.
If this file is found in the directory where qstat is run, the
file will be loaded. Configuration files can also be specified
with the QSTAT_CONFIG environment variable and the -cfg
command-line option. See <a href="#APPENDIXB">Appendix B</a> for
a description of the configuration file format.

<h4>Descent 3</h4>
Support for Descent 3 is a bit fragmented. There are three different
protocols for getting status information from a Descent 3 server: PXO,
LAN, and Gamespy. If the server was acquired from the PXO master
server, then the PXO protocol is used. If the server is running on
the local LAN (not reporting to a master server), then the LAN
protocol should be used. Finally, if the server's Gamespy query
port is known (default is 20142) then the Gamespy protcol can be
used. The gamespy protocol can be used on servers listed in the PXO
master.

Each protocol reports different information. The Gamespy protocol
provides player names, frags, deaths, and ping. The PXO and LAN
protocols only provide player names.

The ideal solution would be a PXO server list paired with each
server's gamespy query port. Most servers will use the default
gamespy query port, unless there are multiple servers on the same
machine. A possible approach is to get the server list from the
PXO master like this:<pre>qstat -d3m,outfile gt.pxo.net,d3pxo.txt</pre>
Then convert the file from "d3p" to "d3g" and remove the port numbers:
<pre>sed -e 's/d3p/d3g/' -e 's/:.*$//' d3pxo.txt > d3gs.txt</pre>
Then run the servers in d3gs.txt with -f:
<pre>qstat -f d3gs.txt</pre>
This technique will retrieve the full player info for servers using
the default gamespy query port.

<H4>Broadcast Queries</H4>
<dd>QStat has limited support for broadcast queries. Broadcast queries
use one network packet to find all the game servers on a local
network. A broadcast returns servers of one type on one port.
You may only broadcast to networks to which you computer is
directly attached (ie. local networks).

A broadcast query is specified by prefixing an address with a '<tt>+</tt>'
(plus sign). The address should be 255.255.255.255 or a valid
broadcast address for your local network. On Unixes, 'ifconfig -a' will
display the broadcast address for all attached networks.

<H4>Port Ranges</H4>
Broadcast Queries can scan a range of ports to find game servers that don't run
on the default port. Specify the minimum and maximum port of a range separated
by a dash.

<H4>Query Arguments</H4>
Some game types support customized server queries. For example,
many master servers can return a select list of servers based on
the mod, number of players, or region. Each query can be
customized differently.

Server queries are customized by attaching query arguments to the
server type option. Each argument is separated by a comma (',').
The argument has a name followed by an optional value separated
with an equal-sign ('='). The general format looks like this:
<pre>
-server-option,query-arg[=arg-value][, ...]
</pre>
See the Master Server sections below for more examples.
<H5>General Query Arguments</H5>
The follow query arguments can be applied to any server type.
<table border=1>
<tr><th>Query Argument<th>Description
<tr><td>showgameport<td>Always display the game port in QStat
output. If the query port was different from the game port, then
the query port will be saved in the "_queryport" server rule.
This is the same as the -showgameport command-line option,
but only applies to one server query.
<tr><td>gp<td>Short-hand for showgameport.
<tr><td>noportoffset<td>Do not apply the "status port offset" when
sending the server query. Some games use different ports for
game play and status queries (for example, Unreal, Medal of Honor, etc).
QStat will normally add an offset to the game port to find the
query port. But not all servers use the standard offset. This
option allows QStat to query servers where the query port is
known. The server address should be an IP address and a query
port (not the game port).
This is the same as the -noportoffset command-line option,
but only applies to one server query.
<tr><td>qp<td>Short-hand for noportoffset.
</table>

Some examples of the general query arguments.
<pre>
qstat -uns,noportoffset 1.2.3.4:7787
ADDRESS PLAYERS MAP RESPONSE TIME NAME
1.2.3.4:7787 0/16 Kansas 119 / 0 Example server
</pre>
The default Unreal game port is 7777 and the query port is usually
at offset 1 (port 7778). But this server has a different query port.
Note that qstat displays the query port. To display the game port
instead:
<pre>
qstat -uns,noportoffset,showgameport 1.2.3.4:7787
ADDRESS PLAYERS MAP RESPONSE TIME NAME
1.2.3.4:7777 0/16 Kansas 119 / 0 Example server
</pre>
Another common usage for "showgameport" is with broadcast queries:
<pre>
qstat -uns,showgameport +255.255.255.255
</pre>

<H4>Master Servers</H4>
Master server addresses don't change very often, but some times they
go off-line. The following is a table of some of the master servers
I know about.

<table border=1><tr><th align=left>Game<th align=left>Master Servers
<tr><td>QuakeWorld<td>satan.idsoftware.com (ports 27000, 27002, 27003,
27004, 27006), 204.182.161.2, 194.217.251.40, 203.34.140.1, 200.245.221.200,
194.87.251.3
<tr><td>Quake II<td>satan.idsoftware.com, q2master.planetquake.com
<tr><td>Half-Life (hlm)<td>half-life.west.won.net, half-life.east.won.net
<tr><td>Half-Life (stm)<td>steam1.steampowered.com:27010, steam2.steampowered.com:27010
<tr><td>Tribes<td>tribes.dynamix.com
<tr><td>Quake III<td>master3.idsoftware.com
<tr><td>Doom 3<td>idnet.ua-corp.com
<tr><td>Gamespy<td>master0.gamespy.com
<tr><td>Tribes 2<td>211.233.32.77:28002, 217.6.160.205:28002
<tr><td>Descent 3<td>gt.pxo.net
<tr><td>Return to Castle Wolfenstein<td>wolfmaster.idsoftware.com
<tr><td>Star Trek: Elite Force<td>master.stef1.ravensoft.com
<tr><td>UT2004<td>ut2004master1.epicgames.com, ut2004master2.epicgames.com, ut2004master3.epicgames.com
</table>

<H4>Gamespy Master</H4>

Access to the gamespy masters has been disabled by Gamespy Inc.

Server lists can be fetched from Gamespy masters by using the gsm
game type. A query argument is required to use the Gamespy master.
This extra argument indicates which server list to get from the master.
The query argument can be one of the QStat supported game types or any
other string that will fetch a server list. The following game types
can be used as query arguments: qws, q2s, q3s, tbs, uns, sgs, hls, kps,
hrs, sfs. For each of the game types, QStat will fetch the appropriate
server list and get status from each server.

The query argument can also be any string that the Gamespy master
responds to. Most of these games support a "standard" server status
protocol that I'll call the "Gamespy status protocol". Not surprisingly,
it is almost identical to the Unreal server status protocol. This
means that QStat can support any game that supports this protocol.
In QStat these games are queried using the gps game type.
Through experimentation I've found the following query arguments.

<table border=1>
<tr><th>Query Argument<th>Game
<tr><td>roguespear<td>Rainbow Six: Rogue Spear
<tr><td>redline<td>Redline Racer
<tr><td>turok2<td>Turok 2: Seeds of Evil
<tr><td>blood2<td>Blood 2: The Chosen
<tr><td>drakan<td>Drakan: Order of the Flame
<tr><td>kiss<td>KISS Psycho Circus: The Nightmare Child
<tr><td>nerfarena<td>Nerf Arena Blast
<tr><td>rally<td>Rally Masters: Michelin Race Of Champions
<tr><td>terminous<td>Terminous (?)
<tr><td>wot<td>The Wheel of Time
<tr><td>daikatana<td>Daikatana
</table>

<H4>Tribes 2 Master</H4>

The Tribes 2 master server supports a number of filtering options.
You can set these filters with QStat by appending query arguments
to the server type. The general syntax is:
<blockquote>
t2m,query-arg=value, ...
</blockquote>
<table border=1>
<tr><th>Query Argument<th>Values<th>Description
<tr><td>game<td>mod path<td>Mod path the server is using. The mod
path of unaltered servers is "base". Use query=types to
get the list of known game types.
<tr><td>mission<td>Bounty, Capture the Flag, CnH, Deathmatch, Hunters,
	Rabbit, Siege, TeamHunters<td>Mission type the server is currently running.
Use query=types to get the list of known mission types.
<tr><td>minplayers<td>0 - 255<td>Servers with fewer players than this will not be returned.
<tr><td>maxplayers<td>1 - 255<td>Servers with more players than this will not be returned.
<tr><td>regions<td>list of regions or 0xhex-value
<td>Limit servers to those in the given geographical
regions. See Region List table. The regionlist is sent as a bit mask
to the Tribes 2 master. If you know the bit mask for a region QStat
doesn't support, you can specify the bitmask directly by supplying a
hex value: regions=0x11.
<tr><td>build<td>build version #
<td>Only return servers matching this build version number. [4/20/2001]
This filter only seems to work if the build version # is 22337.
If the filter is 22228, then the master returns 0 servers. This appears
to be a bug in the T2 master.
<tr><td>status<td>list of dedicated, linux, nopassword or 0xhex-value
<td>Limit servers to those with these status flags set. The list is
one or more status flags separated by colons (':'). To filter on
dedicated Linux servers, specify status=dedicated:linux 
If you know a status flag that QStat doesn't support, you can specify
the status flags directly by supplying a hex value: status=0x3
<tr><td>maxbots<td>0 - 255<td>Servers with more bots than this will not be returned.
<tr><td>mincpu<td>0 - 65535<td>Servers with lower CPU speed than this will not be returned.
<tr><td>query<td>types<td>Get the list of game and mission types. This
is not a filter but a different master request. Using this query
argument overrides any other query arguments. The list of game and
mission types known to the master server will be displayed. In raw
mode, the first line is the list of game types and the second line is
the list of mission types. There is no output template support for
game and mission lists.
</table>

<blockquote>
<h5>Region List</h5>
The region list is one or more region arguments separated by colons (':').
For example, to filter on North American servers specify regions=naeast:nawest

<table border=1>
<tr><th>Region Argument<th>Geography
<tr><td>naeast<td>North America East
<tr><td>nawest<td>North America West
<tr><td>sa<td>South America
<tr><td>aus<td>Australia
<tr><td>asia<td>Asia
<tr><td>eur<td>Europe
</table>
</blockquote>

The Tribes 2 master query arguments can be used on the command-line
or in a server list file (via the -f option). If the values
contain spaces, be sure to quote the arguments for your shell. The
second example below demonstrates this usage for most common shells.
To query for
Capture the Flag servers that have more than 6 players:
<blockquote>
qstat -t2m,mission=Capture the Flag,minplayers=6 master-server-ip 
qstat -t2m,mission="Capture the Flag",minplayers=6 master-server-ip 
</blockquote>
If you want to do this in a server list file, that would look like
this:
<blockquote>
t2m,mission=Capture the Flag,minplayers=6 master-server-ip 
</blockquote>
Master server filters can be combined with the "outfile" option.
Just put outfile some where in the query argument list and put
the name of the output file after the master IP address:
<blockquote>
t2m,outfile,mission=Siege,minplayers=4 master-server-ip,siegeservers.txt
</blockquote>
Warning: There is a bug in the 22075 build of Tribes 2 that
doesn't return the game name. For those builds, QStat will use the game
info in place of the game name. The bug is fixed in the 22228 build.
In fixed servers, the game info can be found in the "info" server rule.

<H4>Half-Life Master</H4>

The Half-Like master server supports a number of filtering options.
You can set these filters with QStat by appending query arguments
to the server type. The general syntax is:
<blockquote>
hlm,query-arg=value, ...
</blockquote>
<table border=1>
<tr><th>Query Argument<th>Values<th>Description
<tr><td>game<td>mod path<td>Servers running this "mod".
<tr><td>map<td>map name<td>Servers running this map.
<tr><td>status<td>list of dedicated, linux, notempty, notfull
<td>Limit servers to those matching this status. The list is
one or more status flags separated by colons (':'). To filter on
dedicated servers that are not empty, specify status=dedicated:notempty
</table>

See the Tribes 2 master server above for example usage.

<H4>Half-Life Master (Steam)</H4>

The Half-Life steam master server supports a number of filtering options
different from the old WON master.
<blockquote>
stm,query-arg=value, ...
</blockquote>
<table border=1>
<tr><th>Query Argument<th>Values<th>Description
<tr><td>game<td>mod path<td>Servers running this "mod".
<tr><td>map<td>map name<td>Servers running this map.
<tr><td>region<td>name or number of region<td>Geographical Area of the server.
You can specify the name or number of the region:
	<ul>
		<li>0: US East coast</li>
		<li>1: US West coast </li>
		<li>2: South America </li>
		<li>3: Europe </li>
		<li>4: Asia </li>
		<li>5: Australia </li>
		<li>6: Middle East </li>
		<li>7: Africa</li>
	</ul>
<tr><td>status<td>list of dedicated, linux, notempty, notfull, secure, proxy
<td>Limit servers to those matching this status. The list is
one or more status flags separated by colons (':'). To filter on
dedicated servers that are not empty, specify status=dedicated:notempty
</table>

See the Tribes 2 master server above for example usage.

<H4>Doom 3 Master</H4>

The Doom 3 master server supports a number of filtering options.
You can set these filters with QStat by appending query arguments
to the server type. The general syntax is:
<blockquote>
hlm,query-arg=value, ...
</blockquote>
<table border=1>
<tr><th>Query Argument</th><th>Values</th><th>Description</th></tr>
<tr><td>status</td><td>colon separated list of password, nopassword, notfull, notfullnotempty</td>
<td>Limit servers to those matching this status. The list is
one or more status flags separated by colons (':'). To filter on
servers without password that are not full, specify status=nopassword:notfull</td></tr>
<tr><td>gametype</td><td>one of dm, tdm or tourney</td>
<td>limit servers to those mathing the specified gametype</td></tr>
</table>

See the Tribes 2 master server above for example usage. 
A special option is a number major.minor which specifies the protocol version.

<H4>UT2004 Master</H4>

The UT2004 master server supports a number of filtering options.
You can set these filters with QStat by appending query arguments
to the server type. The general syntax is:

<blockquote>
 hlm,query-arg=value, ...
</blockquote>
<table border=1>
 <tr>
 <th>Query Argument</th>
 <th>Values</th>
 <th>Description</th>
 </tr>
 <tr>
 <td>cdkey</td>
 <td>path to the UT2004 cdkey file</td>
 <td>You MUST specify a valid CD key to be able to query the master server</td>
 </tr>
 <tr>
 <td>status</td>
 <td>colon separated list of password, nopassword, notfull, notempty,
 standard, nostandard, nobots, stats, nostats, weaponstay, noweaponstay,
 transloc, notransloc</td>
 <td>Limit servers to those matching this status. The list is one or more
 status flags separated by colons (':'). To filter on standard servers
 without password that are not full, specify
 status=standard:nopassword:notfull</td>
 </tr>
 <tr>
 <td>gametype</td>
 <td>any UT2004 gametype, e.g. xMutantGame</td>
 <td>limit servers to those mathing the specified gametype</td>
 </tr>
 <tr>
 <td>mutator</td>
 <td>colon separated list of Mutators.</td>
 <td>limit servers to those running the specified mutators. Prepend a dash
 to include servers that do NOT run the specified mutator</td>
 </tr>
</table>

See the Tribes 2 master server above for example usage.

<H4>Option Usage</H4>

<dl>
<dt>-cfg configuration-file<dd>
	Load the QStat configuration file. New game types defined in
	the config file can be used in subsequent command-line options.
<dt>-server-option host[:port]<dd>
	Query game server host for status. The GAME OPTIONS
	table lists the available server-options and their default
	port.

<dt>-nocfg
	Ignore qstat configuration loaded from any default location
	(see <a href="#APPENDIXB">Appendix B</a> for a list of default locations). Must be the
	first option on the command-line. Use this option to have
	complete control over the configured game types.

<dt>-master-server-option host[:port]<dd>
	Query a game master for its server list and then query all
	the servers. The GAME OPTIONS
	table lists the available master-server-options
	and their default port.

<dt>-master-server-option,outfile host[:port],file<dd>
	Query a game master for its server list and store it
	in file. If the master cannot be contacted, then
	file is not changed. If file is - (a
	single dash), then stdout is used.
	The GAME OPTIONS table lists the available
	master-server-options and their default port.

<dt>-gsm,query-argument host[:port]<dd>
	Query a Gamespy master for a server list and then query all
	the servers. The Gamespy Master section details the supported
	values for query-argument.
<dt>-gsm,query-argument,outfile host[:port],file<dd>
	Query a Gamespy master for a server list and store it
	in file. If the master cannot be contacted, then
	file is not changed. If file is - (a
	single dash), then stdout is used.
	The Gamespy Master section details the supported
	values for query-argument.

<dt>-q3m,query-argument host[:port]<dd>
	Query a Quake 3 Arena master for a protocol-specific server list
	and then query all the servers. The query-argument should
	be a Quake 3 protocol version. Protocol version 48 is Quake 3
	version 1.27, protocol 46 is Quake 3
	version 1.25, protocol 45 is Quake 3 1.17, protocol 43 is Quake 3
	version 1.11. The default is protocol version 48.
<dt>-q3m,query-argument,outfile host[:port],file<dd>
	Query a Quake 3 Arena master for a protocol-specific server list
	and store it in file. The query-argument should
	be a Quake 3 protocol version. Protocol version 46 is Quake 3
	version 1.25, protocol 45 is Quake 3 1.17, protocol 43 is Quake 3
	version 1.11. The default is protocol version 45.

<dt>-f file<dd>
	Read host addresses from the given file. If file is -,
	then read from stdin. Multiple -f options may be
	used. The file should contain host names or IP
	addresses separated by white-space (tabs, new-lines,
	spaces, etc). If an address is preceded by a server
	type string, then QStat queries the address according
	to the server type. Otherwise QS is assumed, unless -default
	is used. The GAME OPTIONS table lists the available server
	type strings and their default port.

<dt>-default type-string<dd>
	Set the default server type for addresses where the type is not
	obvious. This affects the addresses at the end of the qstat
	command-line and those in a file not prefixed by a server type
	(see -f).
	The GAME OPTIONS table lists the available server
	type strings and their default port.

<dt>-noportoffset<dd>
	Do not apply the "status port offset" when
	sending server queries. Some games use different ports for
	game play and status queries (for example, Unreal, Medal of Honor, etc).
	QStat will normally add an offset to the game port to find the
	query port. But not all servers use the standard offset. This
	option allows QStat to query servers where the query port is
	known. The server addresses should be an IP address and a query
	port (not the game port).
	This is the same as the noportoffset server query argument,
	but applies to all servers being queried.

</dl>

<H3><dt>INFO OPTIONS</H3>

<dl compact><dt>-R<dd>
	Fetch and display server rules.

<dt>-P<dd>
	Fetch and display player information.
</dl>

<H3><dt>DISPLAY OPTIONS</H3>

<dd>The QStat output should be self explanatory. However, the type of
information returned is different between game types. If QStat
queries multiple server types, then each server status line is prefixed
with its type string. The GAME OPTIONS table lists the available
type strings.

<dl compact>
<dt>-of file<dd>
	Write output to file instead of stdout or the console.
	file is over written if it already exists.
<dt>-af file<dd>
	Like -of, but append to the file. If file does
	not exist, it is created.
<dt>-u<dd>
 Only display hosts that are up and running a game server.
		Does not affect template output.
 
<dt>-nf<dd>
 Do not display full servers. Does not affect template
		output.

<dt>-ne<dd>
 Do not display empty servers. Does not affect template
		output.

<dt>-nh<dd>
 Do not display header line (does not apply to raw or
		template output.)

<dt>-cn<dd>
		Display color names instead of numbers. This is
		the default. Only applies to Quake, QuakeWorld,
		Hexen II, and HexenWorld.

<dt>-ncn<dd>
		Display color numbers instead of color names. This is
		the default for -raw mode. Only applies to Quake,
		QuakeWorld, Hexen II, and HexenWorld.

<dt>-hc<dd>
		Display colors in #rrggbb format. This is nice for
		HTML output. Only applies to Quake, QuakeWorld,
		Hexen II, and HexenWorld.

<dt>-nx<dd>
		Perform name transforms. Transform game specific player
		and server name escape sequences into more readable text.
		This setting is ON by default.

<dt>-nnx<dd>
		No name transforms. Do not transform player and server
		names. Option -utf8 implies -nnx.

<dt>-tc<dd>
		Display time in clock format (DhDDmDDs). This is the default.

<dt>-tsw<dd>
		Display time in stop-watch format (DD:DD:DD).

<dt>-ts<dd>
		Display time in seconds. This is the default for
		-raw mode.
 
<dt>-pa<dd>
		Display player addresses. This is the default for
		-raw mode. Only available for Quake and Hexen II.

<dt>-sort sort-keys<dd>
		Sort servers and/or players. Servers and players are sorted
		according to sort-keys. Lower case sort keys are
		for servers and upper case keys are for players. The
		following sort keys are supported:
		<ul>
		<li>p - Sort by ping
		<li>g - Sort by game (mod)
		<li>i - Sort by IP address
		<li>h - Sort by hostname
		<li>n - Sort by number of players
		<li>l - Sort by list order
		<li>P - Sort by player ping
		<li>F - Sort by frags
		<li>T - Sort by team
		</ul>
		
		The 'l' (ell) sort key displays servers in the order they
		were provided to qstat. For example, the order in which
		they are listed on the command-line or in a file. The
		'l' sort key cannot be combined with other server sort
		keys, but it can be be combined with player sort keys.
		If the 'l' sort key is used with other sort keys, then the
		'l' sort key is ignored.

<dt>-hpn<dd>
		Display player names in hex.

<dt>-old<dd>
		Use pre-qstat 1.5 display style.

<dt>-raw delimiter<dd>
	Display data in "raw" mode. The argument to
	-raw is used to separate columns of
	information. All information returned by the game
	server is displayed.
 
	POQS output -- General server information is
	displayed in this order: command-line arg (IP address
	or host name), server name, server address (as returned
	by Quake server), protocol version, map name, maximum
	players, current players, average response time,
	number of retries. Server rules are displayed on one
	line as rule-name=value. If significant packet
	loss occurs, rules may be missing. Missing rules are
	indicated by a "?" as the last rule. Player information
	is displayed one per line: player number, player name,
	player address, frags, connect time, shirt color, pants
	color. A blank line separates each set of server
	information.
 
	QuakeWorld and HexenWorld server output -- General server information is
	displayed in this order: command-line arg (IP address
	or host name), server name, map name, maximum
	players, current players, average response time,
	number of retries, game (mod). Server rules are displayed on one
	line as rule-name=value. Player information
	is displayed one per line: player number, player name,
	frags, connect time, shirt color, pants
	color, ping time (milliseconds), skin name. A blank line
	separates each set of server information.
 
	All master server output -- Master server information is
	displayed in this order: command-line arg (IP address
 or host name), number of servers. No other information
	is displayed about master servers.
 
	Quake II, Quake III, Half-Life, Sin, BFRIS, Kingpin, Heretic II, Unreal, Tribes 2, and Shogo server output -- General server information and
	server rules are the same as a QuakeWorld server.
	The player information varies for each game:
<ul>
<li>Quake II/III, Sin, Kingpin, Heretic II, Shogo: player name, frags, ping time
<li>Half-Life: player name, frags, connect time
<li>Tribes: player name, frags, ping time, team number, packet loss
<li>Tribes 2: player name, frags, team number, team name, player type, tribe tag
<li>Unreal: player name, frags, ping time, team number, skin, mesh, face
<li>BFRIS: player number, ship, team name, ping time, score, frags, player name
<li>Descent 3: player name, frags, deaths, ping time, team 
</ul>
	Ping time is in milli-seconds. Connect time is in seconds.
	A blank line separates each set of server information.
 
	Ghost Recon server output -- General server information and
	server rules are the detailed in the GhostRecon.txt file.

Servers queried using the "Gamespy style" protocol use the
	same raw output format as Unreal servers.
	
<dt>-raw,game delimiter<dd>
	Same as -raw but adds the game or mod name as the last
	item of server info.

<dt>-raw-arg<dd>
	When used with -raw, always display the server address
	as it appeared in a file or on the command-line. Note that
	when -H is used with -raw, the first field of the
	raw output could be a hostname if the server IP address was resolved.
	This can make matching up input servers addresses with raw output
	lines fairly difficult. When -raw-arg is also used, an
	additional field, the unresolved server address, is added at the
	beginning of all raw output lines.

<dt>-progress,count<dd>
	Print a progress meter. Displays total servers processed,
	including timeouts and down servers. The meter is just a
	line of text that writes over itself with &lt;cr&gt;. Handy
	for interactive use when you are redirecting output to
	a file (the meter is printed on stderr). 
	By default, the progress meter is updated for every server.
	The updates can be limited by appending ,count to
	the option where count is a number. The meter
	will be updated every count servers. For example,
	-progress,10 will update every ten servers.

<dt>-Tserver file 
<dt>-Tplayer file 
<dt>-Trule file 
<dt>-Theader file 
<dt>-Ttrailer file<dd>
	Output templates. Each template should be a text file containing
	QStat variables that are substituted for results from the server
	query. The -Tserver flag must present to enable template
	output. The other -T flags are optional. The server template
	is output once for each server queried. The player template,
	if present, is output once for each player (if -P is also
	used). The rule template is output once for each server rule (the
	-R option may be required for some game types).
	The header template is output once before any servers
	are output. The trailer template is output once after all servers
	are output. See <a href="#APPENDIXA">Appendix A</a> for the
	output template formatting and variables. 
	NOTE: All of of the -T flags may be abbreviated with two
	characters: -Ts, -Tp, -Tr, -Th, and -Tt.

<dt>-htmlnames<dd>
	Colorize Quake 3 and Tribes 2 player names using html font tags.
	Enabled by default if $HTML is used in an output template.

<dt>-nohtmlnames<dd>
	Do not colorize Quake 3 and Tribes 2 player names even if
	$HTML is used in an output template. The
	$HTMLPLAYERNAME variable will always colorize player
	names.

<dt>-htmlmode<dd>
	Convert &lt;, &gt;, and &amp; to the equivalent HTML entities.
	This is the same as $HTML in an output template, but works for
	raw display mode. Using -htmlmode with -xml will
	result in double-escaping.

<dt>-carets<dd>
	Display carets in Quake 3 player names. Carets are
	used for colorized player names and are remove by default.
	This option has no effect if -htmlnames is
	enabled.

<dt>-xml<dd>
	Output server information wrapped in XML tags.

<dt>-utf8<dd>
	Use the UTF-8 character encoding for XML output.

<dt>-showgameport<dd>
	Always display the game port in QStat
	output. If the query port was different from the game port, then
	the query port will be saved in the "_queryport" server rule.
	This is the same as the showgameport server query argument,
	but applies to all server queries.

<dt>-errors<dd>
	Display errors.

<dt>-d<dd>
	Enable debug options. By default, enables printing of all
	received packets to stderr.

</dl>

<H3><dt>SEARCH OPTIONS</H3>

<dl compact><dt>-H<dd>
	Resolve IP addresses to host names. Use with caution
	as many game servers do not have registered host
	names. QStat may take up to a minute to timeout
	on each unregistered IP address. The duration of
	the timeout is controlled by your operating system. Names
	are resolved before attempting to query any servers.

<dt>-Hcache cache-file<dd>
	Cache host name and IP address resolutions in cache-file.
	If the file does not exist, it is created. If -Hcache is used
	without -H, then the cache is only used for host to IP address
	resolution. WARNING A host cache file should not be
	shared by QStat programs running at the same time. If you run several
	QStats at the same time, each should have its own cache file.

<dt>-interval seconds<dd>
	Interval in seconds between server retries. Specify as a
	floating point number. Default interval is 0.5 seconds.
	This option does not apply to master servers (see -mi.)
 
<dt>-mi seconds<dd>
	Interval in seconds between master server retries. Specify as a
	floating point number. Default interval is 2 seconds.
 
<dt>-retry number<dd>
	Number of retries. QStat will send this many packets
	to a host before considering it non-responsive. Default
	is 3 retries.

<dt>-maxsimultaneous number<dd>
	Number of simultaneous servers to query. Unix systems
	have an operating system imposed limit on the number of
	open sockets per process. This limit varies between
	32 and 100 depending on the platform. On Windows 95 and
	Windows NT, the "select" winsock function limits the number of
	simultaneous queries to 64. These limits can be increased
	by minor changes to the code, but the change is different
	for each platform. Default is 20 simultaneous queries.
	This option may be abbreviated -maxsim.

<dt>-timeout seconds<dd>
 Total run time in seconds before giving up. Default is
	no timeout.

</dl>

<H3><dt>NETWORK OPTIONS</H3>

<dl compact>
<dt>-srcport port-number | port-range<dd>
	Specify the source ports for sending packets. The ports can
	be a single number or a range. A range is two numbers
	separated by a dash ('-'). The numbers should be positive
	and less than 65535. Use this option to get through a
	firewall that has source port restrictions. Set -srcport
	to the range of ports allowed by the firewall.
	
	Example: If your firewall will allow outgoing UDP packets on
	ports 26000-30000, the qstat option would be -srcport 26000-30000
	
	Note: The number of source ports given should be greater
	than or equal to the -maxsim (defaults to 20). The
	number of source ports will limit the number of simultaneous
	server queries.

<dt>-srcip IP-address<dd>
	Specify a local IP address from which to send packets. This
	is useful on machines that have multiple IP addresses where
	the source IP of a packet is checked by the receiver.
	Normally this option is never needed.
</dl>

<H3><dt>NOTES</H3>

<dd>
	The response time is a measure of the expected playability
	of the server. The first number is the server's average
	time in milli-seconds to respond to a request packet from
	QStat. The second number is the total number of retries
	required to fetch the displayed information. More retries
	will cause the average response time to be higher. The
	response time will be more accurate if more requests are made
	to the server.

For POQS, a request is made for each server rule and line
	of player information. So setting the -P and
	-R options will result in a more accurate
	response time. Quake and Hexen II are POQS.

For most other game servers, QStat makes just one request to
	retrieve all the server status information, including server
	rules and player status. The -P and -R options do
	not increase the number of requests to the server.

Half-Life supports three different requests for information;
	general status, players, and server rules.  Each requires a
	separate request packet, so a total of three are used to
	retrieve player and rules.

Quake supports a number of control codes for special effects in
	player names. QStat normalizes the codes into the ASCII
	character set before display. The graphic codes are not
	translated except the orange brackets (hex 90, 10, 91, and 11)
	which are converted to '[' and ']'. Use the hex-player-names
	option -hpn to see the complete player name.

POQS do not return version information. But
	some small amount of info can be gathered from the server
	rules. The noexit rule did not appear until version 1.01.
	The Quake II server rules include a "<tt>version</tt>" key that
	contains the id build number. Recent releases of QuakeWorld
	have a "<tt>*version</tt>" key in the server rules. Unreal
	servers include a "<tt>gamever</tt>" key in the server rules
	that contains the server version without the decimal point.
	Most other game servers include some kind of version info
	in the server rules.

<H3><dt>EXAMPLES</H3>

<dd>The following is an example address file that queries a QuakeWorld
master, several Hexen II servers, some POQS, and a few Quake II servers.

<pre>
QWM 192.246.40.12:27004
H2S 207.120.210.4
H2S 204.145.225.124
H2S 207.224.190.21
H2S 165.166.140.154
H2S 203.25.60.3
QS 207.25.198.110
QS 206.154.207.104
QS 205.246.42.31
QS 128.164.136.171
Q2S sm.iquest.net
Q2S 209.39.134.5
Q2S 209.39.134.3
</pre>
If the above text were in a file called <code>QSERVER.TXT</code>,
then the servers could be queried by running:
 
	<code>qstat -f QSERVER.TXT</code>

<H3><dt>IMPLEMENTATION NOTES</H3>
<dd>
 QStat sends packets to each host and waits for return packets.
 After some interval, another packet is sent to each host which
 has not yet responded. This is done several times before the
 host is considered non-responsive. QStat can wait for responses
 from up to 20 hosts at a time. For host lists longer than
 that, QStat checks more hosts as results are determined.

	The following applies only applies to POQS. If QStat exceeds
	the maximum number of retries when fetching
	server information, it will give up and try to move on to
	the next information. This means that some rules or player
	info may occasionally not appear. Player info may also be
	missing if a player drops out between getting the general
	server info and requesting the player info. If QStat times
	out on one rule request, no further rules can be fetched.
	This is a side-effect of the Quake protocol design.

 The number of available file descriptors limits the number of
 simultaneous servers that can be checked. QStat reuses file
 descriptors so it can never run out. The macro MAXFD in
 qstat.c determines how many file descriptors will be
 simultaneously opened. Raise or lower this value as needed. The
 default is 20 file descriptors.

	Operating systems which translate ICMP Bad Port
	(ICMP_PORT_UNREACHABLE) into a ECONNREFUSED will display some
	hosts as DOWN. These hosts are up and connected to the
	network, but there is no program on the port. Solaris 2.5 and
	Irix 5.3 correctly support ICMP_PORT_UNREACHABLE, but Solaris
	2.4 does not. See page 442 of "Unix Network Programming" by
	Richard Stevens for a description of this ICMP behavior.

	Operating systems without correct ICMP behavior will just
	report hosts without Quake servers as non-responsive.
	Windows NT and Windows 95 don't seem to support this ICMP.

	For hosts with multiple IP addresses, QStat will only send
	packets to the first address returned from the name service.

	QStat supports Unreal version 2.15 or greater.

<H3><dt>PORTABILITY</H3>
<dd>
 UNIX - QStat has been compiled and tested on Solaris 2.x,
 Irix 5.3/6.2/6.3/6.4, FreeBSD 2.2/3.0,
	BSDi, HP-UX 10.20/11.0, and various flavors of Linux.

WINDOWS - The Windows version of QStat (<tt>win32/qstat.exe</tt>) runs on Windows 95
 and Windows NT as a console application. On Windows 95 and NT 4.0,
	short-cuts can be used to
 set the arguments to qstat. On Windows NT 3.51, use a batch file.

	OS/2 - An OS/2 binary is no longer included. Try contacting Per Hammer
	for an OS/2 Warp binary.
	<a href="mailto:per@mindbend.demon.co.uk">per@mindbend.demon.co.uk</a>.

	VMS - The source includes a VMS patch from John Ross Hunt.
	This patch was tested on QStat 2.0b, but has not been tested on
	the current version. See COMPILE.txt for instructions.

<H3><dt>VERSION</H3>
<dd>
	This is QStat version 2.10
	The QStat webpage is updated for each new version and
	contains links to Quake server listings and pages about
	the Quake and Unreal network protocols. The page can be found at
 
	<a href="http://www.qstat.org">http://www.qstat.org</a>

Quake, Quake II, QuakeWorld, and Quake III created by id Software.
Hexen II, HexenWorld, and Heretic II
created by Raven Software. Unreal created by Epic Games. Half-Life
created by Valve Software. Sin created by Ritual Entertainment.
Shogo: Mobile Armor Division was created by Monolith Productions Inc.
Tribes and Tribes 2 created by Dynamix, Inc. BFRIS created by Aegis Simulation
Technologies. Kingpin created by Xatrix Entertainment Inc.

<H3><dt>AUTHOR</H3>
<dd>
	<a href="http://www.activesw.com/people/steve/">Steve Jankowski</a>
 
	<a href="mailto:steve@qstat.org">steve@qstat.org</a>

<H3><dt>COPYRIGHT</H3>
<dd>
	Copyright &copy; 1996,1997,1998,1999,2000,2001,2002 by Steve Jankowski
<H3><dt>LICENSE</H3>

	QStat is covered by the terms of the Artistic
	License. The license terms can be found in <tt>LICENSE.txt</tt>
	of the QStat package.
</dl>

<hr>

<a name="APPENDIXA">
<H3><dt>APPENDIX A - Output Templates</H3>
QStat output templates provide greater control of the appearance
of server status information. The results of a server query can be
organized, formatted, and wrapped within any other text. The most
obvious use is to generate HTML for web pages. However, it could
also generate custom output for redisplay within another tool.

There are four output templates:
<table border=1 cellspacing=1>
<tr><th>Template<th>Option<th>&nbsp;
<tr><td>server<td>-Ts<td>Output once for each server queried. (required)
<tr><td>player<td>-Tp<td>Output once for each player. Must be used with -P.
Invoked by the $PLAYERTEMPLATE variable.
<tr><td>rule<td>-Tr<td>Output once for each server rule.
Invoked by the $RULETEMPLATE variable.
<tr><td>header<td>-Th<td>Output once before any servers are queried.
<tr><td>trailer<td>-Tt<td>Output once after all servers are output.
</table>

The server template must be specified to enable template output. The
other templates are optional.

Each output template is a file containing text and QStat variables.
The text is output unchanged by QStat, but the variables are processed
and replaced by QStat. Most variables are replaced by values from a
queried server. Some variables have hardcoded values,
and some generate no output, but affect how the template is processed.

Variables are grouped according to the templates where they can be used.
General variables may be used in any of the templates. Server variables
may be used in the server or player templates. Player variables may be used in the
player template. Expression variables may only be used with the
$IF and $IFNOT variables. If a variable is used where it
doesn't make sense, it is ignored and generates no output.

Variables are specified using one of several syntaxes: 
<pre>
 $VAR
 $VAR:OPTION
 $(VAR)
 $(VAR:OPTION)
 $(VAR:OPTION(ARGUMENT))
</pre>
The syntax used does not affect the output. However using the $()
syntax is somewhat more readable when the text gets cluttered. If you
want the variable to be followed immediately by text, then the $()
syntax must be used.

<H4>Download considerations</H4>
If you are generating output to be downloaded, then you'll want to make
your output as small as possible. In the case of HTML, you can reduce
the size of your pages by excluding stuff.
<li>Remove unneeded spaces (indenting and newlines)
<li>Remove unneeded end tags. The HTML spec says the following tags can
always be left out: &lt;/TD&gt; &lt;/TR&gt; &lt;/TH&gt;
<li>When creating a table, "width" modifiers are only needed on one
cell of a column. Put them on the cells of the first row of the
table.

<H4>Display options</H4>
The display options -u, -ne, and -nf have no
affect on template output. Use the $IF:UP, $IF:ISEMPTY,
and $IF:ISFULL conditions to accomplish the same thing.

<H4>General Variables</H4>
<table border=1 cellspacing=1>
<tr><td width=150>$QSTATURL<td>Output the web address of the QStat home page.
<tr><td>$QSTATVERSION<td>Output the version of QStat being run.
<tr><td>$QSTATAUTHOR<td>Output the name of the QStat programmer.
<tr><td>$QSTATAUTHOREMAIL<td>Output the email address of the QStat programmer.
<tr valign=top><td>$HTML<td>Enable HTML friendly string output. Server
results may
include characters that have special meaning in HTML. These are replaced
by equivalent SGML entities. QStat converts '<tt>&lt;<tt>', '<tt>&gt;<tt>',
and '<tt>&amp;<tt>' to '<tt>&amp;lt;<tt>', '<tt>&amp;gt;<tt>', and
'<tt>&amp;amp;<tt>'. Use this variable once in the header template.
<tr valign=top><td>$CLEARNEWLINES<td>Convert line feeds and carriage
returns into spaces. Applies to all variables that output strings.
Use this variable once in the header template.
<tr valign=top><td>$RULENAMESPACES<td>Allow spaces in rule names.
Use this variable once in the header template.
<tr valign=top><td>$IF<td>Conditional output. If the variable option is "true,"
the template is output up to a matching $ENDIF variable. If the variable
option is "false," the template is ignored until after a matching
$ENDIF. See Conditional Options for a list of supported conditional
options.
<tr><td>$IFNOT<td>Conditional output. Same as $IF, but the opposite
sense.
<tr valign=top><td>$ENDIF<td>End conditional output. There must be one $ENDIF for
each $IF and $IFNOT within a template.
<tr><td>$NOW<td>Output the current local time.
<tr><td>$TOTALSERVERS<td>The total number of servers to be queried.
<tr><td>$TOTALUP<td>The number of servers up and running.
<tr><td>$TOTALNOTUP<td>The number of servers either DOWN or TIMEOUT.
<tr><td>$TOTALPLAYERS<td>The number of players found on all servers.
<tr><td>$TOTALMAXPLAYERS<td>The sum of the maximum player values
for all servers.
<tr><td>$TOTALUTILIZATION<td>The ratio of $TOTALPLAYERS to $TOTALMAXPLAYERS
expressed as a percentage (a number between 0 and 100). Reports how full
the servers are.
<tr valign=top><td>$\<td>Ignore the next newline.
Not really a variable, but a way to curtail the output of extra newlines.
Saves space in the output while the template remains readable. Must be
the last thing on the line.
<tr><td>$DEFAULTTYPE<td>The full name of the default server type specified
with -default.
</table>

<H4>Server Variables</H4>
<table border=1 cellspacing=1>
<tr valign=top><td width=150>$HOSTNAME<td>Output the host name of the server if known,
otherwise the server address as given to QStat.
</tr>
<tr><td>$SERVERNAME<td>Output the name of the server.
</tr>
<tr valign=top><td>$PING<td>The time in milli-seconds to get a response from
the server. If the server is DOWN or TIMEOUT, nothing is output.
</tr>
<tr><td>$PLAYERS<td>The number of players on the server.
</tr>
<tr><td>$MAXPLAYERS<td>The maximum number of players allowed on the server.
</tr>
<tr><td>$MAP<td>The name of the map being played.
</tr>
<tr><td>$GAME<td>The name of the game being played. This is usually the
name of the "mod" run by the server.
<tr><td>$GAMETYPE<td>The type of game being played. Only applies to
Quake 3. Typical values are Free For All, Capture the Flag, and Arena.
</tr>
<tr><td>$RETRIES<td>The number of retries needed to get the server status.
This is a measure of packet loss.
</tr>
<tr><td>$IPADDR<td>The IP address of the server. Does not include the
port number.
</tr>
<tr><td>$PORT<td>The port the server is running on.
</tr>
<tr><td>$ARG<td>The server address as given to QStat.
</tr>
<tr valign=top><td>$TYPE<td>Output one of the following depending on the server type:
<pre> Quake
 Quake II
 Quake II Master
 QuakeWorld
 QuakeWorld Master
 Hexen II
 HexenWorld
 Unreal
 Unreal Tournament 2003
 Half-Life
 Half-Life Master
 Sin
 Tribes
 Tribes Master
 Tribes 2
 Tribes 2 Master
 Shogo: Mobile Armor Division
 Quake III: Arena
 Quake III Master
 BFRIS
 Kingpin
 Heretic II
 Soldier of Fortune
 Gamespy Master
 Gamespy Protocol
</pre>
If the server type is not known, nothing is output.
</tr>
<tr valign=top><td>$TYPESTRING<td>The server's type string (see GAME OPTIONS table.)
</tr>
<tr valign=top><td>$TYPEPREFIX<td>The server's type prefix (same as $TYPESTRING but in all-caps.)
</tr>
<tr valign=top><td>$RULE:name<td>The value of a server rule. If the
rule is not returned by the server, nothing is output. Must be used with
the -R flag.
Server rule names can include any alpha-numeric
character plus '*', '_', '.', or ' ' (space). The use of space in a rule
name will require use of the parenthesized format: $(RULE:name)
</tr>
<tr valign=top><td>$ALLRULES<td>Output all the server rules in the format
name=value separated by commas. Must be used with
the -R flag.
</tr>
<tr valign=top><td>$PLAYERTEMPLATE<td>Invoke the player template. The player
template is output once for each player on the server. Must be used with
the -P flag.
</tr>
<tr valign=top><td>$RULETEMPLATE<td>Invoke the rule template. The rule
template is output once for each server rule.
</tr>

</table>

<H4>Player Variables</H4>
The player template is only invoked if $PLAYERTEMPLATE is used in the
server template.
<table border=1 cellspacing=1>
<tr><td width=150>$PLAYERNAME<td>The name of the player. If
-htmlnames or $HTML is used, then HTML color font tags will
be added for Quake 3 and Tribes 2 player names. If $HTML is used
but -nohtmlnames is set, then player names will not be
colorized.
</tr>
<tr><td width=150>$HTMLPLAYERNAME<td>The name of the player with HTML color
font tags. Only Quake 3 and Tribes 2 are supported.
</tr>
<tr><td>$FRAGS<td>The number of frags scored.
</tr>
<tr><td>$DEATHS<td>Descent 3 - The number of times player has died.
Ghost Recon - Indicates if the player is dead. Only available for
Descent 3 or Ghost Recon.
</tr>
<tr><td>$PLAYERPING<td>The player's ping time to the server.
This value is not available from Half-Life or Ghost Recon servers.
</tr>
<tr valign=top><td>$CONNECTTIME<td>How long the player has been playing.
This value is only available from Quake, QuakeWorld, Hexen II, and
Half-Life servers.
</tr>
<tr><td>$SKIN<td>The name of the player's skin texture.
This value is not available from ?? and Ghost Recon servers.
</tr>
<tr valign=top><td>$MESH<td>The name of the player's mesh (model).
This value is only available from Unreal servers.
</tr>
<tr valign=top><td>$FACE<td>The name of the player's face texture.
This value is only available from Unreal version 405+ servers.
</tr>
<tr valign=top><td>$SHIRTCOLOR<td>Color of the player's shirt.
This value is only available from Quake, QuakeWorld, and Hexen II servers.
</tr>
<tr valign=top><td>$PANTSCOLOR<td>Color of the player's pants.
This value is not available from Quake, QuakeWorld, and Hexen II servers.
</tr>
<tr valign=top><td>$PLAYERIP<td>The IP address of the player's computer.
This value is only available from Quake and Hexen II servers.
</tr>
<tr><td>$TEAMNUM<td>The player's team number. This value is only
available from Unreal, Tribes, Tribes 2 and Ghost Recon servers.
<tr><td>$TEAMNAME<td>The player's team name. This value is only
available from Tribes and Tribes 2 servers.
<tr><td>$TRIBETAG<td>The player's tribe tag. This value is only
available from Tribes 2 servers.
<tr><td>$PLAYERSTATID<td>The player's global statistics id. This value is only
available from Unreal Tournament 2003 servers.
<tr><td>$PACKETLOSS<td>The player's packet loss. This value is only
available from Tribes servers.
<tr><td>$COLORNUMBERS<td>Display $SHIRTCOLOR and $PANTSCOLOR as
numbers. Equivalent to -ncn command-line option. No output.
<tr><td>$COLORNAMES<td>Display $SHIRTCOLOR and $PANTSCOLOR using
color names. Equivalent to -cn command-line option. No output.
<tr><td>$COLORRGB<td>Display $SHIRTCOLOR and $PANTSCOLOR using
#rrggbb format. Equivalent to -hc command-line option. No output.
<tr><td>$TIMESECONDS<td>Display $CONNECTTIME as number of seconds.
Equivalent to -ts command-line option. No output.
<tr><td>$TIMECLOCK<td>Display $CONNECTTIME in clock format (DhDDmDDs).
Equivalent to -tc command-line option. No output.
<tr><td>$TIMESTOPWATCH<td>Display $CONNECTTIME in stop-watch format (DD:DD:DD).
Equivalent to -tsw command-line option. No output.
</tr>

</table>

<H4>Rule Variables</H4>
The rule template is only invoked if $RULETEMPLATE is used in the
server template. The rule template supports equality tests on rule names
and values. See RULENAME and RULEVALUE under Conditional Options.

<table border=1 cellspacing=1>
<tr><td width=150>$RULENAME<td>The server rule name.
<tr><td width=150>$RULEVALUE<td>The server rule value.
</table>

<H4>Conditional Options</H4>

These options maybe used with the $IF and $IFNOT variables.
For example, to display player information, the following could be used
in the server template:
<pre>
 $(IF:PLAYERS)$(IF:FLAG(-P))
 The server has $(PLAYERS) players:
 $(PLAYERTEMPLATE)
 $(ENDIF)$(ENDIF)
</pre>
The template between the $IF and $ENDIF variables will only be
displayed if the server has one or more players and the -P
flag was given to QStat.

<table border=1 cellspacing=1>
<tr><td width=150>GAME<td>True if the server is running a "mod."
<tr><td>PLAYERS<td>True if the server has one or more players.
<tr><td>QUAKE<td>True if the server is running Quake (the original).
<tr><td>QUAKE2<td>True if the server is running Quake II.
<tr><td>Q2MASTER<td>True if the server is a Quake II master.
<tr><td>QUAKEWORLD<td>True if the server is running QuakeWorld.
<tr><td>QWMASTER<td>True if the server is a QuakeWorld master.
<tr><td>HEXEN2<td>True if the server is running Hexen II.
<tr><td>HEXENWORLD<td>True if the server is running HexenWorld.
<tr><td>UNREAL<td>True if the server is running Unreal.
<tr><td>UNREALTOURNAMENT2003<td>True if the server is running Unreal Tournament 2003.
<tr><td>HALFLIFE<td>True if the server is running Half-Life.
<tr><td>HLMASTER<td>True if the server is a Half-Life master.
<tr><td>SIN<td>True if the server is running Sin.
<tr><td>TRIBES<td>True if the server is running Tribes.
<tr><td>TRIBESMASTER<td>True if the server is a Tribes master.
<tr><td>TRIBES2<td>True if the server is running Tribes 2.
<tr><td>TRIBES2MASTER<td>True if the server is a Tribes 2 master.
<tr><td>SHOGO<td>True if the server is running Shogo.
<tr><td>QUAKE3<td>True if the server is running Quake III.
<tr><td>Q3MASTER<td>True if the server is a Quake III master.
<tr><td>BFRIS<td>True if the server is running BFRIS.
<tr><td>KINGPIN<td>True if the server is running Kingpin.
<tr><td>HERETIC2<td>True if the server is running Heretic II.
<tr><td>SOLDIEROFFORTUNE<td>True if the server is running Soldier of Fortune.
<tr><td>DESCENT3<td>True if the server is running Descent 3.
<tr><td>GAMESPYMASTER<td>True if the server is a Gamespy Master.
<tr><td>GAMESPYPROTOCOL<td>True if the server is running a "Gamespy style" status protocol.
<tr><td>RULE(name)<td>True if the rule name is set on
the server.
Server rule names can include any alpha-numeric
character plus '*', '_', or '.'. If $RULENAMESPACES is enabled,
then rule names may contain a ' ' (space).
<tr valign=top><td>FLAG(name)<td>True if the flag name was used
on the QStat command-line. The only flag names supported are:
-H, -P, and -R. Any other flag name returns
false.
</tr>
<tr><td>UP<td>True if the server is up and running.
</tr>
<tr valign=top><td>DOWN<td>True if the server is known to be not running. This
is true if the server computer returns an ICMP indicating that nothing
is running on the port. Only supported by some operating systems.
</tr>
<tr><td>TIMEOUT<td>True if the server never responded to a status query.
<tr><td>HOSTNOTFOUND<td>True if the host name lookup failed.
<tr><td>ISEMPTY<td>True if the server has no players.
<tr><td>ISMASTER<td>True if this is a master server.
<tr><td>ISFULL<td>True if the server has the maximum players.
<tr valign=top><td>ISTEAM<td>True if the player is a team. Only available
with Tribes and Tribes 2 servers. Only applies to the player template.
<tr valign=top><td>ISBOT<td>True if the player is a bot. Only available
with Tribes 2 servers. Only applies to the player template.
<tr valign=top><td>ISALIAS<td>True if the player is using an alias.
Only available with Tribes 2 servers. Only applies to the player template.
<tr valign=top><td>TRIBETAG<td>True if the player has a tribe tag.
Only available with Tribes 2 servers. Only applies to the player template.
</tr>

<tr valign=top><td>RULENAME<td>True if the rule name matches the
variable argument. For example $(IF:RULENAME(version)) will be true
when the rule template is outputing a "version" server rule.
Only applies to the rule template.

<tr valign=top><td>RULEVALUE<td>True if the rule value matches the
variable argument. For example $(IF:RULEVALUE(1)) will be true
when the rule template is outputing a server rule whose value is "1".
Only applies to the rule template.

<tr><td>DEATHS<td>True if the player has recorded DEATHS in Descent 3 or if the 
player is dead in Ghost Recon. NOTE if the Ghost Recon player
has spawns available they can go from dead to alive.

</table>

<a name="APPENDIXB">
<H3><dt>APPENDIX B - QStat Configuration File</H3>
QStat configuration files modify built-in game types or create new
game types. New command-line options and template variables are created
for new game types.

Please refer to the default configuration file for examples. The
default configuration file <tt>qstat.cfg</tt> can be found in the
QStat package.

<h4>Config File Load Order</h4>
QStat will load one default configuration file and zero or more
command-line configuration files. The default configuration file
will be the first readable file found by the following search.

<ol>
<li>File named in $QSTAT_CONFIG environment variable.
<li>Unix: $HOME/.qstatrc 
Windows: $HOME/qstat.cfg
<li>Unix: sysconfdir/qstat.cfg 
Windows: location-of-qstat.exe/qstat.cfg
</ol>

The default configuration file will be loaded before reading any
command-line parameters.  Configuration files specified on the command
line will be merged with the contents of the default config file.
In the case of duplicate game types, the command-line config files
will be used.

The QStat package includes a <tt>qstat.cfg</tt> that defines several
new game types. If you want to use these game types, you need to
place the file where it can be found by the default config file
search. Or use the -cfg option.

<blockquote>Unix Note: The sysconfdir is determined when qstat is
compiled. For Unix compiles, the QStat makefiles default to <tt>/etc</tt>.
To compile with a different sysconfdir, set SYSCONFDIR when
compiling with <tt>gmake</tt>. For example, to set sysconfdir
to <tt>/usr/local/etc</tt>
<blockquote>
<table border=0 bgcolor=gray>
<tr bgcolor=#555555><td>
<pre>% gmake SYSCONFDIR=/usr/local/etc</pre></td></tr>
</table>
</blockquote>

</blockquote>

<blockquote>Windows Note: The location-of-qstat.exe is the directory
where the QStat executable (<tt>qstat.exe</tt>) is located. Just put the
default <tt>qstat.cfg</tt> in the same directory as <tt>qstat.exe</tt>.
</blockquote>

<h4>General Syntax</h4>
QStat configuration files describe game types using "stanzas". A stanza
begins with a "gametype" line and is followed by several parameter lines
ending with an "end" line. The general syntax looks like this:
<blockquote>
<table border=0 bgcolor=gray>
<tr bgcolor=#555555><td>
<pre>gametype type-string (modify | new extend type-string)
 parameter-name = parameter-value
 ...
end
</pre></td></tr>
</table>
</blockquote>
The text in bold are keywords that must be used as shown.

Parameter names are one or more words separated by spaces. The supported
parameters and their meaning are listed in Gametype Parameters. Extra
white space before, after and within a parameter name is ignored.
An equal sign ('=') must separate the parameter name and the
parameter value. There can be one parameter setting per line.

Parameter values are one more characters or escape sequences. Leading
and trailing spaces are ignored. All characters are used as-is except
for backslash ('\') which begins an escape sequence.
<blockquote>
<table border=0 bgcolor=gray>
<tr bgcolor=#555555><td>\\<td>A single backslash ('\')
<tr bgcolor=#555555><td>\n<td>A newline (ASCII char 10)
<tr bgcolor=#555555><td>\r<td>A carriage return (ASCII char 13)
<tr bgcolor=#555555 valign=top><td>\(space)&nbsp;<td>A space (ASCII char 32). This escape should
	be entered as two characters: backslash followed by one space.
<tr bgcolor=#555555 valign=top><td>\xHH<td>A single character represented by the two-digit
	hexadecimal code. The hex digits H must be 0-9, A-F, or a-f.
<tr bgcolor=#555555 valign=top><td>\DDD<td>A single character represented by the three-digit
	octal code. The octal digits D must be 0-7.
</table>
</blockquote>

<h4>Defining New Game Types</h4>
New game types are defined with the new keyword.
<blockquote>
<table border=0 bgcolor=gray>
<tr bgcolor=#555555><td><pre>
gametype new-type-string new extend existing-type-string
 parameter-name = parameter-value
 ...
end
</pre></td></tr>
</table>
</blockquote>
The new-type-string must not be a built-in type string. If a new gametype
is defined multiple times in configuration files, only the last
definition is used. The existing-type-string can be any built-in or
configuration defined game type. However, QStat has the best support for
extending Q3S, Q2S, GPS, UNS, and Q3M game types.

The new game type has command-line option, type string and type prefix
derived from new-type-string. The case of new-type-string is ignored.
The command-line option and type string are always lower-case and the
type prefix is always upper case.

The new game type starts with the same parameters as the existing-type-string
except for the type string itself. Game type parameters are set by the
following parameter setting lines. Some parameters may only be used
with master server and some only with game servers.

We suggest that new-type-strings be as short as possible and end with
an 's' for game servers and an 'm' for master servers. New game types
should, but are not required to, set the name, default port, and
template var parameters. The template var should be all upper-case
and should not contain any spaces.

<h4>Modifying Game Types</h4>
Existing game types can be modified to update their query parameters.
<blockquote>
<table border=0 bgcolor=gray>
<tr bgcolor=#555555><td><pre>
gametype existing-type-string modify
 parameter-name = parameter-value
 ...
end
</pre></td></tr>
</table>
</blockquote>
The existing-type-string can be a built-in game type or a configuration
defined game type.

Only certain parameters can be modified: master protocol, master query,
and master packet.

<h4>Request Packets</h4>
The request packets used for game server queries can be set with
status packet, status2 packet, player packet, and rule packet.
Request packets for master servers can be set with the master packet
parameter.

A request packet can only be set if the extended game type uses the
same type of request packet. If a game type only uses the status
packet, then an extending game type can only set the status packet.

Request packet typically contain binary characters (those beyond the
printable ASCII character set). These can be specified using the
hex and octal character escapes.

If the master packet parameter is set, the master protocol and master
query parameters will be ignored.

<h4>Game Type Parameters</h4>

<table border=1>
<tr valign=top><td>name<td>Sets the name of the game type. Should be the full game
name as used by the publisher.
<tr><td>flags<td>set the query flags. Bitwise OR of the following constants:
	<ul>
	 <li>TF_SINGLE_QUERY</li>
	 <li>TF_OUTFILE</li>
	 <li>TF_MASTER_MULTI_RESPONSE</li>
	 <li>TF_TCP_CONNECT</li>
	 <li>TF_QUERY_ARG</li>
	 <li>TF_QUERY_ARG_REQUIRED</li>
	 <li>TF_QUAKE3_NAMES</li>
	 <li>TF_TRIBES2_NAMES</li>
	 <li>TF_SOF_NAMES</li>
	 <li>TF_U2_NAMES</li>
	 <li>TF_RAW_STYLE_QUAKE</li>
	 <li>TF_RAW_STYLE_TRIBES</li>
	 <li>TF_RAW_STYLE_GHOSTRECON</li>
	 <li>TF_NO_PORT_OFFSET</li>
	 <li>TF_SHOW_GAME_PORT</li>
	</ul>
 </td>
</tr>
<tr><td>default&nbsp;port<td>Default network port used by the status protocol.
<tr><td>status&nbsp;port&nbsp;offset<td>Offset of the status/query port from the game port.
<tr><td>game&nbsp;rule<td>The server rule containing the name of the game style or game mod.
<tr><td>template&nbsp;var<td>The template variable used to test whether a server is of this game type.

<tr><td>status&nbsp;packet<td>The status request packet. This is the first
packet sent to a server of this game type.
<tr valign=top><td>status2&nbsp;packet<td>The second status request packet. If the server
responded to the first status packet, then this packet is sent, but only
if player or rule info is needed (command-line options -P or -R).
<tr><td>player&nbsp;packet<td>The player request packet. Requests player
information.
<tr><td>rule&nbsp;packet<td>The rule request packet. Requests server rule information.
<tr valign=top><td>master&nbsp;for&nbsp;gametype<td>Sets the type of game returned by this master. The value must be a built-in or configuration defined game type.
<tr valign=top><td>master&nbsp;protocol<td>The protocol number to use in the master request.
The master server will respond with servers that match the protocol number.
The numbers change with each version of the game that uses an incompatible
network protocol. The master protocol is used mainly with Quake 3 based
games.

The master request packet will combine the master protocol and master
query values.

<tr valign=top><td>master&nbsp;query<td>The query string to use in the master request.
The master query string provides additional filtering for the master
server.

The default master request packet will combine the master protocol and
master query values.

<tr valign=top><td>master&nbsp;packet<td>The master request packet. Requests a server
list from the master server. If master packet is set, master protocol
and master query are ignored.
</table>

</body>
 
 
</html>