Q3 Engine Game Bugs / JA bugs

[ensiform]

Originally posted by razorace
While on the subject, has anyone else noticed bots wearing the wrong teams in team games?

Also, I have finally fixed the Hoth Bridge exploit if anyone is interested.

never noticed wrong team colors...

i would like that but siege doesnt work for rs or my basejka :/

[razorace]

It doesn't work at all?!

[ensiform]

no, siege gives max cvars error...

actually base works for me now, for some reason all my rs cvars n **** were in base's config...

but i found a bug in cmd_kill_f with siege...

	if ( ent->client->sess.sessionTeam == TEAM_SPECTATOR ) {
		return;
	}

shouldnt it be this, i was playing around and when i was specing when i could move, and pressed kill and i actually died again...

	if ( ent->client->sess.sessionTeam == TEAM_SPECTATOR || ent->client->tempSpectate > level.time ) {
		return;
	}

[razorace]

Well, it probably means that RS has simply added too much cvars to the game. I've heard once that it's possible to increase the limit but I've never confirmed that.

[ensiform]

not without the engine :/ whats weird is even when i dont make any of them stored in the config either, usually that is what causes it. i suppose u could probably get away with creating another cvartable...

[ensiform]

havent been able to fix this yet but:

bot_nochat doesnt really work. ima look into it but im not sure if it is even fixable in mod.

Edit: no i really dont think it is possible without making my own cvar.

[razorace]

Couldn't you just alter the bot chat function so it just disables if the cvar is set.

[ensiform]

maybe but the cvar doesnt exist in the game code. i got it working using bot_nochat2.

in ai_util.c find the function BotDoChat

just below the gentity_t *cobject; line add:

	if (bot_nochat2.integer)
	{
		return 0;
	}

you will of course need to make the cvar in g_local.h and g_main.c.

[razorace]

Why not just use the original bot_nochat cvar?

[ensiform]

cause it doesnt exist and it may do something else in the engine and i dont want to **** it up.

[razorace]

Well, if it's not in the code, it's not in the code. I wouldn't worry about it.

[ensiform]

grr... only send 20 clients wtf ?

comment this out in g_cmds.c DeathmatchScoreboardMessage

	if (numSorted > MAX_CLIENT_SCORE_SEND)
	{
		numSorted = MAX_CLIENT_SCORE_SEND;
	}

(MAX_CLIENT_SCORE_SEND=20)

[razorace]

It's probably because the scoreboard are only hold 20 client's stats at once. (guessing)

[ensiform]

should be able to hold more, i know the one in red slushie / ensimod can.

[razorace]

*shrug* well, it was probably also done for bandwidth reasons as well but it's worth a shot.

[zERoCooL2479]

more of an annoyance than a bug, but here goes:

In g_ICARUScb.c

static void Q3_LCARSText ( const char *id)
{
	G_DebugPrint( WL_WARNING, "Q3_ScrollText: NOT SUPPORTED IN MP\n");
	//trap_SendServerCommand( -1, va("lt \"%s\"", id));

	return;
}

should be:

static void Q3_LCARSText ( const char *id)
{
	// MJN - fix: typo in warning message.
	G_DebugPrint( WL_WARNING, "Q3_LCARSText: NOT SUPPORTED IN MP\n");
	//trap_SendServerCommand( -1, va("lt \"%s\"", id));

	return;
}

[razorace]

Is that scripting used anyway?

[zERoCooL2479]

Yeah, it is part of the ICARUS scripting engine for map events.

[razorace]

But is it ever used?

[ensiform]

Client bug: when using graphical hud, armor value doesnt show > 100 even if u have more than 100.


so open up cg_draw.c. we want CG_DrawArmor.

add int realArmor;

add the realArmor line:

	armor = ps->stats[STAT_ARMOR];
	realArmor = ps->stats[STAT_ARMOR]; // add this line below the above line

below this section:

	if (armor> maxArmor)
	{
		armor = maxArmor;
	}

add:

	if (realArmor > 200)
	{
		realArmor = 200;
	}

now where its drawing the numfield, change it from armor to realArmor.

		CG_DrawNumField (
			focusItem->window.rect.x, 
			focusItem->window.rect.y, 
			3, 
			realArmor,
			//armor, 
			focusItem->window.rect.w, 
			focusItem->window.rect.h, 
			NUM_FONT_SMALL,
			qfalse);

[razorace]

When do you ever have more than max armor?

[ensiform]

? if u pick up a large shield you go over 100.

[razorace]

Oh, ok. See I thought you were supposed to go up to 200 and stop there. Maybe that's just the older Jedi Knight games.

[ensiform]

well you really dont need to put a limit on it like it did, i put it there just for safety though.

[dumbledore]

