playerState_t::holding

(jaybird) #1

I’m trying to use holding (currently using bit 1) to get info from the server to the client. I have a piece of code in g_active.c - clientthink_real that is assigning this. I have also tried it in clientendframe to no avail. I am using the value in cg_draw.c. It seems no matter where I try this assignment, cgame is not receiving the value. Is there anything special I need to be doing here?

(jaybird) #2

Ah yeah, I tried accessing this through cg.snap->ps and cg.predictedPlayerState.

(SCDS_reyalP) #3

playerState_t and entityState_t are shared with the engine. That means you can’t go changing them and expect it to work. See the comments in q_shared.h

You will have to find unused bits to stuff your inforation into, or send it some other way.

(Jaquboss) #4

you have there around 5 free (well almost free) int(s) …
and do this not in clientthink_real , but in playerstate2entitystate functions…
and at last cg.snap->ps and cg.predictedPlayerState are not using entityState_t at all…
IMO it is worst think in modding that centity_t doesnt has playerState_t but only entityState_t…

(jaybird) #5

Right. The holding (int) variable isn’t used, so I used it. So do this in ps2es and it should work, ok. Now where I access this in client code? Sorry I didn’t understand the last couple of sentences Jaquboss.

(Jaquboss) #6

well , i want to say that entitystate_t is used for example as centity_t->currenstate …
and my last sentence was stupid i was complaing about reducing playerstate to entitystate…

(jaybird) #7

Got a list of usable vars?

(jaybird) #8

Alright this is getting a bit frustrating. I’m trying to get a single bit from GAME to CGAME, and it’s definitely not obvious. The bit is provided from GAME, and the function to get it is not (easily) accessible from the BG files. Basically I’m trying to implement an ETPro feature: artillery or airstrikes not available. I used entityState_t::density to get the value to the CGAME code (and when it’s hard coded to set to 1, of course it works). To update the variable I’m using in game code (ps.holding), I’m doing it in clientendframe. I cannot seem to get this value across to cgame. I am doing the assignment from ps to es in bg_playerstatetoentitystate(extrapolate as well). What’s the easiest way to do this?

(KillerWhale) #9

Etpro uses a configstring for that, you can look it up with /configstrings:
(looks something up)
They use configsting 43 for that in this format:
axis\1\allies\1
The value behind the team indicates if arstrikes/arty is available (1=available 0=not available).

That should be really easy to implement without breaking a unmodified client.

(KillerWhale) #10

There are a few bits you can use to send info from the GAME to the CGAME, look how etpub did that with sending the playdead state to the client.

(jaybird) #11

Heh. Thanks for pointing out the obvious. Dunno why I was trying to do it the other way :slight_smile:

(bani) #12

you really want to use a configstring for this.

(jaybird) #13

I did :slight_smile:

But, the failure of what I was trying to do is frustrating. I’m really just starting on some of my ideas on some client mods, but getting client-specific information to cgame seems impossible from what I’ve tried so far. Any pointers?

(bani) #14

try using one of the ps.pers slots. ent->client->ps.persistant[bla] on the server, and cg.snap->ps.persistant[bla] on the client.
try PERS_BLEH_2 as its unused.

(jaybird) #15

Ok. So, snap’s playerstate is send to cgame. Are the members of cg.snap->ps an automatic copy of the server’s information, or are its values explicitly assigned somewhere? I ask this because, as above, I was trying to use ent->client->ps.holding, but I could not seem to get the value with cg.snap->ps.holding. Thoughts?

(Jaquboss) #16

well , maybe u should make it in bg_ pmove.c ( you can read that pm and ps should be there ), also tryed cg.predictedPlayerState ?

(jaybird) #17

Tried cg.predictedPlayerState. But the game code modified PS values outside of the BG files, so why should it matter? It’s too troublesome sometimes to use game-only code in BG stuff sometimes. There’s got to be an easier way than that, right?