Search / View

[Tequila]

Hi admins,

little talk about GUID stuff. I'm thinking about a solution to get such a functionnality in Q3 mods games. I would like to have your opinion.

1) Why a player GUID ?
I think player "Global Unique IDentifier" is only meaningful for player statistics. When you are checking Wasteland stats for example you can easily found some players with many positions and the same name. VSP can take care about GUID but this stuff isn't available in Q3 engine. With the SA release, maybe players would love to check there stats and maybe that could be a way to show someone progress. I think young people would love that, but this is just a point of vue. So maybe a good GUID handling could help some Q3 player to play more on SG and SG need more online players...

2) How GUID for SG ?
In fact, technically we can't have a real GUID unless Q3 engine is taking care of. But there's something people transmit to servers as they connect to we can use to fake a GUID... The player name of course... ... waoh ? How can we use it to recognize people ? Anyone can connect to a server pretending he is "Red Neckerson" ! Oh yes, you're right so we need a "secret" to recognize automaticaly someone. No real secret can be shareds between server and a player, so I just think of a poor secret... just something for which you need to know some good tool to discover the secret. Why ? because the secret is encoded in the name. How ? Just say the Red Neckson secret is a number like 1234... Than Red NeCKersoN name can be set to '^1R^7eD ^3NeCK^2erso^1N^7^7^1^2^3^4^7^7'... as you see the secret is inserted in a color scheme at the end of the name. That's invisible in game.

3) Faking GUID, sharing a secret, no way you can trash it now, you're stupid
Of course, this is not a great solution. Technically with some script between server log and VSP you can handle easily that kind of GUID. Now, for the secret, I'm thinking... maybe the secret should be provided from another server where we manage players who care about there stats and the secrets list & scripts are shared with VSP admins. This is an idea.
In case of a duel tournament, maybe we could implement a tournament web server where you need to register just before you play to get your secret, set it and play on the SG server which know that secret. Without that secret you would be out of the tournament...

Conclusion:
Yes there's some job. There's some ideas.
Do SG need that ?
Maybe SG should better be ported to Q4 engine or another

So now you can say I'm stupid

[ReD NeCKersoN]

Several of us have discussed how we wish for a player guid system. The suggestion you have here does seem odd though & relies solely on player cooperation. Could work out for a tournament, but I don't know.

[L3th4l]

Well quake3 does support GUID and IP address but for some reason it does not output to the SG server.log..

[ReD NeCKersoN]

Ah, good. That's what this thread needs. Knowledgeable input. Anyone else know a bit about this?

[Tequila]

Well quake3 does support GUID and IP address but for some reason it does not output to the SG server.log..

Thank you for that info.

yes I didn't check ioq3 code before and I found the code in code/game/g_client.c at lines 867-883 (for svn rev1204)

Code: Select all

   // send over a subset of the userinfo keys so other clients can
   // print scoreboards, display models, and play custom sounds
   if ( ent->r.svFlags & SVF_BOT ) {
      s = va("n\\%s\\t\\%i\\model\\%s\\hmodel\\%s\\c1\\%s\\c2\\%s\\hc\\%i\\w\\%i\\l\\%i\\skill\\%s\\tt\\%d\\tl\\%d",
         client->pers.netname, team, model, headModel, c1, c2,
         client->pers.maxHealth, client->sess.wins, client->sess.losses,
         Info_ValueForKey( userinfo, "skill" ), teamTask, teamLeader );
   } else {
      s = va("n\\%s\\t\\%i\\model\\%s\\hmodel\\%s\\g_redteam\\%s\\g_blueteam\\%s\\c1\\%s\\c2\\%s\\hc\\%i\\w\\%i\\l\\%i\\tt\\%d\\tl\\%d",
         client->pers.netname, client->sess.sessionTeam, model, headModel, redTeam, blueTeam, c1, c2,
         client->pers.maxHealth, client->sess.wins, client->sess.losses, teamTask, teamLeader);
   }

   trap_SetConfigstring( CS_PLAYERS+clientNum, s );

   // this is not the userinfo, more like the configstring actually
   G_LogPrintf( "ClientUserinfoChanged: %i %s\n", clientNum, s );


