[bf1942] XML Event Logging

Forrest Thiessen thiessen at alum.mit.edu
Wed Apr 7 12:30:59 EDT 2004

Hello Andy!
Well, since you asked. . .
This is my combined "grocery list" of bugs/features for XML logging for
both BF1942 and BFV; some of these comments are specific to one engine
or the other, some apply to both.  If you're not involved with the
BF1942 code, I'd be grateful if you could pass this along to whoever
is-both so that the problems in BF1942 logging can be fixed, and so that
the BF1942 and BFV log formats can continue to be compatible with one
Let me make one overall comment:  please try not to break anything!
There are several parser programs already in use by the community, and
more on the way; when BFV came out there were surprisingly few changes
needed (at least in my parser) to deal with the differences from BF1942,
but one of them, the change to the bf:log tag, was ugly, needless, and
not the correct usage of XML., and made extra work for us that are
trying to make player stats work for BFV (my comments on it are the
final thing in item in the lists below).  Every one of the bug fixes /
new features listed below can be handled without needing require anyone
to recode anything in their parsers, unless they want to take advantage
of new functionality. . . except fixing the bf:log tag, even the act of
fixing which would break most or all of the parsers again!  So, my
suggestion: please consider the effect of any changes you want to make
on the existing parser/stats systems that people have already written!
Your comment about "reworking" some of the events particularly scares
me-except for the bugs listed below, the existing events are fine!  8086
machine code is butt-ugly, but somehow it's managed to evolve to higher
levels of functionality without killing everything that depended on its
original design!
So here are my lists:
1.	The Windows BFV server logs nothing but chat events, which is
completely useless, even for recording chat, since you can't tell which
player is mapped to which player ID.  The Windows server needs to be
"fixed" the same way the Linux BFV server was.
2.	In BF1942, radio messages sometimes (but not always) are shown
as coming from wrong player_id.  Haven't verified yet if this also
happens in BFV.
3.	There are two different formats for the destroyVehicle event in
BF1942 (haven't checked to see if this applies to BFV); this doesn't
seem harmful, but is likely a bug.  One looks like this:
<bf:event name="destroyVehicle" timestamp="29.1746">
    <bf:param type="int" name="player_id">232</bf:param>
    <bf:param type="vec3"
    <bf:param type="string" name="vehicle">
    <bf:param type="vec3"
and the other looks like this:
<bf:event name="destroyVehicle" timestamp="29.1746">
    <bf:param type="string" name="vehicle">IraqSoldier</bf:param>
    <bf:param type="vec3"
4.	In Objective Mode games, scoreEvents for achieving an objective,
or TKing an objective, are not generated, but are counted in score (5
score points).  This applies to both the BF1942 engine (which at least
has "placeholders" for counts of these objectives in the roundstats
structure (although they aren't populated), and the BFV engine, which
doesn't even list them in roundstats.
5.	In BF1942 the game mode is always logged wrong; it's always
shown as "GPM_CQ", even when the mode is Co-op, for example.  (This is
fixed in the Linux BFV server).
6.	Victory type is always logged as "4" in BF1942, despite the real
victory type (it is fixed in the Linux BFV server).
Improvements Desired (both BF1942 and BFV):
1.	No event is generated when the game is paused or unpaused-both
pause and unpause should generate log events.
2.	Console messages (game.sayall) are not logged, but should be,
just as the chat and radio messages are logged.
3.	No IP addresses are currently given in the logs' player data.
Having the CD Key hash is nice, and useful, too, but I'd really like the
IP address, also-otherwise you have to go try to find it by matching up
against the PunkBuster logs.
4.	There is currently no logging of vote activities (such as map
change or kick player).  That would be useful in tracking down abusive
players-please add it.
5.	Log file time and date information isn't recorded in the file
anywhere-you can only get it from the name of the file.  The current
system is workable, but it means you can never rename your log file, and
sometimes that's desirable.  It would be much better to also record the
time and date that the log was started as an attribute in the bf:log
6.	When a game ends, there isn't any indication of why it
ended-time limit reached?  Score limit?  Manual map change?  Map vote?
7.	There is no way to tell when a log file is being written by a
server, so users of log data need to either always leave the latest file
in a directory untouched, for fear it is being written, or they need to
use rcon to do a direct server query to ask the server which log file is
being written.  Suggestion: rather than getting into complicated
semaphores or locking protocols, when the log file is created, the
server should name the file something that can't be confused the name of
completed log file (example: instead of "ev_14567-20040218_1939.zxml",
name it "temp_14567-20040218_1939.zxml".  When the game completes and
the server closes the log file, rename it to it's normal log file name
("ev_. . .").  Besides being easy to do, it has three advantages: (1)
parsers can tell when a log file is ready to be scanned, unlike the
present system; (2) when the server crashes and leaves the log in an
improper XML state, that file never gets renamed, and never has to be
dealt with by a parser; (3) programs that are using the log file to
carry-out real-time control over the server (for example, to
automatically ban players who are using "inappropriate" language) can
easily tell which file they should be monitoring.
Odd things, but not necessarily bugs:
1.	Vehicle destruction is logged, but vehicle spawning is not;
that's not really a problem, but it might be nice to have the extra
2.	Healing at a medical locker isn't logged (but then, neither is
getting damaged, so maybe it doesn't matter).  Same thing for vehicle
repair by repair pad.
3.	The <bf:log> tag is a dog's breakfast; it's perfectly valid XML,
but not the right way to do things, and the way it's currently
implemented makes needless work for parser programmers.  It's got a
version number and specifies a namespace that includes a second version
number, and specifies two contradictory local identifiers for the
namespace, depending on the engine used-ugh.  When you look at the logs,
it's clear that there is no need for multiple namespaces, as both BF1942
and BFV use the same XML tags.  Further, there are no qualified names
used in the logs, so there is no need for the two different local
identifiers used ("bf" and "bfv").  A much cleaner way to do things
would be to add an attribute that specifies the engine being run, and to
use the version attribute to refer to the log format version for that
engine, and the version number in the namespace name to refer to the
version of the (seldom changing) namespace, thus:
<bf:log version="1.1" engine="bfv"
Note that making this change to bf:log will once again break all the
parsers already in existence. . . for that reason I think a good case
can be made for just leaving it the way it is; however, if there's a
chance there will be more versions, engines, or namespaces in the
future, I think it would be worth it to "bite the bullet", make the
change now, and just get it over with.
Hope that's helpful!
Best regards,
--Forrest (aka Woodrow)
  thiessen at cyberscapearena.com
-----Original Message-----
From: Andy Berdan [mailto:andy.berdan at dicecanada.com] 
Sent: Wednesday, April 07, 2004 8:51 AM
To: bf1942 at icculus.org
Subject: [bf1942] XML Event Logging
Hash: SHA1 
For those who don't know already, I've taken over the dedicated server
duties from Peter (dpc). 
I've begun work on updating the XML Event Logging, and I've started to
rework some of the events, since BFV is a bit different than '42.  :)
It occurred to me that I probably wouldn't think of everything, and
since the admin population in the studio approaches zero, I'd post a
request for events.  So, what's missing?
Note that I will take all requests as just that... requests.  Some ideas
may be difficult and/or impossible to put in place in the time I have
For reference, here's the list of events from 1942: 
scoreEvent (FlagCapture, Attack, Defence, Kill, Death, DeathNoMsg, TK,
Version: GnuPG v1.2.4 (MingW32) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/bf1942/attachments/20040407/3e5a2731/attachment.htm>

More information about the Bf1942 mailing list