More BFV XML Bugs, and Some Oddness
thiessen at alum.mit.edu
Sun Mar 14 23:06:15 EST 2004
Peter: This is soooo cool to have a Linux server pretty much ready when
the games releasedthanks for all your efforts!
Ive been studying the XML event logs generated by the server (various
versions, but Ive checked the following on the latest version, too),
and have the following comments:
1. BUG: roundInit events are missing from the logs. In BF1942, they
look like this:
<bf:event name="roundInit" timestamp="276.721">
<bf:param type="int" name="tickets_team1">375</bf:param>
<bf:param type="int" name="tickets_team2">375</bf:param>
These events occur early in each round and mark the actual start time
each round; that "actual" start time can be just after the timestamp
the beginning of each <bf:round> tag, or it can be a minute or more
depending (I guess) on how fast things initialize. Without the
event there is no way to tell when gameplay actually starts, and so
statistics will have to be based on the <bf:round> timestamp. . . and
therefore show the round duration as having been longer than it
Can we please have roundInit events back?
2. BUG: There is a bug in BF1942's XML logs that causes victorytype
in the <bf:roundstats> structure at the end of every round to ALWAYS
That same bug appears to be present in BFV. Even though it's a bug
"inherited" from BF1942, it sure would be nice to fix it (like you or
someone else apparently fixed the bug in BF1942 that caused all games
be logged as "GPM_CQ", even when they weren't--the mode reporting
works correctly in BFV's XML logs).
3. WEIRDNESS: The semantics of flag captures have changed from the way
they are handled in BF1942; it's definitely incompatible, but whether
a bug or not. . . (maybe it's a "feature"?). In BF1942, flag
all play modes other than CTF are denoted as "Attack" scoreEvents.
BF1942 CTF mode, flag captures are reported as "FlagCapture"
In BFV, however, any kind of flag capture is reported as a
scoreEvent. That's probably ok and can be dealt with, but it's
a change from how BF1942 behaved. Is there a reason to change the
type of flag captures? If not, could we leave them as "Attacks" so
be compatible? (Note that BFV also introduces a new "Defence" (yes,
misspelled) scoreEvent type that is generated by something to do with
but I haven't figured out yet--probably something to do with the new
behavior of flags in No big deal--it seems unrelated to the
Attack/FlagCapture issue). (Note 2: BF1942 and BFV both seem to have
"Objective" and "ObjectiveTK" scoreEvent types; I haven't been able
them in BFV yet, but they are definitely *BROKEN* in BF1942--I can't
them to be produced for anything, even in Objective-mode Secret
maps; hopefully they work in BFV, if not, that will be a bug, too).
I'm leaving out from this list things that should be in the XML logs,
but aren't in BF1942, and I'm guessing aren't in BFV, either (things
like no logging of game pauses, of operator messages ["game.sayall"], no
logging of map or kick votes, no record in the log of date and time [you
have to get it from the file name], and no reliable way to tell which
log file is currently active, if any, etc., etc.). Presumably, those
are things could be addressed in release 1.1 of the server (or 1.2, or
1.3. . .) since they are "new" features, rather than "bug" fixes.
thiessen at cyberscapearena.com
From: Peter Chang [mailto:peter.chang at dicecanada.com]
Sent: Sunday, March 14, 2004 4:38 PM
To: Bf1942 at Icculus. Org (E-mail)
Subject: [bf1942] bfv five-by-five
yes, it's true, this man has no life...
in an effort to have a 'release' w/ no known major issues i present...
the later only have binary thingees (the exes and the pb .so's) along w/
the readmes etc since the content hasn't changed.
check the readme to see if your favorite bugbear has been addressed, but
this will be the *LAST* interim release (unless a 16-ton weight drops on
my head) and v1.0 should be considered baked. this is especially true
since there should be clients soon.
More information about the Bf1942