Global statistics

[Tank Program]

What do people think of the idea of the authority for a player keeping track of their won rounds/matches/kills/deaths? I think it'd be neat to on the forums show that information at least. It could maybe be done by establishing some sort of session key on login, downloading the current stats and then on logout use the key to upload the new stats. Or do it incrementally. Obviously a feature for trunk. I think it'd be doable as a new back end to swap in place of tStatFile. Originally a straight database class was my plan, something like tStatMySQL, but I never got around to writing that. (Not that it wouldn't be good to do that either.)

So summary:

* Player logs into authority. Authority sends back some sort of session key along with PASSWORD_OK.
* Server keeps track of stats while playing
* Player exits server. As part of clean up, the server uses the key to send the new stats information back to the authority.

Vulnerable to man in the middle I suppose, but only if you're packet grabbing. It would be annoying, but I suppose the server could re-request login as part of the logout and send the stats information back that way.

[K-Yo]

I love the Idea!

could lead to an enhanced server list.
Noobs would be proposed servers where majority of players are noobs and good players will be displayed servers full of pros first.

No comment about how to realize it, I'm a complete noob with that.

[theroze]

Cool Idea. But we gotta work out a formular for Armaskills, which includes all the Kills, suicides and blah. That'd go along with all the SQL Stuff to a specific Server.

Hm. What about making several Schedules? Fort, Sumo, HR and all that Stuff. Because if someone pwns at Sumo and enters an other Server where he sucks...Whatever, I think you got my Point.

Oh and, I'd suggest to have gridstats.com again, would totally fit.

[Tank Program]

I don't know for sure, but I don't think NOMS would work with this directly. And as for the difference between servers and game types, another issue but I'm not sure how it would be possible to take that into account.

[Z-Man]

A problem that needs thinking about here is cheat servers. We can do nothing against servers popping up that just artificially boost peoples' stats. What was wrong with Luke-Jr's approach of letting server admins send in ladderlogs (yeah, we probably need to rework that one) and the central statmaker parses them? To integrate that back into the game, the servers could then query the statmaker server.

(Funnily, a simple central stat system already exists as part of the Krawall code. There's the option to send win stats to the masters, crudely encrypted.)

[Tank Program]

Yeah. The cheating. Having the session key means that in order to cheat you have to do it on your own modified server so that would offer some protection. Offering a server key out on request would take away some of the automaticness, but then verify that only trusted servers were being used. And then it would be easier to track by server, or at least server operator. The server key could be hashed with the session key as well, similar to how it is with passwords maybe. The whole idea here is to make it as automatic as possible. While sending in server logs is comprehensive it takes a bit of work.

(Funnily, a simple central stat system already exists as part of the Krawall code. There's the option to send win stats to the masters, crudely encrypted.)

I do remember reading bits of this code in the past and I have no idea if it'd be usable or not.

Alternatively, I just had the idea that the server operator could pick their own server key. If it's blank, it's the equivalent of a "Player 1" entry. It would remove the issue about scores for different game types meaning different things. A large binary field in the database could be used to store the information comma separated or something then packed.

[epsy]

what about splitting stats by server? That kills cheating(becomes obvious), and makes sense with different settings. A server itself could propose more than one set of settings and send the appropriate identifier when sending stuff to the stats collector(A hash of all game-related settings?)

[Tank Program]

(A hash of all game-related settings?)

That would work pretty well as a server key. I don't think there's any two servers with a identical settings.

[epsy]

You didn't get it: I mean one key for the server + one for whatever /game/ settings it uses.

[ZURD101]

that goes back the implementation of this topic's

Code: Select all

server_gametype <sumo | Fortress | LMS>

settings, which i think could help define the global stats

[sinewav]

that goes back the implementation of this topic's

Code: Select all

server_gametype <sumo | Fortress | LMS>

settings, which i think could help define the global stats

http://forums3.armagetronad.net/viewtop ... 94#p216694

[epsy]

Well, if an admin starts messing around with settings for fun, the gametype label is the last thing he's gonna change. And boom, stats will be trashed.

[Tank Program]

So then there'd be two keys involved. One key identifies the server owner/admin/operator, the other key identifies the game type. I'd say both settable by the user. That way every say, sumo server, could share the same key, but they would still be different by the operator key. You could then compile stats by game type or by operator.

[Tank Program]

Right well. I've written the server side code. It may even work. I haven't been able to test it farther than compiling, but as I'm about to break for lunch I thought I'd post what I've gotten. Next up would be writing the modifications to the armaauth script.

[epsy]

What has to be changed?