Q3 Engine Game Bugs / JA bugs

[Lathain Valtiel]

If that fix works, he just made Kurgan's day.

[ensiform]

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.

[ensiform]

*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

[ensiform]

Ambient Sounds Seem To Get Lost After snd_restart and the imfamous Sound bug in siege.

[Griswald]

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, &cent->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, &cent->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?

[ensiform]

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.

[ensiform]

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;

[razorace]

it's not copied as part of the normal persistant save?

[ensiform]

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.

[razorace]

Ah, gotcha. Mind adding that fix to the OJP code?

[ensiform]

I suppose though my svn build and code isnt exactly capable of being uploaded at the moment.

[Gamall Ida]

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.

[dumbledore]

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...

[ensiform]

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.

[ensiform]

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 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.

[Gamall Ida]

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

[ensiform]

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.

[ensiform]

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. :<

[razorace]

It's a good idea, but is there a way to tell if a saber is a staff saber without the .sab file info?

[ensiform]

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.

[razorace]

Good thing you found it. I had totally forgotten about that.

[ensiform]

Yea that one was stumping me :/

[ensiform]

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.

[ensiform]

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.

[ensiform]

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;
}