How does the engine read the players weapon?

[Mexicouger]

I looked into how cl.stats[STAT_WEAPON] Worked, and I tried adding a new stat to keep track of other floats I have in the engine.

Just how exactly do you add new values to store like more health, or shields, or other values?

[r00k]

the cl.stats[STATS_WEAPON] is mainly used for the hud, the server uses ent->v.weapon, but for netQuake there isnt a placeholder for the weapon in hand in the client state sent to everyone on the server. I think QW has this, which makes viewWeapons possible.

You might have to modify the protocol, in cl_parse.c

[ceriux]

i think hes talking about adding another parm.

[Mexicouger]

Another parm?

I am talking about, how does the engine read cl.sats[STAT_HEALTH], and then you can use it in QC as .float health, and the engine will know what it is, so I can add new values myself.

[Spike]

the server is lazy and directly knows the health field, which it chucks across the network in a lazy and spammy fashion, which the client explicitly reads into the cl.stats[STAT_HEALTH] stat slot.
yeah, special cases and hacks, gotta love them. :)

specifically, the 'regular' stats are retransmitted in every single svc_clientdata message. You get one of those in every single unreliable packet, so you'll have to forgive my rudeness about this as its a reasonably fair bias. :)
Alternatively, additional stats, up to index 32, can be sent to the client from the server without breaking any network compatibility thanks to the svc_updatestat message. This message can update any slot, but the ammo/health/items slots will be overwritten insanely quick anyway, so its not really practical for that. You can send it from QC with msg_target = self;writebyte(MSG_ONE, svc_updatestat);writebyte(MSG_ONE, $chosen_slot);writelong(MSG_ONE, newvalue);
Doing that will cause the client to write it directly into the cl.stats[] array without any extra work (note that the index MUST be <32 or you'll crash buggy clients - ie: unfixed ones, while others will merely disconnect from the server with a nasty error).
so all you need is that qc code, and to modify your sbar code, no cl_parse.c or sv_send.c changes are required.

try to use stat slots that don't/won't conflict with dp or fte usage, by the way. making your view zoom in every time you switch weapon would be annoying. tip: 32-127 are 'reserved for mods' in the csqc spec, but note that you would need to bump the STATS_MAX value in your client for that.


mvdsv/ezquake's viewwep stuff works due to an additional .vw_index field sent on player entities in an otherwise hidden bit of state. models to be used for each vwep are sent in advance via a stuffcmd. That's not directly portable to NQ, and cannot properly be done using the stats system.
the viewmodel modelindex that you see on your own view is in the STAT_VIEWMODEL, which is different for different clients. its filled in from the .viewmodel field and converted into a modelindex on each and every frame.
STAT_WEAPON is the weapon bitmask currently selected. in missionpacks its the bit number instead (8bit data in both).
cl.items (not technically a stat in NQ but that's a technicality - see last sentance of first paragraph) is the items you currently have.

I'm bored. can you tell?

[Mexicouger]

msg_target = self;
writebyte(MSG_ONE, svc_updatestat);
writebyte(MSG_ONE, $chosen_slot);
writelong(MSG_ONE, newvalue);

What is this? Is chosen_slot a number value or what. What slot is it refering too. And by the way, Thanks.

And how would I do this in sbar.c? What would I call it if my value in QC were
self.ammoweapon;?

Thanks!