pointerstat explanation (and case study) (draft)

STATS are variables sent to CSQC by the server to each client, and normally contain information about themselves (their own localplayer). ie as a player, they usually contain information about you, your health, ammo, armour, etc, so they can be displayed in your HUD. But what if it’s a multiplayer game, and you want your CSQC to get information about *other* players, so you can (eg) display *their* health, or some other .variable (of theirs) your client wouldn’t normally have access to? For this example we’ll stick w one int, which will store 32 boolean values about other players.

[code language=”c”]
//ssqc globals
const int STAT_FOO_0 = 50;
.int foo; // this int will store 32 bools regarding each player, which will be sent to CSQC. (Your code might already have an equivalent .variable you can use)
[/code]

Next, we set aside 32 integer slots for STATs.

[code language=”c”]
// near the top of worldspawn
for (int i = 0; i<32; i++)
{
pointerstat(STAT_FOO_0+i, EV_INTEGER,edict_num(i + 1).foo);
}[/code]

When the map starts, before anything else happens (top of worldspawn) pointerstat creates 32 stats (STAT 50 – STAT 82) which are pointers to the .foo(integers) used by the entities (1 – 32) (which are players).
So:
Player 1’s .foo =  STAT 50
Player 2’s .foo = STAT 51
.
.
Player 32’s .foo = STAT 82

These STATS are sent to each client, and contain information about other players.

Here’s the CSQC part:

[code language=”c”]
//CSQC global
const int STAT_FOO_0 = 50;
.float foo; // reminder, .foo is a local CSQC variable, no relation to its ssqc namesake (until we give it the values, as explained below)
[/code]

[code language=”c”]
//self is a player, here via deltalisten
// self.entnum is this entity’s actual number on the ssqc server
self.foo = getstati(STAT_FOO_0 + self.entnum-1); //this fills the variable self.foo with the value of the STAT which is ‘the ent number (1-32)’
[/code]

TROUBLESHOOTING:
Scenario 1: ssqc entity 70 (not a client) is using ‘the mdl which runs deltalisten’

70-1 is 69. CSQC will access STAT 69, what *should* have been player/entity .19’s foo. it will either get wrong/irrelevant data, or if there is no player 19, it will get 0 [TODO: we need a way to distinguish players from bots, or (easier) just use a different mdl]

Scenario 2: ssqc entity 200 (not a client) uses ‘the mdl which runs deltalisten’

200-1 is 199. CSQC will access STAT 199, and there IS NO STAT 199!! Hence:

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>