Server statistics?

[webdevbrian]

Hello all,

As others hosting servers may know, the most engaging aspect of leading of a group (or 'clan'), is the ability to associate their members with game-to-game statistics. Is there any possibility of taking your own dedicated Altitude statistics and bringing them into a static form (ex. a SQL db)?

I'm contemplating adding a couple of servers for my group, just wondering if people are already doing this, or have already had this idea?

Best,
webdevbrian

[Demia]

Originally Posted by webdevbrian

Hello all,

As others hosting servers may know, the most engaging aspect of leading of a group (or 'clan'), is the ability to associate their members with game-to-game statistics. Is there any possibility of taking your own dedicated Altitude statistics and bringing them into a static form (ex. a SQL db)?

I'm contemplating adding a couple of servers for my group, just wondering if people are already doing this, or have already had this idea?

Best,
webdevbrian

Well the server writes JSON logs so you could write your own program that uses JSON to take kill messages and what not to create a database of statistics pretty easily I might actually do it for me and my brothers server when we get it running.

[webdevbrian]

Hmm, that's a decent idea. I haven't set up a server yet, so I haven't seen what it does in it's live status.

Parsing through JSON and adding to a DB is quite simple, so this could be pretty sweet and 'way less complicated' than I originally thought. I guess you could prevent massive CPU / DB utilization by setting an update interval (ex. once every 5 minutes or so) to have semi-live updated statistics. The issue then being, is catching up where it left off from the last update.

It's doable, though. A nice mod would be making it write directly to a DB to store data straight from the server, instead of having to deal with parsing / DB addition loads Meh, it's something I guess. I wonder what details it grabs from the users, in terms of level / plane used...

[Jrathje]

Originally Posted by webdevbrian

It's doable, though. A nice mod would be making it write directly to a DB to store data straight from the server, instead of having to deal with parsing / DB addition loads Meh, it's something I guess. I wonder what details it grabs from the users, in terms of level / plane used...

Level of detail, pretty much EVERYTHING. See this thread for an example of what info is available and was used to investigate a cheating situation. Go down to where nobodyhome posts.

[webdevbrian]

Originally Posted by Jrathje

Level of detail, pretty much EVERYTHING. See this thread for an example of what info is available and was used to investigate a cheating situation. Go down to where nobodyhome posts.

Awesome stuff. I'm about to run a test a quick parser I just made which tosses the results into a SQL DB and see if I can't generate a decent reporting tool from it. Thanks for the link.

[MajorPayne257]

While you're at it, just read that whole thread. Lulz are provided.

[webdevbrian]

Originally Posted by MajorPayne257

While you're at it, just read that whole thread. Lulz are provided.

Ha, yeah I checked that out. Good stuff.

[Jrathje]

Originally Posted by webdevbrian

Awesome stuff. I'm about to run a test a quick parser I just made which tosses the results into a SQL DB and see if I can't generate a decent reporting tool from it. Thanks for the link.

No problem Brian. Welcome to Altitude. Mature, intelligent people are always a great addition to the community.

[webdevbrian]

Originally Posted by Jrathje

No problem Brian. Welcome to Altitude. Mature, intelligent people are always a great addition to the community.

I'm just glad others exist Cheers.

[webdevbrian]

Well I've managed to parse through a server log, however (as I said above) it takes a while. Getting it into SQL isn't too bad, making a password protected script which dumps the results into SQL is definitely a more feasible option.

Just as a comparison for people who don't know the difference:

JSON parse ('small' log file, 223kb): 6.7 seconds

SQL query to return all results from a JSON dump : .1 seconds

The interesting part is splitting the JSON dump into specific tables / rows, ex. every time the server is started and ended, then assigning Player IDs for that session to each vaporId. Not to bad though, managed to bullet through the above project in about an hour.

The bigger issue being that other dedicated server log files will be easily 10MB+, and dumping the results into a SQL file will definitely take a while, unless the administrator of said server splits the log files between each dump into smaller sizes.

Shouldn't be too difficult though, definitely happy about the servers dumping JSON instead of XML for a change .

If anyone has a dedicated server, what's your log file size?

*edit*: I should also mention that my log files had connected users' vaporIds split into separate lines, which will definitely muck up parsing.

[phong]

If I'm understanding you correctly, the problem with your idea is that the logs can be manipulated before they are uploaded. Unless you only allowed trusted sources (by password or other means), to upload you'd end up with a very inaccurate database (especially if the password ever leaked)

You could just make customized version of PALP, have each server admin run it configured to a mysql server of your choice (with user/pass/host restrictions), but then you'd have live data.

If I ever got around to updating PALP I'd do this but wont be getting there any time soon. Right now the sql queries were meant to run with a single instance of altitude_launcher in mind.

On a side note if lamster ever got around to implementing clan/squads *death gaze*.. it would make it real easy to track teams but that has been pending forever.

[webdevbrian]

Originally Posted by phong

If I'm understanding you correctly, the problem with your idea is that the logs can be manipulated before they are uploaded. Unless you only allowed trusted sources (by password or other means), to upload you'd end up with a very inaccurate database (especially if the password ever leaked)

You could just make customized version of PALP, have each server admin run it configured to a mysql server of your choice (with user/pass/host restrictions), but then you'd have live data.

If I ever got around to updating PALP I'd do this but wont be getting there any time soon. Right now the sql queries were meant to run with a single instance of altitude_launcher in mind.

On a side note if lamster ever got around to implementing clan/squads *death gaze*.. it would make it real easy to track teams but that has been pending forever.

Unless it's (server log file) being scraped automatically, it needs to be separated into multiple files to save on parse / upload sizes. So, manipulation is a must. Secondly, It's absolutely protected by password and php sessions.

What I have so far I don't believe is like PALP (Though I haven't used it, nor heard of it), however, is not a modified version of it (nor using a core of any other server stats script). I like my semi-live statistics, and I think an active connection on the log file would be to much of a resource hog, dependent on the server's population history.

But I agree with you on the no clan/squad names, (and surprisingly other data I thought would be pretty nice to have). In the end, it IS a server log, I wonder if a bot / separate script could piggyback off of the server launcher and lift data that way. Would be best, especially without dealing with all of this parsing / SQL crap over a single file. I think clans / squads would have to have a specific format in the username, or Altitude needs to add further functionality so people can grab those statistics. Grouping people by clan name / squad would be a massive win.

I'll check out PALP and see what's going on with it. Thanks.