Not calculating UT99 multi-kills correctly?

[WhiteHowler]

Using UTStatsDB version 3.02

I parsed several logs from my UT99 LAN matches, and while everything else seems to be appearing correctly, it doesn't seem to be showing any multi-kills of any type. I personally had several multi- and ultra-kills during our games, so there should definitely be some logged.

For example, these two lines from the log file:

Code: Select all

60.83 kill 9 GES Bio Rifle 4 Rocket Launcher Corroded 60.83 kill 9 GES Bio Rifle 3 Rocket Launcher Corroded

This should definitely result in a double-kill tallied for that player, but none are listed in the match stats or the player's individual stats.

Any ideas? I can send copies of our log files if you want them -- I would have attached one to this thread, but it doesn't like .log or .txt extensions.

Other than this one issue, my UT group is having a blast with being able to see their stats. Thanks!

[Panther]

UT '99 doesn't log multi-kills, so you must enable Multi-Check in the log configuration.

[WhiteHowler]

I just verified that Multi-check is set to "True", but multikills still aren't being tracked for some reason (I even cleared the DB and re-parsed the logs just to be sure). ut_configlogs.multicheck is definitely set to 1.

I also noticed one other thing: The last four sections in "Career Highs" (career kills/deaths/deaths holding/suicides -- all by weapon) aren't being populated at all, but UT99 logs enough data that these can be calculated.

If you'd like to examine these issues further, our UTStatsDB site is located at http://idlemindsradio.com/utstats/index.php. I can also send you copies of the log files from the matches we've played so far if that would help.

Thanks for the help, we're really enjoying our new stats site.

[Panther]

Please post some logs (you can send them in an attachment in a PM if you prefer). Be sure to use some sort of compression utility on them.

[WhiteHowler]

Okay, I PMed you a link to grab them (the forum software doesn't seem to like .zip files either).

Thanks!

[Panther]

I fixed the issue with the board not accepting .zip files (or other archives) in private messages. I'll have a look at the logs.

[Panther]

I had no problem with multi-kills or the Career Highs you mentioned - only the Weapon Specials section had nothing listed. For further support you'll need to post additional information about your system per the notice here:
viewtopic.php?f=3&t=2

[WhiteHowler]

Sure thing... Keep in mind that I don't have any direct access to the webserver -- I'm renting hosting from another company.

UTStatsDB version: 3.02
Operating system and version: FreeBSD 5.3-RC1
Database type and version: MySQL 5.0.41
PHP version: 4.4.7
Web server and version: Apache 1.3.39

I think some of the problems I'm seeing in Career Highs are being caused by player merges not updating the ut_totals table correctly. For example, if you look at the player listing on my site and then compare the kills/frags/suicides totals with what's on the Career Highs table, it's completely off.

The people with the top two highest kill totals on the Players list have been merged from old names -- the next person down has never been merged, and is listed as the top kills total on Career Highs, despite (correctly) having a much lower kill count in ut_players).

My suspicion is that this will work itself out next time I parse a log file. Does the ut_totals table get re-generated using the data in ut_players each time a log is parsed? This seems like the only way to keep it accurate.

[Panther]

Career highs are not recalculated upon a merge. It simply replaces the player IDs where they have changed, but does not calculate the highs based on the new player totals. They would be recalculated the next a log is processed for a match that that particular player participated in.

[WhiteHowler]

Career highs are not recalculated upon a merge. It simply replaces the player IDs where they have changed, but does not calculate the highs based on the new player totals. They would be recalculated the next a log is processed for a match that that particular player participated in.

Okay, makes sense to me.

Any idea why my multi-kill tracking isn't working? This seems to be the case regardless of whether players have been merged or not. I once again verified that Multi-Check is enabled, but no luck so far.

[Panther]

No, I don't know why multi-kills aren't working for you since they show up fine when I parse the maps you sent me.
For example on the first match in DM-turbine (Thu, Feb 21 2008 at 12:14:00 PM) there were 12 double kills.

[WhiteHowler]

No, I don't know why multi-kills aren't working for you since they show up fine when I parse the maps you sent me.
For example on the first match in DM-turbine (Thu, Feb 21 2008 at 12:14:00 PM) there were 12 double kills.

Hmm, okay... If you can tell me where in the code it actually calculates the UT99-type double kills, I can try to insert some debug code and maybe figure out what's happening.

