How does the server know your client is keeping track?

(S. Monkey) #1

I’ve just started playing with the source code today. I made a mini-mod that turns off medic regenerate for 5 seconds whenever the medic is damaged, and shockingly it worked right the first time. :slight_smile:

Anyway, my question is how does the server know the client is doing this properly? I implemented it by adding a new variable to playerState_s, and there is a comment immediately above it saying that you can’t put anything in that class if it needs transmitting over the network. This got me thinking - would a stat like this need to be checked at the server end as well?

([RW]FRED) #2

Argggg U can’t modify playerState_s & entityState_t structure!!! Read comments above the definition

(S. Monkey) #3

How come? it says you can’t modify it unless the information doesn’t need to be transmitted to the server (which at the time I thought it didn’t).

(Tavington) #4

Well Nerve added a few things into playerstate_t so it must be possible.

The documentation mentions msg.c , a file which doesn’t exist. Is g_cmds.c the corresponding file?

I’m trying to add stuff to playerstate_t and keep getting client prediction errors as the documentation suggests. Someone plz help!

([RW]FRED) #5

That structures are size fixed, because the Q3/ET Engine carry over network a packed version. And some fields are partially transmit like eFlags (only 24bits carried) and on some 32bits only 16bits are carried too.

I’m trying to add stuff to playerstate_t and keep getting client prediction errors as the documentation suggests. Someone plz help!

Ahah.
Well I’ll give u some infos to do what u want: If u want carry infos from server to client: some fields of playerState_t are carried but not used in game such as ps->holding, ps->holdable (32 bits fields, but 16bits transmitted) if 16 integer are insuficient, u can split the array ammo & ammoclip into 2 shorts. That arrays are 16bits transmitted. Remember too that playerState_t are not resent from the client ot the server.
It remains also in the persistant.stats one or 2 slots available.

In entityState_t u have some multiple usage available fields as effect1Time, effect2Time, effect3Time, and others. In some circunstances u can use it for ur own usage.

In that struct don’t typecast for ur usage an int to a float!!! use origin2/angles2 to carry extras.

msg.c file is a source file of the engine: NOT PUBLIC

(S. Monkey) #6

Alright, if doing it the way ive done it causes network problems ill find another.

The comment above playerstate_t says something about a pmext struct being a better place to put stuff, but I can’t find it. Any ideas?

edit: im looking at hijacking another variable. are any of the powerup variables not used?

(Rain) #7

If the client doesn’t need to know anything about your change (and I gather it doesn’t), just edit gclient_s, which is local to the qagame module. If you put it in the playerstate, you’ll waste bandwidth every time it changes if the client doesn’t use that data for something.

([RW]FRED) #8

Right too but he didn’t give details about what he would to do and i’d supposed that he would share datas accross server&client

([RW]FRED) #9

Powerups is an array of 16 x 16bits, it’s used to known if the player is carrying the objective PW_RED_FLAG or blue and also to carry extra infos for disguised players such class etc. Also becarefull ps->powerups are recopied into ent->s.powerups as a bitfield to notify others players and the powerups are timebased so the server will clear the used slot in g_active.c until u modify the file. it’s preferable to used the unused “holding” field in ps.

(S. Monkey) #10

Which keeps track of the health, server or client? I’d have thought both would have.

Anyhow, I’ve now got it using powerup[] in playerstate_t, but it has stopped working. ive used an available element of the array (13 wasn’t being used).

(S. Monkey) #11

What exactly does holding (and hodable[]) do? I’d like to know before I hijack it totally.

(Rain) #12

Both keep track of health, but the client doesn’t predict the health value at all–it always uses the value in the playerstate (stats[STAT_HEALTH]), which is updated in every snapshot (which should be received 50ms under normal conditions.) There’s probably no need for the client to know about your change, but perhaps you’re doing something unusual that you haven’t described…

The holdable[] array is a leftover from RtCW SP.

(S. Monkey) #13

Both keep track of health, but the client doesn’t predict the health value at all–it always uses the value in the playerstate (stats[STAT_HEALTH]), which is updated in every snapshot (which should be received 50ms under normal conditions.) There’s probably no need for the client to know about your change, but perhaps you’re doing something unusual that you haven’t described…

The holdable[] array is a leftover from RtCW SP.[/quote]

Thanks.

I’m stopping the player regenerating, so yes Id have to keep the client informed.

g_active.c is run on the server, isn’t it? (apologies for dumbness)

(Rain) #14

The client doesn’t do anything but display the health value that the server gives it… Are you certain you need to communicate any additional information to the client?

And yes, g_active.c is run on the server. All of the g_* files are for qagame (the server-side gamecode), all the cg_* files for cgame (the client-side gamecode), all the ui_* files for the user interface stuff (menus and the like), and bg_* for ‘both games’ (files shared between all 3 gamecode modules (although ui only uses a couple of the bg_* files.))

(S. Monkey) #15

Well, it changes your health value, so it needs to tell you, doesn’t it?

Anyhow, I put it in the holdable[] and it works quite happily now, without any changes to q_shared.c

Thanks for the help.

(Rain) #16

Right, but there’s already a field for your health… why the redundancy?

(S. Monkey) #17

I see what you mean, at the moment I’m transmitting the time until the medic starts regening again.

As far as I know, I’m not short on variable space in playerstate_t yet, but if I were to be could you suggest where else I can stick it?

(SCDS_reyalP) #18

nerve had access to the engine source

The documentation mentions msg.c , a file which doesn’t exist.

because it is most likely in the engine. If you change a structure that the engine expects to have a particular layout, Bad Things will happen.

(Rain) #19

Well, the medic regeneration is done entirely on the server, so you probably don’t need to transmit the time to the client.

If you don’t need to transmit data to the client, you can add fields to gclient_t and gentity_t all you like (the engine only cares about entityState (s) and entityShared ® in that struct.)

(Tavington) #20

So there’s no unused variable in playerstate_t that is 32 bits?