client side GetEdictFieldValue() ?

[frag.machine]

Is there a easy way to add it to a vanilla GlQuake or, at least, FitzQuake ? The idea here is to be able to inspect QuakeC fields during HUD rendering time.

[Spike]

how can that possibly work without csqc?

[mankrip]

That would require a new protocol where all edict fields are sent from the server to the client. This would increase the packet size massively.

[frag.machine]

how can that possibly work without csqc?

That would require a new protocol where all edict fields are sent from the server to the client. This would increase the packet size massively.

Ok, looks like I failed to explain what I have in mind. I know GetEdictFieldValue() is a server side function. I am looking for a way to retrieve information to be used in HUD rendering, and the GetEdictFieldValue() format fits exactly in what I imagined.

Now, I am aware I cannot simply invoke it and expect things to work in the client side, that's why I put a "client side" in the subject. So, rephrasing a bit: "Is there an easy way to write something in the client side that works in the same fashion of GetEdictFieldValue(), but restricted to already available information in the client side ?"

[r00k]

Well I'm not sure what field you are trying to inspect, but without a protocol change, ProQuake uses a svc_stufftext followed by a single byte (0x01) to parse hud messages.

in quakeC the progs.dat uses this...

Code: Select all

void (entity e, float c) pqc_new_team =
{   
   local float msg_type;

   if (e.cl[CL_ACTIVE] == %1)
   {
      msg_entity = e;
      msg_type = MSG_ONE;
   }
   else
      msg_type = MSG_ALL;

   WriteByte (msg_type, SVC_STUFFCMD);
   WriteByte (msg_type, 1);
   WriteByte (msg_type, PQC_NEW_TEAM);
   WriteByte (msg_type, 16 + c & 15); // pants
   WriteByte (msg_type, 16 + c / 16); // shirt
   WriteString (msg_type, string_null);
};



on the client, it parses this way

Code: Select all

      case svc_stufftext:
         // JPG - check for ProQuake message
         if (MSG_PeekByte() == MOD_PROQUAKE)
            CL_ParseProQuakeMessage();

         // Still want to add text, even on ProQuake messages.  This guarantees compatibility;
         // unrecognized messages will essentially be ignored but there will be no parse errors
         Cbuf_AddText (MSG_ReadString ());
         break;
   


and then to...

Code: Select all

void CL_ParseProQuakeMessage (void)
{
   int cmd, i;
   int team, shirt, frags, ping;
   extern void SCR_DrawPing (int ping);
   
   MSG_ReadByte();
   cmd = MSG_ReadByte();
   
   switch (cmd)
   {
   case pqc_new_team:
      Sbar_Changed ();
      team = MSG_ReadByte() - 16;
      if (team < 0 || team > 13)
         Host_Error ("CL_ParseProQuakeMessage: pqc_new_team invalid team");
      shirt = MSG_ReadByte() - 16;
      cl.teamgame = true;
      cl.teamscores[team].colors = 16 * shirt + team;
      //Con_Printf("pqc_new_team %d %d\n", team, shirt);
      break;
...


Yes this is very much a kludge, but it works for all clients and would be ignored on clients that dont have pqc_ extensions.

[frag.machine]

Actually it's a clever (albeit hacky) way to dodge protocols limits. Anyway, what I had in mind wasn't involving any additional interaction between server and client.

[Spike]

What are you actually trying to get?

All the hud info is stored in eg cl.stats[STAT_HEALTH].
Entity info is stored in cl_entities[cl.viewentity].modelindex, I think (QW is different, so don't blame me if I'm wrong!).

So yeah, what exactly are you trying to get?

[frag.machine]

What are you actually trying to get?

All the hud info is stored in eg cl.stats[STAT_HEALTH].
Entity info is stored in cl_entities[cl.viewentity].modelindex, I think (QW is different, so don't blame me if I'm wrong!).

So yeah, what exactly are you trying to get?

I am trying to NOT access this information directly. "Why ?" You ask. Simple: a) because it's hardwired to the current implementation (for example, you need to know the value for STAT_HEALTH) and b) because this way is heavily dependent of the engine programmer to extend HUD functionality (what if a mod adds a .float inventory in the QuakeC side and people want to show this information in the HUD ?).

[Spike]

I never asked why, I asked what.

a) A number is a numerical name, whereas a string is an inefficient name. WriteByte(svc_updatestat); WriteByte(STAT_CUSTOM); WriteLong(self.customfield); will work if you don't want to mod the server, where 'STAT_CUSTOM' is your field's networked name.
b) If you're extending the hud, you're either an engine programmer so what does it matter if its heavily dependant, or you're using csqc, in which case you can just pass over whatever info you want via stuffcmds or whatever.

If you're trying to read qc fields from the client without modding the server or client, to make a hud which you're not making either because its too enginey... then you're both trying to achieve the impossible and contradicting yourself in the process.
I'm confused.

[mh]

It may also be the case that there's also a simpler way of doing what you want to do that doesn't involve having to cross client/server boundaries in any way. But without knowing more info it's difficult to give any pointers here.

An interesting alternative is to use Baker's principle of "when nobody's looking you can do whatever you like" and just access sv.edicts directly from the client. This only works for SP games, but it is a valid approach if it suits your requirements, if you code carefully enough around it, and if you're prepared to accept the consequences.

[frag.machine]

I never asked why, I asked what.

a) A number is a numerical name, whereas a string is an inefficient name. WriteByte(svc_updatestat); WriteByte(STAT_CUSTOM); WriteLong(self.customfield); will work if you don't want to mod the server, where 'STAT_CUSTOM' is your field's networked name.
b) If you're extending the hud, you're either an engine programmer so what does it matter if its heavily dependant, or you're using csqc, in which case you can just pass over whatever info you want via stuffcmds or whatever.

If you're trying to read qc fields from the client without modding the server or client, to make a hud which you're not making either because its too enginey... then you're both trying to achieve the impossible and contradicting yourself in the process.
I'm confused.

Don't be confused. It's quite simple actually. I am just trying to figure out a way to let non-engine coders to redefine and customize the hud via console commands. So people can just write, say, "hud big 0 0 client[0].health" and 3 big digits are drawn in the selected position; they don't need to care if the info is stored in cl_entities[cl.viewentity].v.health or cl.stats[STAT_HEALTH] or another exotic C structure. Likewise, if we had a way to access from the client all the available info in the QuakeC (like entities fields and globals) that would open a lot more options to customize the HUD.

@mh: yeah, I am considering the "if it's single player, then I can do anything I want" option, too. I was just wondering if there would be a better way to access the interpreter information. r00k comment about the embedded ProQuake message into stufftext also is an option.