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]

[Baker]

[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]