<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1106" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hello everyone,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I am happy to say that the initial testing I have
done with the Team-Kill detection logic has gone extremely well. The
biggest hurdle was to ensure that teams could be properly identified.
Without that, there just wasn't any way to determine if a TK event
occurred. Originally I had planned to use Mazzic's suggestion, the
sessionx command, but I hit a snag. Evidently, the command only
works for players who are already on the server and stay connected when the
new level loads. Then, only the starting team assignment is
reported. Any subsequent changes aren't shown when the command is
invoked. Needless to say, this was frustrating.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>The way I got it to work was by reading status
displays. In team games, players on a given team share the same score in
the status display. As soon as each team has different non-zero scores, it
is a simple matter of parsing the status display and recording the data.
The reason the scores must be non-zero is because a zero score can indicate the
beginning of a map, a player who is in the process of connecting or choosing a
team, or a spectator. The monitor logic pays attention to any requests to
change name, team, or change to spectator mode and removes the team assignment
for the player in question. The drawback is that deaths which occur when
teams aren't assigned cannot be evaluated properly. I had originally
thought of tabling death messages until teams could be determined, however there
is always the possibility that a player could issue a command to change
teams. Since the command doesn't report if the change is successful or
not, there is no sure way of knowing what team the player is on. The good
news is that team affiliations carry over from the previous map and I keep track
of everyone who hasn't asked to change teams.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I also decided to add some additional monitoring
features that detect server settings for the developer, g_gametype, and
g_teamdamage cvars and if they are changed at any time. If the server
settings won't support the logic, the TK processing is deactivated.
Similarly, if the settings will support the TK logic and the configuration file
has it enabled, the logic will activate automatically.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I want to do some more dry runs of the logic before
I feel comfortable releasing the new program, but I wanted to give everyone an
update. The bottom line is that I think I have a TK detection system that
works well enough to be practical. The next step is determining what to do
when a TK is detected. I am interested in hearing opinions on the
issue. In the meantime, I'll continue pounding on the logic and analyzing
the debug logs.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Shockwave</FONT></DIV></BODY></HTML>