OBJ games and player team detection

[[-SF-]Shockwave]

Hello everyone!

I've been working on the beta testing of the latest version of my server administration tool and have uncovered a situation that has caused me some difficulty and was wondering if I could get some feedback.  The issue has to do with how to identify what team a player is on by processing the messages sent to the game server log.

The main problem with implementing TK logic is this:

- The game server's log file doesn't record when players join teams.  It only records the command used to choose a team.

This creates two possible problems:

(1) A player asks to join a team using "auto_join_team"

(2) A player asks to switch teams but the mandatory wait period has not expired.

In the first case, the player is placed on a team and only "clientCommand: Shockwave : 1 : auto_join_team" is recorded in the log.  In the second case, the command to join a specific team might be used, but it will fail leaving no failure message in the game server log.  This could cause a team change to be recorded when it was never processed.  This is why I designed the tool to key off the status display.  Consider the following log output with the extra comments added automatically by the server tool I created:

map: dm/mohdm2
num score ping name            lastmsg address               qport rate
--- ----- ---- --------------- ------- --------------------- ----- -----
  0     5   80 [ -EVIL- ] Dr. Evil      0 68.60.207.204:12203   35849 20000
*** SCORE A: '5'
  1     4   48 Blake Dirge (CA)      0 68.81.98.14:12203     30482 10000
*** SCORE B: '4'
  2     5   63 Yeaterssm             0 12.217.80.91:12203       46  5000
  3     0   91 some dude             0 68.60.207.204:12204    2341  5000
  4     4   88 ^|BW|^Theone*Who*can't      0 24.53.27.85:12203     60436  5000
  5     0  999 stixxx2            5250 64.157.114.129:12203  23940  4000
*** UPDATING TEAMS...
*** TEAMS UPDATED
***     B - ^|BW|^Theone*Who*can't
***     A - Yeaterssm
***     ? - stixxx2
***     ? - some dude
***     A - [ -EVIL- ] Dr. Evil
***     B - Blake Dirge (CA)

As the status display is parsed, the tool looks for two distinct non-zero scores and records them if it finds them.  Since in TDM each kill by a player on a team is shared by every other player on that team, if both teams have different non-zero scores, they can be identified.  Players who have scores of zero are either connecting to the server, spectating, or in the process of disconnecting so they can't help with the determination.  In the example above, the program identified that there is a player with a score and it saves it as the score for team "A".  After reading the next line, it finds a different non-zero score and records it for team "B".  It then finishes tabling all the lines, does some calculations, and places each of the players on the two teams that can be identified producing the display you see above after the status display itself.

Since player team affiliations stay the same from level to level, only players who join when teams cannot be determined remain "?" in the team identification tables.  These tables, along with logic that identifies and parses death messages, form the foundation of the program's ability to identify TK'ers.  This works just fine for TDM, but OBJ puts a spin on all of this.

For OBJ games, player scores are shared just like TDM, but the scoring is handled differently.  Individual player kills do not show in the status displays, only matches won.  This presents a problem because teams cannot be determined until each team has different non-zero scores.  Potentially, given a very successful team, an entire series of matches can be played with the opposing team scoring no points at all.  This means that TK'ing can occur and the tool is unable to do much about it.  Because of this, I have been thinking of new approaches to team identification that will work for both TDM and OBJ games with equal proficiency.

The first thing I thought of trying was generating a message in the game server log that would indicate what team a player joined.  After all, the message is printed to the game screen and I figured that I might be able to redirect that information to the server log.  Unfortunately, it appears that the information I require to make that modification is proprietary and hasn't been released yet.  I then tried to figure out a place where I could force some other error message to occur (such as the attempt to load non-existent texture files named "join_allies" and "join_axis") when a player joins, but I was unable to find a script that is executed when a player specifies a team change.  Additionally, even if I can find such a script, the information won't have the player's name attached so I'll be forced to hope that the log information is recorded sequentially by each player that makes such a request and is not intermingled with messages from other players with similar requests in order to properly attribute this false error message data to the appropriate player.  All things considered, it doesn't look very promising.  If anyone knows of a modification that can be made that will do this, please tell me.  It would also be helpful if the exact variables that hold player information could be manipulated so a custom log message can be crafted, but I think that might be hoping for too much.

After my unsuccessful attempts at finding ways to manipulate the game server software, I came up with the following ideas to eliminate the two obstacles that make team determination difficult:

(1) Eliminate the ambiguity of the "auto_join_team" selection by removing the ability for a player to choose that menu option.

I found the scripts that create the menus used in the game and potentially these can be manipulated to remove the functionality of the button that allows for the selection of the automatic team assignment option.  I'm going to test it, but since I'm not very familiar with the game server files and how the whole thing works, I might not be successful.  It also might not be something that can be implemented server-side only.  In any event, I'm willing to try.

If that doesn't work, I've thought of two other options:

(a) It is possible to use the "spectator X" command from the console, where X is the client ID, to force players who choose the "auto_join_team option to be spectators.  This logic can force players to explicitly choose a team or they will be placed back into the spectator queue.

(b) Once a player joins the game, the tool can automatically assign a team to the player using the "join_team allies" and "join_team axis" console commands.  The incoming player will then be confronted with the weapons choice menu.  Trying to change teams at this point would cause the logic in the option below to take effect.  This would also come in handy trying to balance teams.  I've never been able to get the game to honor the "g_forceTeamBalance 1" setting anyway.  

(2) Eliminate the possibility of a failed team selection by making the tool handle that function.

It is possible for the tool to timestamp individual team selection requests and force anyone to join the spectator queue who hasn't let the mandatory waiting period elapse.  Any waiting period will be reset if a player chooses a team while it's active.  Since the tool will take longer to process the game server log data and calculate the wait interval than the game server itself, there should never be a case where a team selection will be sanctioned by the tool, but denied by the game

-------

So far, that's what I have been able to brainstorm for fixes.  I would greatly appreciate any feedback.  I'm not only looking for alternative approaches, but also whether any of the ones that have been mentioned so far are reasonable as far as player acceptance is concerned.  Although TK'ers are a scourge, I don't want to cause any more grief trying to fix the problem they create.  In the meantime, I have created a windows-friendly version of the README for the tool and have created a page on my site where both it and the Unix formatted version can be obtained if anyone is interested in learning more about what the tool does:

http://www.clanshortfuse.com/mohaa_admintool.shtml

Thank you all very much for your time and attention.


Shockwave




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/mohaa/attachments/20021010/446bbca6/attachment.htm>