Frequently asked questions
==========================

Last updated 26/7/99 for v1.08
------------------------------

Q. I want to run Fragstats for my Quake 2 server. How do I do it?
A. If you are using CTF or RA, they have logging built in. Otherwise, download
   a mod which enables Frag logging; eg. GS log mod, ServerConfig Mod or Lithium
   (see fragstats.txt for where to get these).
   Set them to generate Frag logs (or Stdlog.log). Configure Fragstats for the appropriate
   log style, and you should be set.

   As of v1.06 you can record and display any special bonus scores recorded using the GS
   log standard. See the templates.txt and fragstats.cfg files.

Q. But I don't like GS log mod, ServerConfig Mod or Lithium because <insert reason here>.
A. There are other mods that generate logs. Check them out. If they generate GS or QW
   style logs, Fragstats can work.

Q. Hang on, what about TRIBES?
A. Syn and Dude over at the D0gz Pack have written a tool for TRIBES that will let you
   generate stats via Fragstats or any other GS log parser. You can download
   Tribestats from http://quake2.d0gz.net

Q. How do I find out what special bonuses are recorded by my mod?
A. Check the mod docs to see what they record. If they're not clear (or non-existant),
   run Fragstats against your logs and have a look at the console output it generates.
   Any special bonuses that are found in the logs will be shown there. I've even made
   the output formatted so you can cut and paste it straight into your config file.

Q. How do I use the user defined tags once I have them defined?
A. You use them just like any of the inbuilt system tags. Check out the default templates
   included in the package.

Q. Can you please explain how Frags/Deaths/Rank/Efficiency/Suicides/Skill/Duel is
   calculated?
A. Check out:
   http://quake.tip.net.au/statsexp.html
   for an explanation of these statistics.

Q. I've set up Fragstats and can get the HTML output, but can't get Qplayer to produce
   individual statistics. Can you help?
A. 1. Make sure your CGI directory is set up correctly.
   2. Make sure you've specified the correct path for cgidir and URL mapping for cgiurl.
   3. Make sure the players.db & victims.db files are in the CGI directory.

Q. The name search facility in the sample scores.html doesn't work. Why?
A. 1. Check the above steps first.
   2. Make sure you've modified the scores.html file, changing the action statement in
      the form to reflect the correct URL mapped location and name for Qplayer.
   3. If it still doesn't work, try changing the method statement in scores.html to GET
      rather than POST. The Apache web server is one web server I know of that doesn't
      support the POST method.

Q. I keep getting a 'Cannot open players.db' message from Qplayer. Why?
A. If you are using Website or IIS 3/4, there is a known problem where Qplayer's working
   directory doesn't default correctly to the CGI directory correctly. New with 1.08,
   you can avoid this problem by setting the environment variable CGIDIR to path
   containing the database files. For NT, you need to do this in the system environment
   section for all users:

   CGIDIR=<path to the directory containing the database files>

   For Unix, set and export according to your shell type, preferrably in the script
   that starts your web server. For Windows 9x, set it in your autoexec.bat file.

   This variable must be set prior to your web server starting, otherwise it will not
   be visible to Qplayer.

   NOTE: If you are running multiple CGI directories containing Qplayer, you will
   need to wrap qplayer in a shell script or batch file, setting CGIDIR prior to
   actually calling Qplayer.

Q. I get a message from Qplayer saying 'Wrong database version'. Why?
A. You either need to reinitialise your database or update your version of Qplayer.
   In the first case, delete the last.dat file and re-run Fragstats.

Q. Why do I get an 'Error parsing' message in the Fragstats output?
A. You have some records in your logs which have been truncated or malformed due to server
   crashes, they haven't been written out to disk yet or perhaps a bug in the Q2 mod you
   are using. This message is just a warning, ignore it.

Q. My HTML editor screws up the Fragstats tags, eg. <?server> becomes &lt?server&gt.
   What can I do?
A. Try using the alternate tag mechanism, eg. <!--server-->. This should not be messed
   up by your editor. One known exception to this is in the <TITLE>...</TITLE> field.
   You can always modify the HTML by hand (ouch).

Q. I'm running a recent version of Ret Hat Linux and the date displayed by Fragstats
   seems to be out by several hours. What can I do?

