Quake3World

I'm debugging a mod created by someone else. It has MAX_WEAPONS set to 21 instead of the standard 16. This is the size of ps.ammo[]. And this seems to work. It seems that the elements with index > 15 are only used by the server, not by the bg_* stuff. Does this mean that only the first 16 elements are transmitted from the server to the client? Otherwise the playerstate would have been screwed up, as far as I can tell.

EDIT: seems that cgame uses index > 15 too, which is sort of confusing.

no the stats can over 16 bits and you will most likely need a new playerState_t item. and send that through msg.c (need the engine source) i havent exactly figured this one out yet... as you need to send a different bit count, i guess u could use 32 but 64 is more efficent.

with a mod, you cannot increase MAX_WEAPONS to more than 16 because its shared with the engine. (q_shared files shouldnt be modified, only added too if absolutely need be)

Now I know why it works. He has changed the sizes of the arrays, and removed and added a few fields. But it all adds up to the same size as in vanilla q3.

In q_shared.h:

// bit field limits
#define MAX_STATS 16
#define MAX_PERSISTANT 10
#define MAX_POWERUPS 13
#define MAX_WEAPONS 21

// 4 ints have been used for other variables, so total ints of 60 instead of 64 here

so this is a engine mod not a regular mod?

It's a regular mod, vanilla quake3.exe. The web site is in my sig.

you cannot modify those values for a regular mod, trust me, you do it you crash.

powerups and weapons are sent as 16 bit arrays in the engine.

Download the mod and try for yourself. I can promise you it works. And it's one of the coolest q3 mods ever. :icon31:

Maybe later I'll have a look in the engine code to see what's really going on with playerstate.

ensiform wrote:you cannot modify those values for a regular mod, trust me, you do it you crash.

powerups and weapons are sent as 16 bit arrays in the engine.

It's certainly possible, but I for one wouldn't recommend it. A better solution would have been to implement a marshalling/demarshalling scheme for the existing data structures such that you can define what you want in the playerstate on a higher level. You could even get clever and have it time multiplex to inflate the data limit a little.

It's all water under the bridge now though I guess, given that if you use the Q3 source you can just-damn-change-it(tm).

Will modifying the values and builidng a new engine destroy mod compatibility though?

Hmmm ... the mod code doesn't do the transmitting and receiving directly, so maybe it won't destroy it?

The engine source is great, compiles right out of the box on Mac

just make the mod a standalone game :icon26:

Riiiiight. But keeping mod compatability == instant standalone-ness.