Author Topic: Bug - STDlog PlayerConnect/PlayerLeft while map changes (Read 3804 times)

XtremeBain · « **on:** October 12, 2005, 08:16:12 PM »

I'm not quite sure if I posted this previously on the forum but I'm having an issue concerning the STDlogging of players (re)joining or disconnecting from the server when a map changes. This becomes problemattic for parsing because the parser has to *guess* which team a player is on when they appear in the logs(from a Kill, Flag Grab, Death). Right now it's only affecting the firstelim recording until I can implement some team guessing(shouldn't be hard since most maps are 2 teams).

jitspoe · « **Reply #1 on:** October 12, 2005, 10:39:24 PM »

Not quite sure I follow. You're saying that if somebody disconnects from a server while it's changing maps, it doesn't get logged?

XtremeBain · « **Reply #2 on:** October 12, 2005, 11:28:17 PM »

Alright, I thought I was experiencing the problem with the PlayerLeft but I cannot find any exact instances where it occurs. Here is the most frequent problem I have, and it's with a player called Eddie

Code: [Select]

                GameEnd 10576.3 Blue team wins!
                PlayerRename    Eddie   Eddie   0.0
                PlayerConnect   Eddie   Red     0.0
                Player  Eddie   Red     0.0
                Map     xmas
                PlayerConnect   rez     Blue    9.3     x.x.x.x:x
                Player  rez     Blue    9.3
                GameStart       38.4
                RoundStart      38.4

Lines 2,3,4 are causing most of the problems. Also I'm not quite sure why the PlayerRename is happenning. I was using nano to view the log so I decided to open up the hex editor to see if there were any characters which weren't being shown. Between the 0x09(\t) it was the exact same string of characters, weird.
Also it may be important to note that this happens when there is a GameEnd and when there isn't(I think this mean there was a newmap executed). Also, notice how Eddie's PlayerConnect doesn't have an ip in the last field; also weird. I followed through a large chunk of the log and Eddie seems to never have an IP address displayed in the PlayerConnect. I don't know if he's localhost to this particular server or what the circumstances are.

This happens multiple times and then again to another player:

Code: [Select]

                RoundStart      442.2
                PlayerLeft      PB_Freezy-D             449.6
                RoundEnd        449.7   Red wins
                PlayerConnect   xChronic        Blue    461.6   x.x.x.x:x
                Player  xChronic        Blue    461.6
                Map     steeple15
                PlayerTeamChange        xChronic        Observer        Blue    0.2
                PlayerConnect   .=ioD=.Tourpro  Red     9.9     x.x.x.x:x
                Player  .=ioD=.Tourpro  Red     9.9

Except xChronic wasn't in the server previously he had just joined while the map was changing. This time xChronic's ip does get shown.
The very same thing as "Eddie" happens a little later with a player named "fr34k". Don't know if it's the same person but again, PlayerConnect before Map and no IP shown.
I also run into an instance when I have "Eddie" and "George" playing against each other, each having connected with a PlayerConnect with no IPs once again. This possibly rules out the localhost bit, or maybe they're acebots?

Some other things to note:
While tracking all of this I found this weird occurrence:

Code: [Select]

                PlayerRename    sublime sublim  1787.7
                PlayerRename    sublim  subli   1787.9
                PlayerRename    subli   subl    1788.1
                PlayerRename    subl    sub     1788.1
                PlayerRename    sub     su      1788.1
                PlayerRename    su      s       1788.1
                PlayerRename    s               1788.1
^ÈPÆrEeÚe^È9    noname  Kill    Stingray        1       1791    300

It seems pretty normal, sublime has backspaced everything from the name field in the setup_funname menu. The PlayerRename reflects his name changing to "" but the pball game .dll doesn't like it and changes him to "noname", except the parser just reading the STDlog for what it is has no idea who noname is or where he came from.

I also hit yet another bump. This one is concerning the Player(1) that prevents two people from having the same name.

Code: [Select]

kingsniper(1)   NeRoToXeN       Kill    VM-68   1       1449    166
NeRoToXeN       kingsniper(1)   Kill    Carbine 1       1449    140
                RoundEnd        1449.9  Blue wins
                RoundStart      1458.9
                PlayerLeft      kingsniper              1464.7
                PlayerConnect   burgler Red     1474.4  x.x.x.x:x
                Player  burgler Red     1474.4
_-NoVa-_        NeRoToXeN       Kill    Automag 1       1479    156
                RoundEnd        1479.7  Blue wins
                RoundStart      1488.7
burgler kingsniper      Kill    Automag 1       1497    94

Here we have two "kingsniper" players. My interpretation of the above is that "kingsniper" disconnects from the server and automatically the game dll renames "kingsniper(1)" to "kingsniper" without making the necessary PlayerRename in the STDlog.

