Properly adding new QC floats to the engine

[Ghost_Fang]

So ive been digging around and i think i have a small idea on how. I just want to clarify.

You have your basic self.health, self.weaponframe, etc in the QC and the engine recognizes them and you can use them with cl.stats[STAT_HEALTH].
What if I have my own floats such as self.clipammo, self.bagammo, etc. How do i move those to cl.stats[STAT_CLIP] and cl.stats[STAT_BAGAMMO]?

Am i on the right track with SV_WriteClientdataToMessage in sv_main.c and CL_ParseClientdata in cl_parse.c?

[Baker]

Leads:

1) Look at the implementation of .alpha in FitzQuake 0.85 versus FitzQuake 0.80.
2) Look at Kurok Windows build versus FitzQuake 0.80 windows build. MDave didn't really add any new statistics in Kurok, but he re-used the existing fields.
3) Look at progsdef.q1 in the engine source.

I think after you look at what you would need to change (protocol, cl_parse.c, QuakeC changes like I believe defs.qc as well, many more ... might even change the progs header CRC), you'll likely reach the conclusion you'll be better off creatively re-using existing fields.

... Rather than making additions or subtractions or even renaming fields. The cascade of making alterations adds up to a ton of work, really. But yeah, you have where the data is sent and received correctly identified.

[Ghost_Fang]

Ah, that does seem like alot, But i think i might run out of things to reuse, in addition to the 2 i mentioned i probably have 20-30 more i want to add. What if I implement some sort of new protocol like quake uses for Temp entities like TE_GUNSHOT and TE_EXPLOSION?

for example:

QC:

Code: Select all

WriteByte (MSG_BROADCAST, SVC_CUSTOM);
WriteByte (MSG_BROADCAST, STAT_CLIP);
WriteShort (MSG_BROADCAST, self.clipammo);

Engine:

Code: Select all

void CL_ParseCustom (void)
{
   int      type, value;
   type = MSG_ReadByte ();
       
   switch (type)
   {
   case STAT_CLIP;
       value = MSG_ReadShort();
                 cl.stats[STAT_CLIP] = value;
      break;
};

How would that work out? I'm trying to find the next best alternative to my current method of using cvars....

[offtopic]
By the way Baker, I used your code as seen here: viewtopic.php?p=34517&sid=b13606487316e133cfb87980af37afdd#p34517 to get nice "material" (actually prefix) based bullet decals on the psp. As seen here: http://media.moddb.com/images/games/1/1 ... shot42.jpg the effect turned out nice so thanks for posting that code!

[Baker]

Ah, that does seem like alot, But i think i might run out of things to reuse, in addition to the 2 i mentioned i probably have 20-30 more i want to add. What if I implement some sort of new protocol like quake uses for Temp entities like TE_GUNSHOT and TE_EXPLOSION?

for example:

QC:

Code: Select all

WriteByte (MSG_BROADCAST, SVC_CUSTOM);
WriteByte (MSG_BROADCAST, STAT_CLIP);
WriteShort (MSG_BROADCAST, self.clipammo);

Those aren't in the "reliable stream" like the stats (the sbar stats get sent to a player with every net update --- In single player, I guess it makes no difference since it isn't possible to experience packet loss.). Also, that would be messy because particle effects are sent to everyone, you don't want to send player #1's clipammo to everyone.

Still, if you are making essentially a single player game, it doesn't really matter how you cheat (cvars, whatever) .... you can always make it "proper" in version #2.

The cvars and commands method is a messy/hacky way to get the job done, but you can always aim for version 2 being the "perfect version".

Done Messy > Perfect Version That Never Occurs

I'd stuffcmd everything, personally creating commands on the client side. It isn't the right way to do it, but it won't take weeks. Kurok was chalked to the brim with "evil", so was Nehahra, but we know of those since they were released which means they got finished. You know how to "do it right" and you'd prefer to "do it right" --- but often "doing it right" is not practical and slow as hell.

[*cough Worldcraft Quake Adapter immensely popular hack-beast that should die and maybe TrenchBroom can kill it. /cough*).

[qbism]

Everytime someone uses stuffcmd in qc, one of those little brown monsters eats a kitten. Don't even ask what happens when it's also a closed-source mod... Not to mention, future engine coders love those mysterious crashes, just ask anyone with extended engine limits about Marcher's stuffcmd byte ambient sound at the bell plat.

Alpha uses GetEdictFieldValue to avoid changing entvars_t or progdefs.q1.

[Spike]

msg_entity = someplayerentity;
WriteByte(MSG_ONE, svc_updatestat);//3
WriteByte(MSG_ONE, STAT_MYNEWSTAT);//32+
WriteLong(MSG_ONE, self.mynewstatvalue);
you'll need to re-execute that any time your stat value changes.

then you can directly access the new value via cl.stats[STAT_MYNEWSTAT]

the reason I say STAT_MYNEWSTAT should be 32 or so is because that matches the 'csqc custom range' for mod specific data, meaning you don't step on anyone's toes with stuff like dp_viewzoom etc, but you will need to bump MAX_STATS or whatever its called, and vanilla clients might end up complaining about it because they don't have a bumped value (which would also happen if you used a new svc, so...).
Using writebytes means your server changes are pure qc, no server exe changes.

svc_clientdata is hideous and spammy as fuck. if you're okay with the complete waste of bandwidth you can indeed just add an extra writeshort on the end of it and waste peoples bandwidth and all the demo incompatibility and things that go with it.

[frag.machine]

I understand that Ghost_fang is already using a customized engine, so breaking compatibility shouldnt be a concern.

[Ghost_Fang]

Those aren't in the "reliable stream" like the stats (the sbar stats get sent to a player with every net update --- In single player, I guess it makes no difference since it isn't possible to experience packet loss.). Also, that would be messy because particle effects are sent to everyone, you don't want to send player #1's clipammo to everyone.

Ah my bad, that was a quick copy-paste-edit for the example, What i would have ended up doing is what Spike had mentioned, MSG_ONE:

msg_entity = someplayerentity;
WriteByte(MSG_ONE, svc_updatestat);//3
WriteByte(MSG_ONE, STAT_MYNEWSTAT);//32+
WriteLong(MSG_ONE, self.mynewstatvalue);

Im already using a modified and customized engine for the PSP. So i already accepted my fate of incompatibility. Which is ok, if anyone wants to use the engine bad enough nothing i have added so far is deeply rooted into the engine and removing those things are a minor task. I am also not too concerned with the "spamming" for these will be called when the situations arise. These won't be updating every frame.