Originally Posted by ensiform

never noticed wrong team colors...

i would like that but siege doesnt work for rs or my basejka :/

im pretty sure by hoth bridge expoit he meant the ctf hoth one, not siege. :/

[ensiform]

ctf hoth exploit? the ctf bridge exploit is where u can get in the bridge on the team sides. the one where u can stack above ppl and jump into the void above it is on JA+ Official Server only. Slider said it had something to do with the pk3s his provider has.

[Kurgan]

Originally Posted by razorace

Oh, ok. See I thought you were supposed to go up to 200 and stop there. Maybe that's just the older Jedi Knight games.

In Jedi Outcast you can have a max of 200 armor (even though the max is 100). If you are at 100 and grab a 100 pickup then it is at 200, but counts down until you're back at 100. In JA, I didn't think that even applied. you could simply never go over 100, at least not in basejka. The most common place you saw this occur in JK2 was on Bespin FFA, as it had two large shield boosts sitting around within easy reach.

JK1 and MotS both had 200 as your shield max IIRC (though MotS Personalities had different maximums, from 175-250). In JA Siege each class has a different shield maximum (ranging from 0-100).

As to the "Hoth bridge exploit" that's commonly being referred to as the one in Siege wherein you can cause an explosion as the objective bridge is being extended, causing it to retract back into the wall and never come out again (this was fixed). The same thing was possible with the "switch based" bridges on Korriban Siege (but you could always re-extend those by force pushing the switch). That other exploit is interesting. You're not supposed to be able to player stack in JA since you slide off their heads, but if you're well coordinated enough you can stay on, and the bots have a real talent for it sometimes... heh

[razorace]

BTW, I should diserve some real props for fixing both the invisible driver bug AND the locked door det pack bugs in the same week.

[Kurgan]

Locked door detpack bug? I guess I forgot about that one... how did it work?

[razorace]

Basically, if you're able to physically block a "locked" door (like the team doors on Siege Hoth), it would unlock the door perminately. This was an issue in siege is attacker could be a big advantage by using their enemy's doors.

[Kurgan]

Ah, I see. So all those people sneaking into Hoth base or past the Rancor gate weren't necessarily relying on "traitors" on the other team to let them through!

Good catch, then!

[razorace]

Well, I can;t take the credit for the discovery, Enisform found it. I just fixed it.

[Tinny]

Teehee, I would mindtrick people and follow them as they're going through a door.

[dumbledore]

Originally Posted by Kurgan

In Jedi Outcast you can have a max of 200 armor (even though the max is 100). If you are at 100 and grab a 100 pickup then it is at 200, but counts down until you're back at 100. In JA, I didn't think that even applied. you could simply never go over 100, at least not in basejka. The most common place you saw this occur in JK2 was on Bespin FFA, as it had two large shield boosts sitting around within easy reach.

it works in basejka too, only thing is that you have to have less than 100 shields before picking up the large one (ie, 99 shields). its easiest to do this on ffa1 at the top where there's a lsb. to see it though you need to use cg_hudfiles 1

[Slider744]

i Just fixed a few things one week ago for JA+ mod...
here is my code for the fixes...

invisibility vehicle driver bug FIX
It allows a player riding a vehicle inside (like atst) to become invisible by reconnecting the server while beeing inside.

add this at the end of ClientSpawn(gentity_t *ent) in g_client.c

//MODIFICATION => FIX the basejka bug when players are invisible after having reconnecting when beeing inside a vehicle with hideRider 1
	
	ent->r.svFlags &= ~SVF_NOCLIENT;
	ent->s.eFlags &= ~EF_NODRAW;
	if ( ent->client )
	{
		ent->client->ps.eFlags &= ~EF_NODRAW;
	}

unlock door exploit FIX
I only fixed it for siege gametype. i don't know if it usefull for other gametype at the moment. Moreover this things seen as a bug in siege mod could be usefull in other gametype for mappers.
we need to prevent a blocked door to be unlock because it might screw up siege objectives

in g_mover.c
change this

/*
================
Blocked_Door
================
*/
void Blocked_Door( gentity_t *ent, gentity_t *other )
{
	if ( ent->damage ) {
		G_Damage( other, ent, ent, NULL, NULL, ent->damage, 0, MOD_CRUSH );
	}
	if ( ent->spawnflags & MOVER_CRUSHER ) {
		return;		// crushers don't reverse
	}


	// reverse direction
	Use_BinaryMover( ent, ent, other );
}

with this

