looking for background information?

the faq

log parsing, stats calculation and output are not always that simple to do. here i try to explain some things you might as yet not be aware of.

the history of æstats⁺⁺?
why does the æstats⁺⁺ package have three parts?
what are the meta log files for?
what's the policy on supporting new games?
how do i send in bug reports?
what's with the copyright?
is the source code available?

the history of æstats⁺⁺?

ages ago... about 5-6 months after quake was released, a few friends and i thought it would be nice to have, ranking and player statistics for quake. as it is my habit ;), i did not look around if there where other parsers out there (gibstats was here i think), and wrote my own log parser. the main things i wanted were: 1. html stats output, 2. automated as much as possible, 3. modular, to make enhancements easy, 4. portable code... and some other things.

the 1st generation parser was written for quake and coded in amiga arexx (a script interpreter language, a bit like perl, only that with this language you can control an editor or graphics applications). the stats where nice, i even had ranking progress plots (done with gnuplot)... something even the 4th generation parser does not have, but i am finally planning to add in the 5th...

the 2nd generation parser aeqs was written for quake ii (lithium mod and rocket arena ii support). i changed a lot of things in this generation. the code base migrated to ansi c (using lcc under w95 and gcc under linux). html output became completely automated, and due to the c code, it was pretty fast.

the 3rd generation parser was an adaption of the aeqs parser, this time for unreal and called aeus. nothing much was changed, well sorta ;)... i re-wrote most of the code, to make it even more modular. unreal differed from quake/ii in the point that it did not support frag information output to consoles. i therefore had to write an unreal script module called aeonsdmmod.u to make things work. for the first time i could control *what* information a game should output. the info included: time, date, mapname, weapons both players had in hand just when the frag happened, health for both players, items in hand (extras), if they where using the weapons in alternate mode, ...

the 4th generation parser package was called æstats. what made this generation different is the support for just about every game that runs on quake ii, quake3arena or unreal engines *and* was a death match type of game. this package worked fine for many many years. but there comes a time when a programmer has to move on, to support even more cool stuff.

this 5th generation parser package is called æstats⁺⁺ and is written in d. it will be even more modular, support ctf and other mods, have log history (via mysql), completely new html output design (php), be skinable (of sorts via style sheets), have improved support for player names (banning, ip-tracking, prohibit faking), be extensively configurable e.g. obituaries are now in an external file and... much much more. for an overview be sure to check out the features page on this site.

why does the æstats⁺⁺ package have three parts?

after serval generations (1st to 3rd) of parsers with only one executable, it became quite clear that cramming everything into one source tree would soon lead to code hacking on my part, just to add that one more feature. this became very apparent with aeus that would not let me add quake 3 arena support, without totally re-writing the code.

with æstats i started to separate the preparser code from the stats calculation and html output. this separation into two modules worked fairly well, since the aestats package is even today, after so many years, useful. but there is nothing that could not be improved on.

now with æstats⁺⁺ i separated the code base even further. this time into three distinct modules: the parser module, the stats module and the output module.

the parser will read just about any log file format (e.g. id software and epics engines,...) and convert it into the so called "meta log" format. this very strictly defined format is more or less the same for all games.

the stats module will then read the 'simplified' meta logs and calculate all the stats. this time round all the infos will not be held in memory, they will be saved into files (probably mysql database). this way each player will build up a gaming history, that can then be plotted.
note: once the data is in the history files, you will no longer need the original log files or the meta log files. this should save some disk space.

the job of the output module is to read the pre-calculated data provided in the history files (mysql database) and generate nice html output. this will be done by php code. the main reason why i am separating this module now, is that it will force me to write cleaner code, more modular tables etc. this will make it easier to enhance the output on the fly.

so you see, i use three modules to improve the adaptability of the source code. to make future enhancements less time consuming.

what are the meta log files for?

as long as each game comes along with slightly different log output for in-gaming frags and other infos, there is always a lot of 'unsound' hacking involved in the code base, to make things work. if on the other hand a new log file 'intermediate' format is used (like my 'meta log' format), then when a new game appears, i merely need to change the parser code. the other two modules will not need to be changed, so that stats and output will be available for that game practically right away.

the other advantage... the parser filters out all the junk that server log files include and that is of no use for stats. thus slimming down the amount of logs you might want to collect.

furthermore since the 'meta log' format (as seen in æstats) is plain ascii (the [t] is a tab or ascii 9):

  [date time]  [t]
  [mapname]    [t]
  [player1]    [t] [player2]  [t]
  [damagetype] [t]
  [weapon1]    [t] [weapon2]  [t]
  [altweap1]   [t] [altweap2] [t]
  [health1]    [t] [health2]  [t]
  [item1]      [t] [item2]    [t]

the format will make it possible to use powerful database programs, to calc stats. there is one line of log per frag/death/suicide, which makes it a lot easier to parse as compared to the original log files. most games will not provide that much information alas... :(

for more details on the meta log format, see the parser page on this site.

note: under æstats⁺⁺ the meta log format will be a lot more complex, adapting more readily to the data that the games provide.

what's the policy on supporting new games?

well it's quite simple. you send in log files for a game you deem worthy of stats support and i will see what i can do about it :).

so far i have been supporting just about every game that uses id software or epic engines. since half-life and especially counter-strike are still very popular, supporting cs will be a priority.

if you would like a certain game supported, send me an email from the requests or directly from the send logs page.

how do i send in bug reports?

well anything that gets programmed is likely to contains bugs. this is also true for æstats⁺⁺, so if you find any, don't hesitate so send me an email on the subject.

check out the bug reports page for details.

what's with the copyright?

copyright is with me (christoph 'aeon' loewe (c) 1998-2009). all rights reserved.

may the template pages for html output be changed?

yes. that's the reason i made them editable. but it would be nice if you would reference this site (aeons.poweredbylasers.com/aestats++), e.g. keep the last 'advertising' line on each page. this let's me help others that might also be interested in æstats⁺⁺.

see the legal page for more details.

is the source code available?

at this time the source to the æstats⁺⁺ package is not publicly available. i would like to keep control of the project.

if you are missing something then send me an email from the requests page.

last updated on wednesday, may 18th 2005 up since: sunday, october 23rd 2000 re-design: monday, may 16th 2005