A. A few people have noted that Fragstats on recent RH linux versions doesn't seem to
   take into account the timezone when displaying the date. I don't know why this is,
   but suspect a bug in RH Linux.

   Workaround #1 (Thanks Ian Dobson)

   "I noticed it the faq you have a way to fix the date for Fragstats..
   The reason the date is incorrect in the first place is that a bug exists
   that was in RH5.0 and carried thru to 5.1 and not updated there either..

   Simply by creating a link to the correct timezone info fixes it, not
   just for fragstats but for all other programs as well
   the fix is:

      login as root

      ln -s /usr/share/zoneinfo /usr/lib/zoneinfo

   thats it :)"


   Workaround #2 (my original method)

   1. Define a user defined tag in your config file that references a file to include
      in your HTML, eg.

      deftag realdate as file "/tmp/fragstats.date"

   2. Modify how you run Fragstats so a new date is written to the file
      /tmp/fragstats.date every time you run Fragstats, eg. In a script:

      date > /tmp/fragstats.date
      fragstats

      The modification above takes the output from the date command and redirects
      output into "/tmp/fragstats.date". Fragstats runs immediately after you've
      extracted the date into "/tmp/fragstats.date"

   3. Use the tag you defined above (ie. <!--realdate-->) in your HTML templates
      instead of the <!--date--> tag. You should then end up with the current date
      (as produced by the date command) inserted into your HTML.


Q. Is there an easy way to combine the stats for two or more servers?
A. It's possible, but takes a little fiddling to get right.

   The key is to make sure they don't run at exactly the same time and that you ensure
   that they keep a separate track of where they are in their respective log files.

   So, say you have 2 servers: server1 and server2 which you want to produce one set of
   stats for. They have separate logs files, stdlog1.log and stdlog2.log. I'm assuming all
   the cfg settings not mentioned here are OK - you still need to make sure the other
   options are set correctly.

   Steps to take:

a. You need a config file for each server. Copy fragstats.cfg to server1.cfg &
   server2.cfg. The names aren't important. By default, Fragstats looks for
   'fragstats.cfg' as it's config file. However, you can tell Fragstats to use
   another file, like so:

   fragstats config=server1.cfg

   Will cause Fragstats to use server1.cfg as it's config file.

b. Edit these cfg files (I'll call them 1 & 2 for convenience).
   Set the 'lastscanned' filename to be 'last1.dat' in 1 and 'last2.dat' in 2.
   The 'last.dat' files are used to keep information about where Fragstats was
   in the log file.
   Make sure that the 'htmldir' setting in 1 matches the 'htmldir' in 2.
   Make sure that the 'cgidir' setting in 1 matches the 'cgidir' in 2.
   Make sure 'logdir' in 1 is set to the directory containing the server1 logs.
   Make sure 'logdir' in 2 is set to the directory containing the server2 logs.
   If using GS logs, set 'gslogname' to 'stdlog1.log' in 1 and 'stdlog2.log' in 2.

c. Run Fragstats for server 1:

   fragstats config=server1.cfg

   It will run Fragstats with the server1 configuration, generate HTML and create
   the database. The position last read in the 'stdlog1.log' file is saved in
   'last1.dat'.

d. Run Fragstats for server 2:

   fragstats config=server2.cfg

   It will run Fragstats with the server2 configuration, generate HTML and update
   the database that was created for server1. The position last read in the
   'stdlog2.log' file is saved in 'last2.dat'. Note that it will overwrite the HTML
   pages generated for server1, but it will be with pages that have both server1 and
   server2 data.

   You now have a database & HTML pages that include data from both servers!

   Next time you want to update the stats, repeat c. and d. again. The second time
   through, c. will simply update the database that is there already rather than create
   it. You can automate c.and d. by just creating a script/batch file that runs one and
   then the other, eg.

   #!/bin/sh Fragstats dual server script
   cd /usr/quake/fragstats
   ./fragstats config=server1.cfg
   ./fragstats config=server2.cfg

Q. I don't like that way, and besides, I'm using QuakeWorld!
A. Try this out - thanks to Sparkey (sparky@quakefiles.com)

   For Win32, change to suit for Unix.
   Assume Fragstats is located in c:\fragstats and we have two servers, qw1 & qw2. These
   servers write their logs to two directories, c:\quake\qw1 and c:\quake\qw2. Configure
   fragstats.cfg setting logdir to c:\fraglogs.

   Run c:\fragstats.bat which contains:

      cd \fraglogs
      del *.* /q
      rem - This combines all the stats into one file
      copy c:\quake\qw1\frag_*.log + c:\quake\qw2\frag_*.log c:\fraglogs\frag_0.log
      cd \fragstats
      fragstats

Q. How gan I get rid of those irritating names such as 'Player' and so on?
A. Fragstats doesn't let you delete players from the database yet.
   As a workaround, alias the offensive names to something else, eg.

   alias "Idiot" with "These" "Names" "Will" "Be" "Changed"

   See the fragstats.txt and fragstats.cfg file for details.

* END FAQ *