Purpose of ammo_... variables in clientdata_t struct

[noodlecollie]

I'm creating new weapons in my own FWGS HLSDK fork, and have noticed the following variables within the clientdata_t struct (which seems to be used for prediction):

int ammo_shells;
int ammo_nails;
int ammo_cells;
int ammo_rockets;

I've run a search on their usage and they only seem to be transferred around - no part of the code ever uses them for anything other than an assignment from one clientdata_t to another. They're also referenced from net_encode.c in the Xash3D engine, I'm assuming to define the data that must be transferred across the network to represent the player.

Can anyone shed some light on what these are used for (if anything)? I'm wondering whether I need to account for them if I create new ammo types, but if they're redundant I'll just remove them completely from my engine/library forks.

[a1batross]

Look in HUD_PostRunCmd, it's a main weapon prediction entry point. ammo_rockets, as I remember, holds RPG rockets itself. ammo_shells used for shotguns. Don't be confused with names, they just derived from Quake.

You may reuse them, if you want to. Most important that they should be defined in delta.lst, so engine will know that this field must be delta-encoded and sent to client.

[a1batross]

And... don't removed it from structure itself. It will break binary compability! If you don't want send them over the network, just remove from delta.lst.

[noodlecollie]

In my case my engine and HLSDK forks are quite closely dependent (I've had to make non-trivial changes already to support new BSP formats), so binary compatibility with other GoldSrc mods isn't really a concern for me as long as my libraries can talk to my build of the engine.

In any case, things still seem to run fine with those variables removed (none of them were actually used for anything), so I guess that answers the question.

[a1batross]

I don't see any reason to make changes in shared definitions. They are flexible enough, only if you don't want to run original Nightfire DLLs.

So if you changed something in shared structures, you need to recompile both HLSDK and Xash.