Forum

Learning R00k's Joy

Discuss programming topics for the various GPL'd game engine sources.

Moderator: InsideQC Admins

Learning R00k's Joy

Postby Baker » Wed Oct 17, 2012 6:41 am

I've run into some interesting challenges writing server side stats with QuakeC support.

I've also had to actually learn QuakeC, which is becoming less a mystery every second. But I can really say that the flow of QuakeC is a bit haphazard for client connections.
In my opinion, since as it natural comes it doesn't distinguish between new connections and reconnects (even though it does, but it is a bit of an entangled mess). I guess in Quakeworld this is rather irrelevant, as Spike says the server aliases are cleared and resent every level. [I might head towards that eventually, it can't hurt anything].

The fun part of working with QuakeC when you already are working with the engine is the "if things don't support what you are doing" frustration doesn't really happen. :D

You just say "whatever" and make some changes to the engine source.

Notes / Observations:

1. A lot of NetQuake mods use QuakeC for things that are completely wrong for QuakeC to be doing. Most of the admin functions in mods is all wrong and QuakeC shouldn't be doing it:
A. Checking for blank names. QuakeC can't even do this right due to special characters.
B. Banning/Muting/Kicking. Should be done in the server engine, exposed via rcon.
C. What is left that QuakeC admin functions do? Changing maps, maybe killing a player. I'm thinking admin functions in QuakeC is possibly as "wrong" as spectating functions in QuakeC (Although for now I'll have to live with it.)

2. Here is part of the reason that QuakeC administrative functions are "wrong", using old ProQuake server as an example. You can ban a player, but they can still rcon (since that is the engine). That's silly as hell.

3. Lacking Quakeworld serverinfo stuff, the most ridiculously hard thing that is common with a NetQuake server is setting the map rotation. In QuakeC, this is a crapton of work. In the engine? Ha! Throw in new cvar ("map_rotation"). If cvar isn't "", override PF_changelevel. No QuakeC modification required.

4. pq_teamscores is kind of a standard in ProQuake, the qccx hackage QuakeC for that is terrible. ALL the qccx hacks that I know of, this is the only thing that really is hard to displace in NetQuake. qccx hacks are used for ip masking and generally other stuff that QuakeC shouldn't really be doing.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Baker
 
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Learning R00k's Joy

Postby Baker » Wed Oct 17, 2012 8:18 am

Works perfectly. Allows repeats in the cycle. With R00k's other engine modification, sv_defaultmap someone screwing up a map name in the cvar can't crash the server.

Code: Select all
#ifdef SUPPORTS_MAP_ROTATION_CVAR // Baker change (PF_changelevel modification)
cvar_t map_rotation = {"map_rotation", "dm6 dm3 dm4 dm6 dm2"};


void PF_changelevel (void)
{
   char   *newmap;

// make sure we don't issue two changelevels
   if (svs.changelevel_issued)
      return;
   
   svs.changelevel_issued = true;

   if (map_rotation.string[0])
   {
      static char last_index = 0;
      int cur_index, argc, i, next_index;
      
      // Override with auto rotation
      Cmd_TokenizeString (map_rotation.string);
      
      // argc is now the count
      argc = Cmd_Argc();

      // Locate our position in the list (if we had a position)
      for (i = last_index, cur_index = -1; i < argc; i ++)
      {
         char *argv = Cmd_Argv (i);
         if (Q_strcasecmp(sv.name, argv) == 0)
         {
            cur_index = i;
            break;
         }
      }

      if (cur_index == -1)
         next_index = 0; // Didn't find the map in the rotation, so use first map
      else next_index = cur_index + 1;

      if (next_index >= argc)
         next_index = 0;

      last_index = next_index;

      newmap = Cmd_Argv (next_index);
   } else newmap = G_STRING(OFS_PARM0); // Regular behavior
   
   Con_Printf ("New map is %s\n", newmap);

   Cbuf_AddText (va("changelevel %s\n",newmap));

}
#endif // Baker change
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Baker
 
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Learning R00k's Joy

Postby r00k » Thu Oct 18, 2012 12:36 am

I wrote a modification to changelevel in Qrack that without a parameter it will load a random map based on the maps it finds in the path. I can't remember if the source on the Qrack page has that function included.
But ya most the admin functions should be engine side with a simple parameter passed from the mod.
I did modify pro quake back in the day by adding a mute command but also did it in qc for others versions of Pq that didn't have that chat "mute".
r00k
 
Posts: 1110
Joined: Sat Nov 13, 2004 10:39 pm

Re: Learning R00k's Joy

Postby Spike » Thu Oct 18, 2012 8:23 am

Hexen2 does clearly distinguish between new clients and clients-from-the-previous-map. *ALL* of the player's fields are copied over from one map to the next. This means you need to reset all timers and entities, of course. On the other hand, the parm system is more useful for respawning.