/*
================
MODIFICATION added this special function for blocked door to prevent unlock in siege.
I didn't want tthis fix to work in other gametype than siege at the moment.
Use_BinaryMover_blockedDoor
================
*/
void Use_BinaryMover_blockedDoor( gentity_t *ent, gentity_t *other, gentity_t *activator ) 
{
	if ( !ent->use )
	{//I cannot be used anymore, must be a door with a wait of -1 that's opened.
		return;
	}

	// only the master should be used
	if ( ent->flags & FL_TEAMSLAVE ) 
	{
		Use_BinaryMover_blockedDoor( ent->teammaster, other, activator );
		return;
	}

	if ( ent->flags & FL_INACTIVE )
	{
		return;
	}

	if ( ent->spawnflags & MOVER_LOCKED )
	{//a locked door
		return;
	}

	G_ActivateBehavior(ent,BSET_USE);

	ent->enemy = other;
	ent->activator = activator;
	if(ent->delay)
	{
		ent->think = Use_BinaryMover_Go;
		ent->nextthink = level.time + ent->delay;
	}
	else
	{
		Use_BinaryMover_Go(ent);
	}
}

/*
================
Blocked_Door
================
*/
void Blocked_Door( gentity_t *ent, gentity_t *other )
{
	if ( ent->damage ) {
		G_Damage( other, ent, ent, NULL, NULL, ent->damage, 0, MOD_CRUSH );
	}
	if ( ent->spawnflags & MOVER_CRUSHER ) {
		return;		// crushers don't reverse
	}

	//MODIFICATION FIX only for SIEGE => each time there is something under a door like a player, or det pack ... the door will reopen and will be unlocked
	// so player can lame siege gametype where some doors are locked and unlocked only if some objectives are completed.
	//Use_BinaryMover will unlock the MOVER entity like a doors or teammaster (for group mover items) ==> it needs to be prevent.
	
	// we need to prevent a blocked door to be unlock but only in siege at the moment. i don't know if it usefull for other gametype at the moment. Moreover this things seen as a bug in siege mod could be usefull in other gametype for mappers.
	if(g_gametype.integer == GT_SIEGE){
		
		Use_BinaryMover_blockedDoor( ent, ent, other );
		return;
	
	}

	// reverse direction
	Use_BinaryMover( ent, ent, other );
}

DetPAck exploit FIX
This exploit allows player to kill teamates or destroy siege team objectives that they should protect from the other teams.
To use this exploit you have to fire some det packs and then going to spectator or disconnecting the server while the detpack are not exploding yet...
DOing that all the det pack will explode and kill teamates or team objectives...etc...

in g_combat.c
add in G_Damage
after

	if (targ->flags & FL_BBRUSH)
	{
		if (mod == MOD_DEMP2 ||
			mod == MOD_DEMP2_ALT ||
			mod == MOD_BRYAR_PISTOL ||
			mod == MOD_BRYAR_PISTOL_ALT ||
			mod == MOD_MELEE)
		{ //these don't damage bbrushes.. ever
			if ( mod != MOD_MELEE || !G_HeavyMelee( attacker ) )
			{ //let classes with heavy melee ability damage breakable brushes with fists
				return;
			}
		}
	}

add this

	//MODIFICATION FIX : to prevent detpack to blow teamate members and teamate siege objectives when the attacker is switching to spectator or disconnect the server
	if(mod == MOD_DET_PACK_SPLASH && ! (attacker && attacker->inuse && attacker->client && attacker->client->pers.connected == CON_CONNECTED ) )
		return;
         if(mod == MOD_DET_PACK_SPLASH && attacker && attacker->inuse && attacker->client && attacker->client->pers.connected == CON_CONNECTED
		&& 
			(	attacker->client->sess.sessionTeam == TEAM_SPECTATOR 
				|| 
				( g_gametype.integer == GT_SIEGE && attacker->client->sess.siegeDesiredTeam == TEAM_SPECTATOR)
			)		
	)
		return;

[razorace]

haha, great minds think alike. I fixed several of those errors at well. However, I did them a little differently. As always, all OJP bugfixes are available thru the OJP CVS repository.

invisibility vehicle driver bug FIX

The real source of that problem is the unghostrider function not being called for disconnected players. I just made the unghostrider function always apply since there's no reason not to.

unlock door exploit FIX

I just relocked the doors after the Use_BinaryMover but that works too.

I haven't actually fixed the last one yet.

[Kurgan]

Razor, so that means you've now fixed the AT-ST invisibility exploit? Cool!

[Slider744]

Originally Posted by razorace

I just relocked the doors after the Use_BinaryMover but that works too.

yes i did that in my first fix because i saw a similar coding in the basejka code somewhere else...

but i prefered to recoder another function...
i didn't think it was good to unlock the doors then call the function and then reclock the doors...

[razorace]

Yeah, I was a bit wary about that as well. However, it seems to work fine.

[stubert]

all of this should really go into one mod =/