Also the README says " * cl_guid support". It seems to be based on qkey and is generated with md5 sum on the file. Indeed, it seems to be set empty without qkey but aware people can set it to what he want.

The last line is what we found in server log. The content is defined in the 's' string and as you can see the 'cl_guid' is not used. So if you can add that in the right place for the SA this could be helpful for server admins.
I can propose a patch if you want.
Let me take a moment to recheck VSP stats sources which field should be filled with that CVAR.

But is this nice for you to add such a patch to SA ? I don't really know if just a modified server could be sufficient... I will try that.

[Tequila]

Okay, here is a patch for Q3 engine.

g_client.c.no_guid revision is g_client.c rev1271 from ioQ3 sources. (same file since rev1204)

Code: Select all

--- g_client.c.no_guid  2008-03-14 12:15:49.000000000 +0100
+++ g_client.c  2008-03-14 12:17:11.000000000 +0100
@@ -713,6 +713,7 @@
        char    redTeam[MAX_INFO_STRING];
        char    blueTeam[MAX_INFO_STRING];
        char    userinfo[MAX_INFO_STRING];
+       char    guid[MAX_INFO_STRING];
 
        ent = g_entities + clientNum;
        client = ent->client;
@@ -863,6 +864,7 @@
 
        strcpy(redTeam, Info_ValueForKey( userinfo, "g_redteam" ));
        strcpy(blueTeam, Info_ValueForKey( userinfo, "g_blueteam" ));
+       strcpy(guid, Info_ValueForKey( userinfo, "cl_guid" ));
 
        // send over a subset of the userinfo keys so other clients can
        // print scoreboards, display models, and play custom sounds
@@ -871,10 +873,14 @@
                        client->pers.netname, team, model, headModel, c1, c2,
                        client->pers.maxHealth, client->sess.wins, client->sess.losses,
                        Info_ValueForKey( userinfo, "skill" ), teamTask, teamLeader );
-       } else {
+       } else if (*guid == 0) {
                s = va("n\\%s\\t\\%i\\model\\%s\\hmodel\\%s\\g_redteam\\%s\\g_blueteam\\%s\\c1\\%s\\c2\\%s\\hc\\%i\\w\\%i\\l\\%i\\tt\\%d\\tl\\%d",
                        client->pers.netname, client->sess.sessionTeam, model, headModel, redTeam, blueTeam, c1, c2,
                        client->pers.maxHealth, client->sess.wins, client->sess.losses, teamTask, teamLeader);
+       } else {
+               s = va("guid\\%s\\n\\%s\\t\\%i\\model\\%s\\hmodel\\%s\\g_redteam\\%s\\g_blueteam\\%s\\c1\\%s\\c2\\%s\\hc\\%i\\w\\%i\\l\\%i\\tt\\%d\\tl\\%d",
+                       guid, client->pers.netname, client->sess.sessionTeam, model, headModel, redTeam, blueTeam, c1, c2,
+                       client->pers.maxHealth, client->sess.wins, client->sess.losses, teamTask, teamLeader);
        }
 
        trap_SetConfigstring( CS_PLAYERS+clientNum, s );

Now I'm working on a patch for VSP. I think better to release a SG class parser for VSP as none is available for WQ3/SG...

Then, I tried my patch on Q3A and I saw only the server part needs these patch. But the g_client.c concerned function is overided in SG with qvm load, so can you apply that patch to SG source ?

And then do you think you can release an update for server admins with this only patch applied ? Only the /vm/qagame.qvm is concerned I think, so it can be a very short release. It could be fine if we can test that solution before the SA release. It could be necessary to set "sv_pure" to "0" until SA is released but this is not critical if the goal is testing.

What do you think ?

[L3th4l]

Damn, nice work Tequila

[Tequila]

Thanks. That's a very short contribution

By the way, I also propose the patch to ioquake3 as enhancement (see Bugzilla id 3570).

[hika]

Sorry to be that late ...
Tequila, I will apply your patch to the SG source code, in the next few days, and will bring you the qagame.qvm file you need.

And yes, g_client.c (and other g_* files) concerns the server part.
cg_* files concerns the client part and bg_* files concerns both server and client part.