BlaSTa · « **Reply #3 on:** October 13, 2005, 12:53:22 AM »

Eddie is an acebot. Eddie runs almost all the time on this server, occasionally I'll remove him if I see the server filling up.

When the server fills with maxclients Eddie the acebot temporarily leaves. When the next map starts Eddie will rejoin the game if the maxclient isn't full. Eddie causes some name problems also, when full with real players and the map changes sometimes a real player will end up with Eddies name. At first I thought this was someone gaining access to the server, but it's not and is more funny than a problem to me. I actually laughed when I saw what you described.
BTW, George was probably also an acebot.

XtremeBain · « **Reply #4 on:** October 13, 2005, 01:17:59 AM »

Yeah that's what I figured, after looking further into the logs it became pretty obvious that he couldn't be a real player. Thanks for the clarification on this, it'll certainly help jitspoe identify where these things are breaking down. Maybe I should start detecting AceBots based on a blank IP address and start flagging them as bots while logging stats so the option to leave them out of the rankings can be made.
I figured out the bulk of the problems I was having with these newer logs, so you can take a quick peak at a very plain, incomplete and mostly non-functional output of these logs at http://holm.homelinux.net/dpstats/.
I'm still looking for someone to do some graphics for this project. I want to get it looking a little better and a lot more user friendly. Come visit me at #dpstats on irc.enterthegame.com if anyone is interested in contributing in any way to the project.

loial21 · « **Reply #5 on:** October 13, 2005, 01:19:52 AM »

eddie!!!!! canibus canyon

loial21 · « **Reply #6 on:** October 13, 2005, 01:21:29 AM »

stupid posting before i post. ....

jitspoe · « **Reply #7 on:** October 13, 2005, 01:31:19 AM »

Hm, I think I've addressed some of this stuff already. Acebot ip's should now show up as "BOT". As for players connecting before the map finishes loading... if that's the order of the events, that's how they'll get logged. I don't really know of a way to help you with that. It looks like the level time is before the map change, though, in the case of xChronic. I might be able to do something about the bots, but for real players...

I just fixed the PlayerRename issue. I'll see what I can do about the bots loading before the map. Thanks for the detailed bug report.

BlaSTa · « **Reply #8 on:** October 13, 2005, 01:38:53 AM »

The fact that Eddie had 9 flag caps is amazing. Good job Bain, looking good.

Edit: Ok, doh, it was someone with Eddie's name most likely.

jitspoe · « **Reply #9 on:** October 13, 2005, 01:42:21 AM »

Since he also has grenade kills, I'm guessing that's when a real player's name was overwritten.

I find it funny that the two bots are ranked 7 and 8, though, hehe. Makes me question the skill algorithm a bit... I know the overall numbers are low for the input, but should someone with ~1:1 k/d ratio really be in the top 10?

Edit: another thing, I had a k/d ratio of 1.5, and when I sorted by k/d, it had a range of 1.38-5.4 on the first page, but I wasn't listed.

XtremeBain · « **Reply #10 on:** October 13, 2005, 05:10:10 AM »

You're not part of the K/D sort because you've only accumulated 60 kills. That page only retrieves players who have 100 kills or more, this was used back when eR33t Public was up because the entire first page consisted of people with 10-20 kills and very few deaths.
The skill calcultion is based on a few adjustments I had been making to test the placement of particular players based on different algorithms. I believe that any flag events(grab, cap, fc frag, etc.) aren't being awarded because the last stats I had contained a couple maps that were cap-happy which had skewed the stats quite a bit. George and Eddie are in the top 10 largely due to the fact that they're not intelligent enough to pickup weapons and the bonus for PGP kills is much greater than those of higher end markers.
Also seeing an issue with deathmatch maps and how I keep records of the most kills in a round by players. Since dms are roundless so to say, most people are having kills in a single round record of 50 on the dm maps. Would it be possible to break STDlog standards some more(PlayerConnect tisk tisk) and throw the gamemode into the map entry, or add a gamemode after the map entry. Unfortunately the ability to distinguish dm maps is the only advantage I can see to this right now. I don't really have any ideas on team-flag ctf, center-flag ctf or koth specific stats.

b00nlander · « **Reply #11 on:** October 13, 2005, 08:37:21 AM »

I must say, I am impressed on the work that you have done so far. I have gathered some experience in this topic as well and if i find time, I will try to find you on IRC. My logfile should now be in your email folder, although it is an old one, and i will eventually send you an big current one. maybe.

But I also see the problems you are still having: DM maps will have to be counted differently than CTF maps, and siege maps are again to be counted in a different way I would say. Maybe even break everything down to only show scores per map, although a big lot of data would need to be gathered in order to make that be interesting and valid.

