If that fix works, he just made Kurgan's day.
Sometimes vehicle missiles bounce off walls when they should explode right away (IE: atst rockets when ur at a certain angle up against a wall)
Sometimes the muzzle for vehicle weapons is not properly set so like if your in the ATST on siege_hoth and up against some of the relatively small boxes, they still somehow block your shots because the missiles are being created down towards the bottom of the vehicle sometimes.
Shields tend to block projectiles above their visual height and I don't see why they would...
Many times shields are made extremely tiny if placed in some areas like on the bridge on hoth sometimes, or just made with really retarded angles where things don't turn out so nice.
*BUMP*
Big bug can be found in lots of places in JKA code especially the anim parsing:
http://www.quakesrc.org/forums/viewtopic.php?p=47222#47222)
Read the post below the one in link Timbo has some insight on why its bad ;).
I believe where they have if ( !token || !token[0] ) is fine but having just if ( !token ) is not :S
Ambient Sounds Seem To Get Lost After snd_restart and the imfamous Sound bug in siege.
slightly cosmetic issue in multiplayer, when a player dies, whatever saber they use for saber1 (which is actually saber[0]) gets reset to default. The reason for this is in CG_BodyQueueCopy, where no eType is being set for the new entity. Although this is a cosmetic issue, further inspection into this seems to show a LOT of issues.
For now, I've fixed the cosmetic issue, and need to work on the remaining issues involved. This is a client side bug, sorry server side mods :(
cg_servercmds.c, function CG_BodyQueueCopy:
Look for:
cent->bodyFadeTime = 0;
cent->bodyHeight = 0;
cent->dustTrailTime = source->dustTrailTime;
trap_G2API_DuplicateGhoul2Instance(source->ghoul2, ¢->ghoul2);
if (source->isRagging)
Change this to:
cent->bodyFadeTime = 0;
cent->bodyHeight = 0;
cent->dustTrailTime = source->dustTrailTime;
//// Griswald -- cent needs an eType to pass on for proper saber model setting.
//// Stock JKA Bug. This is a corpse, so ET_BODY should suffice.
cent->currentState.eType = ET_BODY;
trap_G2API_DuplicateGhoul2Instance(source->ghoul2, ¢->ghoul2);
if (source->isRagging)
in cg_weapons.c, function CG_G2WeaponInstance:
Look for:
if (cent->currentState.eType != ET_PLAYER &&
cent->currentState.eType != ET_NPC)
{
return g2WeaponInstances[weapon];
}
if (cent->currentState.eType == ET_NPC)
{
ci = cent->npcClient;
}
Change this too:
if (cent->currentState.eType != ET_PLAYER &&
cent->currentState.eType != ET_NPC && cent->currentState.eType != ET_BODY)
{
return g2WeaponInstances[weapon];
}
if (cent->currentState.eType == ET_NPC)
{
ci = cent->npcClient;
}
However, the remaining issues still remain, the ONLY saber being checked is saber[0], and this is the only saber being passed into CG_G2WeaponInstance, and is the only saber being checked inside. Possible memory leak anyone?
I would suggest using an unused variable in centity_t such as vChatTime for the body and pimp the client number on it, then in CG_G2WeaponInstance you can have the client-info for the proper client.
I've found that there is a bug with ClientBegin...
You must catch PERS_SPAWN_COUNT before the ps is cleared, and then copy it back in after being cleared.. Otherwise you will find CG_Respawn on the client is not called like it is supposed to on *every* spawn. This is mostly noticable in siege or if you are trying to call a script on client for every spawn such as I do with Lua.
so do something like
int spawn_count;
copy eflags...
spawn_count = client->ps.persistant[PERS_SPAWN_COUNT];
... clear ps ...
copy eflags back...
client->ps.persistant[PERS_SPAWN_COUNT] = spawn_count;
it's not copied as part of the normal persistant save?
no its in ps.persistant[] not client.pers->
and ClientBegin itself, doesn't actually save anything... I found this while inspecting Enemy Territory as to why CG_Respawn is called in ET but not Q3 or JK at ClientBegin.
Ah, gotcha. Mind adding that fix to the OJP code?
I suppose though my svn build and code isnt exactly capable of being uploaded at the moment. :rolleyes:
My 2 cents to this thread: clean ways to counter the q3fill attack (as opposed to counting the number of connections from the same ip during a given period, which works but allows some bots to get in)
The bots' userinfo is not exactly built like that of a regular player ; some info is missing, and other is specific to a fake. So, in ClientConnect(), just check whether Info_ValueForKey(userinfo, "model") for instance, is null or not. If it is, then it's a fake.
Conversely, if Info_ValueForKey (userinfo, "cl_guid"), for instance, is not the empty chain, then it is a fake.
Ways around that fix: for the first one, the attacker can add relevant info directly using q3fill. For the second one, they would need to alter q3fill source code and rebuild it. Either way it should keep the vast majority of attackers away, and I haven't seen any false positive.
yeah as you pointed out the big problem with checking stuff like that is that anyone could rebuild q3fill, and only one guy needs to do it and post it on the internet for it to become a big problem again...
Theres also a bug where many of the char arrays are bigger than they need to be in ClientConnect and ClientUserInfoChanged... And some are pointers when they should be sized arrays.
My 2 cents to this thread: clean ways to counter the q3fill attack (as opposed to counting the number of connections from the same ip during a given period, which works but allows some bots to get in)
The bots' userinfo is not exactly built like that of a regular player ; some info is missing, and other is specific to a fake. So, in ClientConnect(), just check whether Info_ValueForKey(userinfo, "model") for instance, is null or not. If it is, then it's a fake.
Conversely, if Info_ValueForKey (userinfo, "cl_guid"), for instance, is not the empty chain, then it is a fake.
Ways around that fix: for the first one, the attacker can add relevant info directly using q3fill. For the second one, they would need to alter q3fill source code and rebuild it. Either way it should keep the vast majority of attackers away, and I haven't seen any false positive.
I don't see how cl_guid makes any difference, JA doesn't use it. The latest q3fill lets you append any cvar AFAIK. Plus you can do it without q3fill and just append cvars mostly in commandline if you want to append bogus sh1t.
BTW, IP data cannot be spoofed on ClientConnect() and I have IPSPOOF protection anyway (which is different from # of connections thing).
I took a look at that rtf of ur code pieces and it looks kind of disgusting plus you have some structs or arrays that we don't even see in there... Clean it up if you expect any of the non-hardcore modders here to know what any of it means.
1) You can put the cvars in the cvartable and then you dont need those trap calls or using the ints/floats in the function and just call theVmCvar.integer
2) You're using a lot of strcpy on char XX[size] when that can be rly bad.
3) I think you could probably copy Q_stricmp and make a regular Q_strcmp for strcmp... and stricmp usage should be Q_stricmp because of strcasecmp hack for linux.
4) G_LogPrintf( "Sent command : [%s]\n", text ); should not use this whole thing because G_LogPrintf will take a dump if its big as well. I use Q_vsnprintf now for it though so it doesn't matter.
5) Checking string length could/should be done in G_Say not Cmd_Say_f and Cmd_Tell_f.
6) Your improved log messages don't take account for bots.
I use:
ClientConnect: num [ip] \"name\"\n
BotConnect: num \"name\"\n
ClientRename: num [ip] \"oldname^7\" -> \"newname\"\n
BotRename: num \"oldname^7\" -> \"newname^7\"\n
ClientDisconnect: num [ip] \"name\"\n
BotDisconnect: num \"name\"\n
7) What is the purpose of storing clientNum? You are never a different client number unless you fully disconnect.
8) IP Address in userinfo is lost after ClientConnect usually.
I don't see how cl_guid makes any difference, JA doesn't use it. The latest q3fill lets you append any cvar AFAIK.
With model you can append it, with cl_guid it is hardcoded into q3fill, so you can't just append it like that, and the point IS that bots use it while JKA don't. And since you can't append a "null" cl_guid, this will work even if the attacker appends whatever he wants...
As long as nobody modifies q3fill.
I took a look at that rtf of ur code pieces and it looks kind of disgusting plus you have some structs or arrays that we don't even see in there... Clean it up if you expect any of the non-hardcore modders here to know what any of it means.
That's why I didn't post the whole thing here ;) I just posted the idea, which I know, for having tested it thoroughly, works.
The rest is off-topic since it is pertaining to my mod and the way I coded things (which I know is far from perfect ; I'm an amateur, too used to the convenience of C++ classes, and I learned both C and the JKA SDK at the same time I was writing this...).
However, since you are kindly offering your help, I'd be very foolish to ignore it :)
1° Yep, I figured that a little late in the game. But why does Raven use it that way ? In CheckVote, for instance : if (trap_Cvar_VariableIntegerValue("g_gametype") != level.votingGametypeTo)
2° I use it 3 times in ClientConnect, and the buffer is large enough to receive it in all cases. Did you mean I should use Q_strncpyz instead ?
3° "strcasecmp hack for linux" What's that ?
4° Yep. I'll just cut it to a reasonable length. What's Q_vsnprintf ? couldn't find it in the SDK.
5° Why? G_Say and G_SayTo are called only by these two, so cutting it in Cmd_*_f also cuts it for G_Say(To). I've tested q3msgboom with say, say_team and tell ingame, and there is no problem.
6° The whole userinfo is stored in the logs right from the start, so it is stored for bots too. Making the log entry different for bots is a very good idea though :)
7° It is used for autokicking, in the # connect/time case : I need the client nums of the last connected clients, in order to kick them all, and not just the clientNum of the current connecting client.
8° Er. Ok. So ? I never use it anywhere after ClientConnect.
edit : typos
1° Yep, I figured that a little late in the game. But why does Raven use it that way ? In CheckVote, for instance :
I'm not really sure, there are some cases that they just didn't want too and this one might even be a Q3 thing not JKA specific... I think it is because there are some cases like after restarts or if its going to restart or if it is a latch cvar, that the value in the vmCvar is not correct however the cvar_t data is always correct so that is probably why.
Lightsaber loading code seems wrong on client side...
When a player has a staff saber that you don't have, it should probably load parameters for "dual_1" instead of just the defaults maybe? Because if you've ever played on a JA- server without its client or the extra sabers and somebody is using a staff that you don't have, it looks like people are using staff moves with the default single saber. :<
It's a good idea, but is there a way to tell if a saber is a staff saber without the .sab file info?
Uhhh... I suppose probably not.
Also: I found your bugfix for the Mods Menu:
basejka:
columns 1 2 40 20
ojp:
columns 1 2 40 280
in the LISTBOX for mods part of setup.menu
It seems as though they changed it in the setup.menu for SP in the actual assets but in the SDK, and ui/jamp it seems incorrect.
Edit: again i looked in assets3 and it looks like 1.01 fixed that for basejka too but the menus that come with the SDK are 1.00 or something. :rolleyes:
Good thing you found it. I had totally forgotten about that. :)
Yea that one was stumping me :/
CG_INCOMING_CONSOLE_COMMAND
Has issues when you're trying to grab /say cmd...
If you're checking if command contains 'say' and you type message in the chat box or just type in console without /say it will not recognize it as having come from 'say'.
There is nothing that can really be done about this without the engine.
For whatever reason I do not know why but they disabled cg_simpleItems for flags...
easy fix:
cg_ents.c, Function: CG_Item, Line: if ( cg_simpleItems.integer && item->giType != IT_TEAM ) {
Comment out the not team type part.
Is there a reason why obituary inherits the origin of the player that died? That makes no sense, its just printing a message. It has svf_broadcast anyway... No sense wasting bandwidth. Change self->r.currentOrigin to vec3_origin (0,0,0).
EV_SIEGESPEC can also be changed, as its just setting a a value on the client when sent to the client of te->s.owner. If anyone else thinks of any others, please do let me know. Generally G_TempEntity is what you would look for. Certain things though, do depend on the origin. You wouldn't want to change saber or fire effect stuff for sure. But messages and just simple setting stuff really shouldn't be used. Player Teleport is needed though. I'm also considering whether or not it would be good to change the default behavior of target_screenshake because I just don't see why you would want a screen shake to be a global effect like it is defaulted so. As seen here:
void SP_target_screenshake(gentity_t *ent)
{
G_SpawnFloat( "intensity", "10", &ent->speed );
//intensity of the shake
G_SpawnInt( "duration", "800", &ent->genericValue5 );
//duration of the shake
G_SpawnInt( "globalshake", "1", &ent->genericValue6 );
//non-0 if shake should be global (all clients). Otherwise, only in the PVS.
ent->use = Use_Target_Screenshake;
}
Remove the UI_CacheSaberGlowGraphics and static qhandle defines for saber shaders. As the fixme says its busted on vid_restart. Remove instances of this func and move the qhandles into cachedAssets_t and also set them in AssetCache().
Why in heck are the item bounding boxes different when dropped from normal?
FinishSpawningItem:
VectorSet (ent->r.mins, -8, -8, -0);
VectorSet (ent->r.maxs, 8, 8, 16);
LaunchItem:
VectorSet (dropped->r.mins, -ITEM_RADIUS, -ITEM_RADIUS, -ITEM_RADIUS);
VectorSet (dropped->r.maxs, ITEM_RADIUS, ITEM_RADIUS, ITEM_RADIUS);
bg_public.h:
#define ITEM_RADIUS 15 // item sizes are needed for client side pickup detection
:smash:
Not really sure which way people wanna have it.
That is weird, do you know how some mods make items physics objects and allows them to be pushed/pulled around?
Yes, mine does. Some mods actually create a new launched entity which is really bad, and just hide the original.
I just let them move it around but store the normal position to return to.
Hell, even JA+ puts the stupid hologram on (weapons and powerups) because slider doesn't know how to properly do it, really annoying too cuz you cannot then pick up dropped weapons if you already have it if it was pushed/pulled, which doesn't make any sense at all. Funny may it be, but what if i want to pull ammo from a guy i just killed towards me?
What do you do? Have a timer on it that makes it return to a position after it hasn't been affected a while? I tried making items a physics object but for some reason they still don't move around, I tried even editing the force_throw code to allow items to be allowed to move around but no luck.
} else if ( em_itemPush.integer && CheckPu****em( push_list[x] ) ) { //rolling and stationary thermal detonators are dealt with below
if ( push_list[x]->item->giType == IT_TEAM ) {
push_list[x]->nextthink = level.time + CTF_FLAG_RETURN_TIME;
push_list[x]->think = ResetItem; // return to original spot after CTF_FLAG_RETURN_TIME ms
} else {
push_list[x]->nextthink = level.time + 30000;
push_list[x]->think = ResetItem; // return to original spot after 30 seconds
}
if ( pull ) {
//pull the item
push_list[x]->s.pos.trType = TR_GRAVITY;
push_list[x]->s.apos.trType = TR_GRAVITY;
VectorScale( forward, -650.0f, push_list[x]->s.pos.trDelta );
VectorScale( forward, -650.0f, push_list[x]->s.apos.trDelta );
push_list[x]->s.pos.trTime = level.time; // move a bit on the very first frame
push_list[x]->s.apos.trTime = level.time; // move a bit on the very first frame
VectorCopy( push_list[x]->r.currentOrigin, push_list[x]->s.pos.trBase );
VectorCopy( push_list[x]->r.currentOrigin, push_list[x]->s.apos.trBase );
push_list[x]->physicsObject = qtrue;
push_list[x]->flags |= FL_BOUNCE_HALF;
} else {
push_list[x]->s.pos.trType = TR_GRAVITY;
push_list[x]->s.apos.trType = TR_GRAVITY;
VectorScale( forward, 650.0f, push_list[x]->s.pos.trDelta );
VectorScale( forward, 650.0f, push_list[x]->s.apos.trDelta );
push_list[x]->s.pos.trTime = level.time; // move a bit on the very first frame
push_list[x]->s.apos.trTime = level.time; // move a bit on the very first frame
VectorCopy( push_list[x]->r.currentOrigin, push_list[x]->s.pos.trBase );
VectorCopy( push_list[x]->r.currentOrigin, push_list[x]->s.apos.trBase );
push_list[x]->physicsObject = qtrue;
push_list[x]->flags |= FL_BOUNCE_HALF;
}
}
I store the original position and such and whether it has spawned originally.
CheckPu****em checks to see if the item is suspended, has a hologram below it, or is flag and check against cvar being 2 to allow dropped flags to move.
Oh ok, thanks a ton Ensi.
Why in heck are the item bounding boxes different when dropped from normal?
Not really sure which way people wanna have it.
I'd use the normal bounding boxes in both cases. The dropped bbox sizes aren't what most people expect.
Fixed Bug where maps that have pits but do not have "nodrop" surface down in the pit thus flags that fall/tossed/pushed/pulled down will sit there until they expire.
Above G_RunItem:
// double size of items
static vec3_t itemMins2 = {-16, -16, 0};
static vec3_t itemMaxs2 = ;
This is what I did in G_RunItem:
Note, the code includes my method of item push/pull checking, and is not necessary for basejka.
Below the following statement:
if ( tr.fraction == 1 ) {
return;
}
I added:
if(ent->item && ((ent->flags & FL_DROPPED_ITEM) || (em_itemPush.integer && ent->think == ResetItem)))
{
int entityList[MAX_GENTITIES];
int i, cnt;
gentity_t *other;
gentity_t *t;
vec3_t mins, maxs;
VectorAdd(ent->r.currentOrigin, itemMins2, mins);
VectorAdd(ent->r.currentOrigin, itemMaxs2, maxs);
cnt = trap_EntitiesInBox(mins, maxs, entityList, MAX_GENTITIES);
for( i = 0; i < cnt; i++)
{
other = &g_entities[entityList[i]];
if(other == ent)
{
continue;
}
if(other && other->inuse && !Q_stricmp(other->classname, "trigger_hurt"))
{
if(ent->item->giType == IT_TEAM)
{
Team_FreeEntity(ent);
}
else
{
if(ent->think == ResetItem)
{
ResetItem(ent);
}
else
{
G_FreeEntity(ent);
}
}
return;
}
if(other && other->inuse && (!Q_stricmp(other->classname, "trigger_multiple") || !Q_stricmp(other->classname, "trigger_always") || !Q_stricmp(other->classname, "trigger_once")) && other->target && other->target[0])
{
int hash = BG_StringHashValue(other->target);
t = NULL;
while ((t = G_FindByTargetnameFast(t, other->target, hash)) != NULL)
{
if(t && t->inuse && !Q_stricmp(t->classname, "target_kill"))
{
if(ent->item->giType == IT_TEAM)
{
Team_FreeEntity(ent);
}
else
{
if(ent->think == ResetItem)
{
ResetItem(ent);
}
else
{
G_FreeEntity(ent);
}
}
return;
}
else
{
continue;
}
}
}
}
}
The infamous obtained wrong item bug is caused by an issue with the engine because events use eventParm stuff which is sent over the network in 8 bits (0-255 range) where entity numbers can be 0-1024 range (10 bits). This cannot be fixed without modifying the engine sadly.
EV_ITEM_PICKUP sends the item that you picked up's entity number and can without a doubt be higher than 255. So, meh :<
Edit: It may actually be doable without the engine (since this may not be the real problem as previously thought/said).
I'm currently testing it with a modified version of the event with a temp entity instead. This would not work well with server-side only mods of course. I also recommend turning off cg_predictItems with this method, as server is always right.
Bug in TIMER_Clear2 that doesn't clear timers on entity 0.
if ( ent && ent->s.number > 0 && ent->s.number < MAX_GENTITIES )
Should be:
if ( ent && ent->s.number >= 0 && ent->s.number < MAX_GENTITIES )
Don't tell me there's more > 0 bugs ._. I might grep the source later on, unless you've already searched for them.
I'm sure there are, and no I really did not. >.<
Mostly in the NPC code you will find a lot of entity 0 stuff.
Unique1's Holocron code that is seen in OJP has an out of bounds bug:
if (number_of_holocronpositions > MAX_HOLOCRON_POSITIONS)
Should be >= because array is 0...max-1
CG_PointContents should use projected origin and angles in-case water is a moving entity such as draining water from an area.
contents |= trap_CM_TransformedPointContents( point, cmodel, ent->origin, ent->angles );
should be:
contents |= trap_CM_TransformedPointContents( point, cmodel, cent->lerpOrigin, cent->lerpAngles );
Hey ensiform, could you point me where's the code related to vehicles? I'm gonna have to take a look in order to make my dragon flyable. If you don't know where's it don't worry, its just that I've downloaded recently the SDK and I haven't looked at it yet, I've started programing in c++ in university and now I can understand things on this thread...:)
btw good job.
Well you can make vehicles without editing the SDK. I would say start by making it a flying type vehicle for now.
CalcEntitySpot has a bug when SPOT_WEAPON is the spot being used...
case SPOT_WEAPON:
//NOTE: automatically takes leaning into account!
if( ent->NPC && !VectorCompare( ent->NPC->shootAngles, vec3_origin ) && !VectorCompare( ent->NPC->shootAngles, ent->client->ps.viewangles ))
{
AngleVectors( ent->NPC->shootAngles, forward, right, up );
}
else
{
AngleVectors( ent->client->ps.viewangles, forward, right, up );
}
CalcMuzzlePoint( (gentity_t*)ent, forward, right, up, point );
break;
But what happens when Ent is neither a player nor an NPC?
Answer: AngleVectors is inputted with an invalid first param and thus causes crashing.
Fix:
case SPOT_WEAPON:
if( ent->client )
{
//NOTE: automatically takes leaning into account!
if( ent->NPC && !VectorCompare( ent->NPC->shootAngles, vec3_origin ) && !VectorCompare( ent->NPC->shootAngles, ent->client->ps.viewangles ))
{
AngleVectors( ent->NPC->shootAngles, forward, right, up );
}
else
{
AngleVectors( ent->client->ps.viewangles, forward, right, up );
}
CalcMuzzlePoint( (gentity_t*)ent, forward, right, up, point );
} else
return;
break;
I put the client check there because, NPC's also have a client pointer. And its not like other things are supposed to be using SPOT_WEAPON anyway... But technically you could do else if client do the ps.viewangles and else do ent->r.currentAngles.
That fixes seeker crashing when trying to shoot at shield(or trying todo something with shield) .
Wonder why its even targeting the forcefield pickup or the forcefield it self for :S.
2 hand lightning effect origin should probably be in middle, not coming from left hand only...
cg_players.c CG_Player:
The following gets changed:
//trap_G2API_GetBoltMatrix(cent->ghoul2, 0, ci->bolt_lhand, &boltMatrix, tAng, cent->lerpOrigin, cg.time, cgs.gameModels, cent->modelScale);
if (!gotLHandMatrix)
{
trap_G2API_GetBoltMatrix(cent->ghoul2, 0, ci->bolt_lhand, &lHandMatrix, cent->turAngles, cent->lerpOrigin, cg.time, cgs.gameModels, cent->modelScale);
gotLHandMatrix = qtrue;
}
efOrg[0] = lHandMatrix.matrix[0][3];
efOrg[1] = lHandMatrix.matrix[1][3];
efOrg[2] = lHandMatrix.matrix[2][3];
to:
if ( cent->currentState.torsoAnim == BOTH_FORCE_2HANDEDLIGHTNING_HOLD )
{//find mid point between two bolts
mdxaBone_t rHandMatrix;
trap_G2API_GetBoltMatrix(cent->ghoul2, 0, ci->bolt_rhand, &rHandMatrix, cent->turAngles, cent->lerpOrigin, cg.time, cgs.gameModels, cent->modelScale);
if (!gotLHandMatrix)
{
trap_G2API_GetBoltMatrix(cent->ghoul2, 0, ci->bolt_lhand, &lHandMatrix, cent->turAngles, cent->lerpOrigin, cg.time, cgs.gameModels, cent->modelScale);
gotLHandMatrix = qtrue;
}
efOrg[0] = ((lHandMatrix.matrix[0][3] + rHandMatrix.matrix[0][3]) * 0.5f);
efOrg[1] = ((lHandMatrix.matrix[1][3] + rHandMatrix.matrix[1][3]) * 0.5f);
efOrg[2] = ((lHandMatrix.matrix[2][3] + rHandMatrix.matrix[2][3]) * 0.5f);
}
else
{
if (!gotLHandMatrix)
{
trap_G2API_GetBoltMatrix(cent->ghoul2, 0, ci->bolt_lhand, &lHandMatrix, cent->turAngles, cent->lerpOrigin, cg.time, cgs.gameModels, cent->modelScale);
gotLHandMatrix = qtrue;
}
efOrg[0] = lHandMatrix.matrix[0][3];
efOrg[1] = lHandMatrix.matrix[1][3];
efOrg[2] = lHandMatrix.matrix[2][3];
}
Alternatively, you could do it like Single Player and play the effect from both hands. (Though is extra things being drawn). So I compensated for this because, it looked as though and the code said that it was only coming from left, and being in center looks a little bit better.
Force Dodge shouldn't work while holding a rocket lock.
Jedi_DodgeEvasion:
if ( self->client->ps.weaponTime > 0 || self->client->ps.forceHandExtend != HANDEXTEND_NONE )
{//in some effect that stops me from moving on my own
return qfalse;
}
=>
if ( self->client->ps.weaponTime > 0 || self->client->ps.forceHandExtend != HANDEXTEND_NONE || self->client->ps.rocketLockTime > 0 )
{//in some effect that stops me from moving on my own
return qfalse;
}
cg.snap->ps.fd.forcePowerLevel[] does not contain real data for most powers.
As far as I can tell its only FP_LEVITATION (1) and FP_SEE (14)
does that cause problems with the client side prediction?