[MatrixZeroOne]

Hi Guys.

Now I know the topic description looks a little backwards.. 'Private Public', so let me give a little background.

I work in school where we have been running small UrT tournaments for a while now and it's been quite successful.
We have held some charity events (one forthcoming) and the request for some stat tracking has raised it's (somewhat ugly) head.

VSP works (in a way) but our students prefer the style and 'awardness' of XLR

The Problem : Although our Lan's are private, the players have the ability to sit wherever they so choose, which makes stat tracking a bit awkward (esp with xlrstats) because of the GUID that is registered and thus the way XLR attributes stats to players.

After a bit of poking around, I've discovered that it's not xlr's fault, but B3 in the way it tracks players by the guid generated by the server and client qkeys.

If I copy my qkey from one machine to another, XLR still is able to track my stats and not a new unregistered player.

The Question : Is there anyway of generating a client qkey outside of UrT so that I could match up qkeys to players? This would enable me to write a small utility to copy over the matched qkey file (or generate it's own) to the pc so that no matter where the player sits the tracking will remain consistent.

Hope this explains everything, and if the is an obvious solution to this that anyone knows of then great.

Thanks for any help =D

[MatrixZeroOne]

Looks like I might have solved by own problem.

Looking through the source of ioquake, the qkey is only a 2K file filled with random bytes.

That can easily be reproduced so I can store player names next to keys in database..

Players will have to be preregistered mind you, but that only need to really happen once every so often.

If anyone else can think of anything, it's most welcome.

Cheers

[MaJ]

MatrixZeroOne, on 03 November 2009 - 11:52 AM, said:

Looks like I might have solved by own problem.
Looking through the source of ioquake, the qkey is only a 2K file filled with random bytes.
That can easily be reproduced so I can store player names next to keys in database..
Players will have to be preregistered mind you, but that only need to really happen once every so often.
If anyone else can think of anything, it's most welcome.
Cheers

Well, the painfully simple way to deal with this issue is to build your own UrT client with a small code change that instead of using the md5 of the contents of the qkey file salted with the server's address, simply uses the player's name as the guid. All you have to do then, is make people use their own names (/name in the console) before (yes, emphasis on the before) connecting to the server.

Besides guid and name, there really is no good way of telling players apart. This has a couple issues, people can play as others and demolish their stats (already the issue you are having) and if you have b3 set up to use some players as admins, players will be able to connect with a given name and issue commands of that player's permission level. (also an issue that you already would have given access to these computers)

The other way is to completely go outside of what UrT and B3 do with guids and set up a remote share for each player. Give them their own UrT directory so they can have their own q3key stored on it. This would also make it so others playing do screw with the config (mouse sens, binds, etc...) since they are working in their own directory on a remote server.

This post has been edited by MaJ: 03 November 2009 - 12:58 PM

[MatrixZeroOne]

Some good ideas there.. Thanks

I already have small UrT launcher to filter a list swear words from the player names before launching the game, refusing access if a wrong word is found.
The launcher is set to overwrite the autoxec.cfg file with seta playername parameters then execute UrT.
I'm doing it this way because the PC's have policies to restrict access (with only the autoexec.cfg fiel being the exception)

My plan is to extend the app to include a username/password combination which would link to a mySQL backend, which would then (after verification) pull the correct qkey file down to the pc overwriting the existing file.

Not going to be easy I know, but I like challenges and the username/password setup would allow the stats to be relative safe from cross player contamination and keep refs/admins safe from abuse.

The roaming profile/user share idea is a good one, and would do exactly the same as above, but I'd rather not matain multiple logons/user areas instead keep the server's and pc's as clean as possible.

Thanks for help

[mission]

MatrixZeroOne, on 03 November 2009 - 01:20 PM, said:

Some good ideas there.. Thanks

I already have small UrT launcher to filter a list swear words from the player names before launching the game, refusing access if a wrong word is found.
The launcher is set to overwrite the autoxec.cfg file with seta playername parameters then execute UrT.
I'm doing it this way because the PC's have policies to restrict access (with only the autoexec.cfg fiel being the exception)

My plan is to extend the app to include a username/password combination which would link to a mySQL backend, which would then (after verification) pull the correct qkey file down to the pc overwriting the existing file.

Not going to be easy I know, but I like challenges and the username/password setup would allow the stats to be relative safe from cross player contamination and keep refs/admins safe from abuse.

The roaming profile/user share idea is a good one, and would do exactly the same as above, but I'd rather not matain multiple logons/user areas instead keep the server's and pc's as clean as possible.

Thanks for help

i have actually done a bit of fiddeling with the ioquake3 client source code. i added 2 cvars cl_username and cl_pwd. Then edited the b3 parser to grab these. Then i did a b3 plugin that would take these on player connect and check the b3 database for a match. Then if it didnt get a match it would kick them, but if it did get a match it would allow them to play. Basically creating a registered players only server. I might be able to get xlrstats to go by login instead of guid. hmm.. ill take a look... also i might still have one of those client executables laying around... i have to check

[MaJ]

mission, on 04 November 2009 - 02:35 AM, said:

i have actually done a bit of fiddeling with the ioquake3 client source code. i added 2 cvars cl_username and cl_pwd. Then edited the b3 parser to grab these.

You shouldn't need to edit the client for that. You could just put:

setu cl_username <username>
setu cl_pwd <password>

into the autoexec.cfg on the client.

[mission]

MaJ, on 03 November 2009 - 09:01 PM, said:

You shouldn't need to edit the client for that. You could just put:

setu cl_username <username>
setu cl_pwd <password>

into the autoexec.cfg on the client.

funny thing is i never thought to just do that, lol

i was originally going to try to integrate a login system into the server side, but never got to that part, so i got the idea of registered users thing and decided to try to combine that client with the b3 bot.

[courgette]

mission, on 04 November 2009 - 03:35 AM, said:

I might be able to get xlrstats to go by login instead of guid.

The B3 login plugin that comes with the default install is very close to what you want to achieve

[mission]

courgette, on 04 November 2009 - 02:52 AM, said:

The B3 login plugin that comes with the default install is very close to what you want to achieve

i got this to work, i edited up the iourt41.py urt parser to get the cl_username and cl_pwd, then i got the xlrstats to use these to track stats instead of the guid. so know when you connect you only have to type !register and as long as you have the correct username and password you will have your stats... i look through the two files for mistakes before i post them, sorry...

[MatrixZeroOne]

Nice Work =D

This would make things alot easier.

I extended the app I had to now include a playername/password combination tied into a mysql backend.
It also pulls down a pre-created qkey file matched to them during registration.
The benifit of doing the verfication outside the client is that they can't launch the game without succefully logging in, and then only when the network login is available.

Your tweeked xlrstats would be great as secondary level of verification preventing them from changing usernames in-game and possible altering someone elses stats.

Thanks for the suggestions and help =D