[mohaa] Admin Tool UPDATE - TK logic functional

[John Dubois]

Hey Shockwave!!

Awesome work!!

My suggestion for what to do when a TK'er is detected are:

1. print a message for everyone - say "MrBadAss has committed a Team Kill, 1 more offence(s) and you will kicked and banned, consider this a warning!!"

If "MrBadAss" commits another team kill: (or as many as he is allowed)

1. print a message for everyone - say "MrBadAss is a TK'er and will be kicked and banned from the server... NOW!!"
2. clientkick "7" (MrBadAss's client number for example)
    OR
    kick "MrBadAss"
3. enter "MrBadAss" ip and name to the banned file(s) (if I remember, I think you might have said were maybe going to prevent TK usernames from connecting as well?)

I guess you could use user friendly variables (like in your first beta script) to adjust the number of warnings a player will get before getting kicked,
as well as customizing your own messages:

TKwarnings=3
prewarningmessage=has committed a Team Kill,
postwarningmessage=more offence(s) and you will kicked and banned, consider this a warning!!
TKkickedmessage=is a TK'er and will be kicked and banned from the server... NOW!!

What do ya think?

I believe warnings are in order before taking any action because:

Sometimes we all, by no fault of our own, kill a team-mate completely by accident, either we were shooting in a crowd and some stray bullets get away during all the bobbing and weaving that occurs during the heat of battle.... or your own player runs into your line of fire..... or you throw a grenade for the opponent and out of the door pops yer team-mate and BOOM!! both are killed...OOPS!

So I think having the warning message number decrement by 1 with every infraction before finally kicking them is only fair.... what do you think?

ps. can't wait to try your next release out!! keep up the good work!!

John Dubois C.E.T, IT
  ----- Original Message ----- 
  From: [-SF-]Shockwave 
  To: mohaa at icculus.org 
  Sent: Monday, September 23, 2002 10:41 PM
  Subject: [mohaa] Admin Tool UPDATE - TK logic functional


  Hello everyone,

  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.

  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.

  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.

  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.


  Shockwave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/mohaa/attachments/20020924/ffcd0031/attachment.htm>