Do I need self.value in CSQC?

[toneddu2000]

[gnounc]

global float will do fine.

Client Side QuakeC is handling things from the perspective of the client. that is the player seated at the game.
you can still use entities, you can even create one to hold all your player variables if you so desire.
but if you have RIFLE_USED; the other players games wont be able to override your variable, its local to you.

[toneddu2000]

[frag.machine]

As a rule of thumb, if you are creating a multiplayer game, the server stills being the right place to the core logic. CSQC won't change this (mostly).

[toneddu2000]

[Spike]

if you might be tracking multiple such values at the same time then its going to have to be a field.
if there can be only one, then you can get away with using a global (and thereby save some field space).

think of it in terms of ownership. who owns the value? if its a field, then the owner is the entity that its a field of. and if its a global? then its singular and owned by the entire local csprogs - and as such can only be used for the local player's entity.

as a general rule, if its an animation thing, then you're going to want to be animating all players (us+them) with roughly the same code, and will thus need to use fields in order to stop them fighting over ownership/meaning.
you should not trust any csqc module for anything but user inputs (due to bots+hacks+cheats), and thus you should be determining frames based only upon snapshots from the ssqc (or your local csqc's prediction of said snapshots). for foot sync, using only the .origin+.angle should really be needed (you can determine if the player is onground etc with traceboxes based upon the player's origin, while frame1time can be updated based upon distance traveled instead of sliding on the ground when they're trying to run into a wall), with the ssqc's .frame or whatever just controlling the torso's animations.

splitscreen makes things more complicated. :s

[frag.machine]

[toneddu2000]

[toneddu2000]

[Spike]

CSQC_Parse_Event events have no intrinsic relationship to any entity. you can send an entity index to the client, but the client possibly won't know what you're talking about (if the entity is not within that client's pvs at the time - there's always lag and resends that can give you problems like this). this is why there's a writeentity(), but only a readentitynum() that needs a separate lookup against entnum field, eg {entity e = find(world, entnum, readentitynum()); if (!e) panic();}
this might be fine if its a regular thing like an animation, but you're probably better off just transfering some field like .origin is transferred.
writing to a global when refering to the state of a single entity is dangerous - if your code uses the same global for every entity, that global will necissarily affect every entity that uses it. hence why it bugs out in that they're all affected.

you CAN use CSQC_Parse_Event for throwaway things like spawning particle effects in some weird crazy pattern, you can use it to update the client's hud, or update global state, but affecting a single entity is typically going to be unreliable.

[toneddu2000]