good job especially on the deeper going stats per person (one page per player), and the funname conversion. keep up the good work

mfg
~Pureblood~

jitspoe · « **Reply #12 on:** October 13, 2005, 11:11:37 AM »

I can add the game mode on there.

Another thing I'd like to see is accuracy statistics. I'm not sure what the best way to tie them into the stdlogs is, though. I could, when a player disconnects, just dump the shots fired and kills for each weapon.

XtremeBain · « **Reply #13 on:** October 13, 2005, 01:07:20 PM »

Somethings that aren't currently in the output:

Players
Longest Kill Streak(and what map)
Longest Death Streak(and what map)
Number of Rounds Played
Deaths from each marker
Most kills in a single round(and what map)
Number of Suicides
Time played on the server

Maps
Number of times played
Total number of kills
The amount of kills from each weapon
The record for most Kills, Deaths, Grabs, Captures in one map(and by who).
The number of rounds played
The amount of in-game time played on the server

The idea that you have with the breakdown by game played(or map-by-map) is an idea that I would really like to implement as well. It can be done with some minor changes to the parser since I already have 2 weeks(well a user-defined period at least) of data in loaded in the database for Skill adjusting purposes. Initially this was implemented so that if a player goes idle for a certain period of time there Skill will roll back to 1500, giving them incentive to play on a regular basis to keep their high rank. Obviously we don't see the affects of this since I'm parsing a few months worth of stats in 50 seconds. However that makes room to throw in separators for each new map into that huge database, slap an identifier on them and give me the ability to pull up all the data as if I was reading it from the log itself. I was actually going to make a seperate parser using this as a base for a match server so that accurate summarries of matches could be created. I've actually come so far that adding this into a pubic environment isn't that far off.

Accuracy would be neat but I fear that it would have to dumped just before the GameEnd(however sometimes the map isn't ended properly and there is no GameEnd) or thrown on the tail of each Kill event. The problem with this, it only knows how many shots are fired since the Kill you made, so if you had a death streak to end off a map, the results wouldn't be so legit.

Thanks again for the stats b00n, I'm going to give them a run and see how the turn out.

jitspoe · « **Reply #14 on:** October 13, 2005, 01:57:13 PM »

The other option would be to add a new stats entry that states the number of shots fired:
- when a player kills another player
- when a player dies
- when a player drops/picks up a weapon

I'm actually planning to make the newmap command end the map as opposed to instantly changing maps.

The other question is: If we log the shots fired at the end of a map, would it be best to do a stats line for each weapon, or put them all in 1? Doing one line would waste less space, but it would cause problems if we ever add/change any of the weapons.

XtremeBain · « **Reply #15 on:** October 13, 2005, 05:31:38 PM »

Tracking the shots fired of players in STDlogs is going to be nothing but headaches. The best implementation I can think of is creating an entry for when players switch weapons as well as spawn, these entries would also carry a shotcount value for the client. The player rename would also need to have the client's shotcount in it. There would also have to be an entry for each player at the end of the map which revealed the shotcount. Then it would require a lot of work on my part to interpret the shot counts to determine accuracy. Other parsers like GibStats wouldn't be able to pick it up at all.

Just some thoughts though..

jitspoe · « **Reply #16 on:** October 14, 2005, 12:01:35 PM »

Is there a reason you'd need it for each weapon switch? Wouldn't stating the shots fired for each weapon at the end of the map be sufficient? I could even state the shots fired and the # of kills for each weapon, if it would make it easier. Then all you'd have to do is total the numbers.

XtremeBain · « **Reply #17 on:** October 14, 2005, 01:50:47 PM »

I'm just concerned that you'll be dumping those numbers for each unique client that played on the server in that particular map. The stats work in a 'unique name' manner instead. Given that I think it would be less work on YOU to implement my suggestion, and in turn it gives me(or anyone else brave enough) more juicy data to play with. From this such additional information can be gathered: the infamous eliminated player's gun, duration of play that each weapon has had, weapon wielding percentages, most shots in one round, highest accuracy in one round, and probably a few others that I can come up with off the top of my head.
Not to say I'd do all or any of those things though

If you want to hack in a dump of each name's shotsfired information and make sure that newmap ends the game gracefully then I can add in the accuracy with not much difficulty.

jitspoe · « **Reply #18 on:** October 14, 2005, 03:46:53 PM »

I guess the ultimate solution would be to do both.

The eliminated player's gun isn't stored? Hm, I should probably change that.

XtremeBain · « **Reply #19 on:** October 14, 2005, 04:57:43 PM »

The Kill log entry is kinda full as it is