I'm fairly competent with PHP, but trying to read through the parser code makes my head hurt.

Edit: Found it under tagut_kill() in logutevents.php. I'm going to have it output data for each kill parsed (time, current multi-kill status/kills, and previous multi-kill start time) and see what happens.

[WhiteHowler]

Okay, I've figured out part of the problem.

In tagut_kill(), we've got this code (ignore my debug messages):

Code: Select all

  // Track Multi-Kills for Killer echo "<br>Killer: ".$killer." | Victim: ".$victim." | Time: ".$time." | Last Kill: ".$multi[$killer][2]; echo " (".($time - $multi[$killer][2])." ago)"; echo " | Kills this Multi: ".$multi[$killer][1];   if ($time - $multi[$killer][2] < 400) { // Within multi range     if (!$multi[$killer][1]) {     echo "<br><b>Start Multi-Kill at</b> ".$time;       $multi[$killer][0] = $time; // Start Time       $multi[$killer][1] = 1; // Kills     }     else {       $multi[$killer][1]++; // Kills     echo "<br><b>Multi-Kill (".$multi[$killer][1].") continues at</b> ".$time;     }     $multi[$killer][2] = $time; // Last Kill Time   }   else {     endmulti($killer, $time); // End Multi-Kill for Killer     $multi[$killer][0] = $time;     $multi[$killer][1] = 1;     $multi[$killer][2] = $time;   }     

The problem is, if a kill isn't a multi-kill, we run the last four lines under the final else clause -- it resets $multi[$killer][1] to 1 every time. This means that the code always thinks that a given player is in a multi-kill state after his first kill, causing the multi-kill "start" code to never run (instead, it just increments the number of kills).

I tried changing this line to zero:

Code: Select all

  else {     endmulti($killer, $time); // End Multi-Kill for Killer     $multi[$killer][0] = $time;     $multi[$killer][1] = 0;  // WhiteHowler: Changed from 1 to 0 to allow multi-kill start code to execute     $multi[$killer][2] = $time;   }   

According to my debug messages, the correct code is getting executed to either start or continue a multi-kill.

Unfortunately, the multi-kill data still isn't being saved to the database, but I haven't quite gotten that far yet.

[Panther]

That's supposed to be 1 - the person just got a kill, and since his or her last kill was more than four seconds ago, that counts as the first kill of a possible multi-kill. The start is the time of the first kill of the multi-kill spree, so this does not get changed upon subsequent kills in the spree.

Besides, remember that it works for me, so you need to find what's different on your system. I'm running unmodified 3.02 code.

[WhiteHowler]

Well, I found the difference. For some reason, the $multicheck global is undefined when endmulti() calls it from logspecial.php. This was causing the switch statement in endmulti() (which identifies the type of multikill and credits it to a player) to never get run.

This is probably a PHP environmental thing on my end. I'm not sure how globals work since the deprecation of register_globals, so I'm not really sure what's wrong. I simply hardcoded "$multicheck = 1;" before the if statement, and things worked fine.

One thing to note, though -- this clause from tagut_kill():

Code: Select all

    if (!$multi[$killer][1]) {       $multi[$killer][0] = $time; // Start Time       $multi[$killer][1] = 1; // Kills     }   

...never seems to be executed under any circumstances. The only time ($multi[$killer][1] == 0) is true is the first time a given player gets a kill in a match -- however, in this case, the parent if clause:

Code: Select all

if ($time - $multi[$killer][2] < 400) { // Within multi range  

...would be false, and this line would never be evaluated. Obviously, it's not required for the multikill code to work correctly, but it doesn't seem to be necessary.

Anyway, thanks for all of your help. If I have any more problems with anything, I'll look at the globals first.

[Panther]

UTStatsDB will work with register_globals enabled or disabled and should be secure enough even when it's enabled. The multicheck variable set from within logs.php. The conflogs array is first loaded from the configlogs table in the loadconfig() function for each log configuration, then the multicheck variable is set while searching the log directory. The point where this could go wrong is if you have multiple log settings enabled where the logs are pulled from FTP in the same path as other log files with the same prefix. For the reason you should select different local paths for different sets of log files when retrieving via ftp.

It's possible for that code in tagut_kill to be executed if someone has a kill within the first four seconds of the match. Although, that would be within four seconds of the match loading so it's an unlikely possibility, but if it ever does happen the code is there to handle it.