1A: The engine should reject blank/dupe names already. QuakeWorld does, I would assume NQ would too.
Note that if you use the char \xff in your name, QW clients might see a truncated string, so servers should be fixed for that bug.
1B: bans should be enforced by the server, yes, if only because the QC can't save its ban lists very easily between server restarts. Engines doing it means that the banned player never even consumes a player slot.
That said, what about mod-specific admin rights? With votekicks and the like?
1C: spectator mode should generally be done by the QC. There are too many weird cases if the server does this, including stuffcmds (like idlescale) sticking. Generally though, you'll need some csqc to make decent use of spectator modes.

2: Ban filters should be enforced by the engine, even if the ban is initiated by QC, yes.

3: so long as it doesn't break mods, like ones that use specific maps for certain things.

4: Anything using a qccx hack is a hack by definition. I don't know what's so special about pq_teamscores that make it require qccx hacks.
Spike
 
Posts: 2908
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: Learning R00k's Joy

Postby Baker » Thu Oct 18, 2012 10:15 am

Spike wrote:Hexen2 does clearly distinguish between new clients and clients-from-the-previous-map. *ALL* of the player's fields are copied over from one map to the next. This means you need to reset all timers and entities, of course. On the other hand, the parm system is more useful for respawning.

Actually, NetQuake for sure distinguishes between new clients and clients from the previous map:

1. SV_ConnectClient ----> PR_ExecuteProgram (pr_global_struct->SetNewParms) (initial connection only --- never done by "reconnect" like map to map reconnection)
2. SV_SaveSpawnparms --> PR_ExecuteProgram (pr_global_struct->SetChangeParms); (Level carry over)

It's just that the standard QuakeC muddles all of this up like spaghetti, with respawn and even level carry over calling SetNewParms. I spent maybe a day detangling this behavior in a codebase that was kinda messy in that particular area (xCTF --- a modified ThreeWave CTF codebase. xCTF has some great stuff in it, I've deactivated the CTF functionality to turn it into a pure teams deathmatch mod).

re: Hexen 2 carrying over timers/entities. That is different.
Spike wrote:1A: The engine should reject blank/dupe names already. QuakeWorld does, I would assume NQ would too.
Note that if you use the char \xff in your name, QW clients might see a truncated string, so servers should be fixed for that bug.

None of the NetQuake engines do this. Of course, that is changing --- the blank names part. The dupe names part --- well, NetQuake doesn't do that either, but we have some knuckleheads that would eventually abuse that by impersonating someone else so they couldn't use their own name to connect to a server.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Baker
 
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Learning R00k's Joy

Postby Baker » Thu Oct 18, 2012 10:21 am

Spike wrote:4: Anything using a qccx hack is a hack by definition. I don't know what's so special about pq_teamscores that make it require qccx hacks.

I've looked closer at pq_teamscores and I'm thinking it may not actually require any QCCX stuff. Seems to use standard QuakeC to do that, but I didn't know that at the time of my above post because I hadn't dissected it out and was operating on the assumption that it was doing something unusual. pq_teamscores seems to use the standard WriteByte or WriteShort function.

Looks like the qccx hacks stuff is largely limited to impossible QuakeC functions like strlen, string editing, beating the PF_ftos limitation, etc.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Baker
 
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Learning R00k's Joy

Postby Spike » Thu Oct 18, 2012 11:06 am

Yeah, I do already know how the parms work. :P
Standard QC really doesn't care if the player is new this map or not. Starting from a clean slate on each map is a nice thing to be able to do. It means you don't get weird new bugs other than items not transitioning (like red armour!).

regarding names, why don't you just fix that engine-side? should be an easy fix inside Host_Name_f.
qc doing things that are so trivial and common sense is just stupid. which is why the whole mentality behind qccx hacks is wrong. If its broken in the engine, fix it in the damn engine, and name+shame any engines where its a problem (at least privately to their authors).
You'd be stupid to run an unmodified quake server on the internet (due to NAT issues or exploitable flaws), so there's very little reason to even bother taking the long route and working around it in the QC. The only reason is if you have absolutely zero contact with the (other?) engine authors.
Spike
 
Posts: 2908
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: Learning R00k's Joy

Postby Baker » Thu Oct 18, 2012 11:40 am

Spike wrote:Yeah, I do already know how the parms work. :P

I did excessive explaining so someone reading this thread that doesn't otherwise know might benefit. (Two weeks ago, I would have been one of those people. In the past, I didn't play with QuakeC hardly ever.)

which is why the whole mentality behind qccx hacks is wrong. If its broken in the engine, fix it in the damn engine

That's kinda what I'm hoping to do.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Baker
 
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Learning R00k's Joy

Postby r00k » Thu Oct 18, 2012 5:17 pm

since as it natural comes it doesn't distinguish between new connections and reconnects


I use a bit flag in SetNewParms, parm10 = CA_NEW_CLIENT;
then in ClientConnect, if (parm10 & CA_NEW_CLIENT)... do new client stuff like ban checking etc.. parm10 = parm10 - CA_NEW_CLIENT;
reconnecting clients will go thru this function but wont have that parm10 set.
r00k
 
Posts: 1110
Joined: Sat Nov 13, 2004 10:39 pm


Return to Engine Programming

Who is online

Users browsing this forum: No registered users and 1 guest