Known Code Bugs and Solutions

[razorace]

I'm starting this to let people know what the known bugs (and solutions to) for the current JK2 code.

 

BOTH_ATTACK10 / BOTH_THERMAL_THROW Tag surface bug (Razor Ace)

Both

 

Problem: The *r_hand tag surface on the BOTH_ATTACK10 / BOTH_THERMAL_THROW animations is messed up. It doesn’t follow the hand and causes the Thermal Detenator to float away from the hand when these animations are played.

 

Solution: Repair animation. Not possible at the moment.

 

 

Animation Skip while Exiting a Roll (Razor Ace)

Both

 

Problem: There’s an animation skip in while exiting a Roll.

 

Solution:

 

Place this Code:

else if ((pm->ps->pm_flags & PMF_ROLLING) &&
	PM_InRollComplete(pm->ps, pm->ps->legsAnim))
{
bobmove = 0.5;
pm->ps->legsTimer = 0;
pm->ps->legsAnim = 0;
//if( !pm->ps->saberHolstered )
//{
//	PM_SetAnim(SETANIM_BOTH, //PM_GetSaberStance(),SETANIM_FLAG_OVERRIDE|SETANIM_FLAG_HOLD, 150);
//}
//else
//{		PM_SetAnim(SETANIM_BOTH,BOTH_STAND1,SETANIM_FLAG_OVERRIDE|SETANIM_FLAG_HOLD, 150);
//}		//PM_SetAnim(SETANIM_BOTH,BOTH_LAND1,SETANIM_FLAG_OVERRIDE|SETANIM_FLAG_HOLD, 150);
pm->ps->torsoTimer = TIMER_LAND;
pm->ps->legsTimer = TIMER_LAND;

}

After this code (bg_pmove.c, PM_Footsteps() ) :

if ( pm->ps->pm_flags & PMF_DUCKED )
{
int rolled = 0;

bobmove = 0.5;	// ducked characters bob much faster

if ( PM_RunningAnim( pm->ps->legsAnim ) && !BG_InRoll(pm->ps, pm->ps->legsAnim) )
{//roll!
	rolled = PM_TryRoll();
}
if ( !rolled )
{ //if the roll failed or didn't attempt, do standard crouching anim stuff.
	if ( pm->ps->pm_flags & PMF_BACKWARDS_RUN ) {
		if ((pm->ps->legsAnim&~ANIM_TOGGLEBIT) != BOTH_CROUCH1WALKBACK)
		{
			PM_SetAnim(SETANIM_LEGS, BOTH_CROUCH1WALKBACK, setAnimFlags, 100);
		}
		else
		{
			PM_ContinueLegsAnim( BOTH_CROUCH1WALKBACK );
		}
	}
	else {
		if ((pm->ps->legsAnim&~ANIM_TOGGLEBIT) != BOTH_CROUCH1WALK)
		{
			PM_SetAnim(SETANIM_LEGS, BOTH_CROUCH1WALK, setAnimFlags, 100);
		}
		else
		{
			PM_ContinueLegsAnim( BOTH_CROUCH1WALK );
		}
	}
}
else
{ //otherwise send us into the roll
	pm->ps->legsTimer = 0;
	pm->ps->legsAnim = 0;
		PM_SetAnim(SETANIM_BOTH,rolled,SETANIM_FLAG_OVERRIDE|SETANIM_FLAG_HOLD, 150);
	PM_AddEventWithParm( EV_ROLL, 0 );
	pm->maxs[2] = CROUCH_MAXS_2;
	pm->ps->viewheight = DEFAULT_VIEWHEIGHT;
	pm->ps->pm_flags &= ~PMF_DUCKED;
	pm->ps->pm_flags |= PMF_ROLLING;
}
}

Pistol Weapon Change Issue (Razor Ace)

Both

 

Problem: The player’s head jumps/jerks to the side when…

 

1. Switching to the pistol.

2. Switching from the pistol to the saber.

 

Solution: Pending…..

 

TurAngles (Razor Ace)

Client

 

Problem: The default TurAngles data is incorrect. There should only be YAW data in this angle vector varible.

 

Solution:

 

Move (cg_player.c, CG_G2PlayerAngles):

	
VectorCopy(legsAngles, cent->turAngles);

From (cg_player.c, CG_G2PlayerAngles):

legsAngles[ROLL] = 0;
torsoAngles[ROLL] = 0;

VectorCopy(legsAngles, cent->turAngles);

if (cent->isATST)
{
legsAngles[ROLL] = 0;
legsAngles[PITCH] = 0;
}

To(cg_player.c, CG_G2PlayerAngles):

if (cent->isATST)
{
legsAngles[ROLL] = 0;
legsAngles[PITCH] = 0;
}

// pull the angles back out of the hierarchial chain
AnglesSubtract( headAngles, torsoAngles, headAngles );
AnglesSubtract( torsoAngles, legsAngles, torsoAngles );

legsAngles[PITCH] = 0;

//<ra><R2>  Fixed general issue with the turAngles
VectorCopy(legsAngles, cent->turAngles);
//</ra></R2>

AnglesToAxis( legsAngles, legs );
// we assume that model 0 is the player model.

 

Backward Playing Animations Don't Work (Razor Ace)

Client

 

Problem: Animations with negative frame rates don't run right. From experimentation, we know that the Server side is running the animations correctly while the Client side isn't.

 

Solution: Pending

 

Saber Spinning Can't Hit Jack (Razor Ace)

Server

 

Symptoms: Saber Spinning having poor hit detection.

 

Problem: The server side animation calls don’t use the speed adjust function BG_SaberStartTransAnim for both the leg and torso spin animations if the client side does. This causes the player to spin at the wrong speed. Also, since the animations play so quickly the saber positional update has trouble hitting stuff.

Solution: Pending

 

My Models Axis Don’t match the ModView Axis! (Razor Ace)

Both

 

Symptoms: Saber blade not pointing the right direction on your saber hilt, The bolt directions axis don’t match ModView.

 

Problem: Modview’s X and Y axii are switched in Modview. The correct axii are used in Modview and 3dsm.

 

Solution: Raven needs to fix the ModView program.

 

Sabers Returning to Spectators instead of the Players (LeeOattes)

Server

 

Symptoms: Thrown sabers returning to a spectator instead of the correct player.

 

Problem: “The specator bug is, in fact, a basejk bug. More accurately, it is a bug in the source distribution from Raven and does not seem to actually happen with the binary 1.04 versions. I have tracked the bug down and fixed it. The bug will be in any other mod unless it is fixed. I have confirmed it is present in adminmod, jediplus, and jedimod. The problem is that when someone spectates and follows some of your data pointers are changed to point at data from the client you are following. These data pointers remain once you cease following. But now, the game code starts updating that data (this is the bug in the code above). In particular, one thing that is updated is the "return" position of the saber of the player that you followed. It's return position is set to the current location of the spectator, so when the saber is thrown, it returns to the wrong player!

 

For some fun, capture someones saber this way. Then move back over to their position (while you are still spectating) and give it back to them!”

 

Solution:

 

Change the follow code (G_RunFrame, g_main.c) from…..

 

This:

if((!level.intermissiontime)&&!(ent->client->ps.pm_flags&PMF_FOLLOW))

To:

if((!level.intermissiontime)&&!(ent->client->sess.sessionTeam == TEAM_SPECTATOR))

(razorace) Note: I haven’t confirmed that bug/fix yet but I have added it to my code just in case.

[Wudan]

Some weapons attack animations end sequence is not the same as the idle animation, this is so in the bryar's case, and the saber animations are handled separately.

 

The Bryar pistol whips up to fire, but it's idle animation is held at the hip.

 

To fix this (although, I think raven doesn't call the animations at the end of a sequence for a good reason, probably bandwidth or something like that) I placed a call to PM_SetAnim for the idle animation at the beginning of PM_Weapon in bg_pmove.c, so that if the player's weapon status was not attacking, he'd be in the idle animation. Rigging something up with timers might be a better idea, but this seemed to work fine.

 

I don't have the exact code, because that was lost with the great Wudan Hard Drive crash of 2003, but I could figure it out again in about 5 minutes.

 

Don't know what I'm talking about? In basejk2, pop the Bryar and fire. Does it go back to the animation you started with?

[razorace]

Yeah, I had noticed that too. Please post if you figure out the solution again.

[razorace]

I've just added a mention of the backward playing animations not working correctly bug to the list.

[razorace]

Added Saber Spins Can't Hit Jack.

 

And remember, "It's not a bug, it's a FEATURE!"

[razorace]

Added My Models Axis Don’t match the ModView Axis!

[razorace]

Added Sabers Returning to Spectators instead of the Players

[LeeOattes]

First, great idea to share common bug fixes! Some comments, follow:

 

Originally posted by razorace

Animation Skip while Exiting a Roll (Razor Ace)

Both

 

Problem: There’s an animation skip in while exiting a Roll.

 

Solution:

 

Place this Code:

 

Hmm, this is interesting. I think I solved this problem by just taking a couple of frames off the end of the animation (ie. edit animation.cfg).

 

I tried your code (with my shorter anmiation) and what I saw was a kind of flutter of hands at the end of each roll. I am not sure this is "better", but what the heck. However, the change does seem to keep you from rolling again right away. That is you cannot string two rolls (or more) back to back. Do you see this too?

 

Sabers Returning to Spectators instead of the Players (LeeOattes)

Server

 

Symptoms: Thrown sabers returning to a spectator instead of the correct player.

 

Problem: “The specator bug is, in fact, a basejk bug. More accurately, it is a bug in the source distribution from Raven and does not seem to actually happen with the binary 1.04 versions. I have tracked the bug down and fixed it.

 

...

 

Solution:

 

Change the follow code (G_RunFrame, g_main.c) from…..

 

This:

if((!level.intermissiontime)&&!(ent->client->ps.pm_flags&PMF_FOLLOW))

To:

if((!level.intermissiontime)&&!(ent->client->sess.sessionTeam == TEAM_SPECTATOR))

(razorace) Note: I haven’t confirmed that bug/fix yet but I have added it to my code just in case. [/b]

 

This fix does definitely fix this specific saber/thow spectator bug in duelers. However, the spectator bug actually occurs deep inside the saber update position code. But in looking things over, I could not figure out why you would ever want to do a forcepower or saber position update for someone who was spectating. That combined with the ability to make a simple one line fix, compelled me to make the change here. There may well be some un-intended side-effects so keep your eyes peeled...

 

Lee

[LeeOattes]

Originally posted by wudan

Some weapons attack animations end sequence is not the same as the idle animation, this is so in the bryar's case, and the saber animations are handled separately.

 

I have seem similar problems with "emote" animations. If you are using saber only you wont see this. However, with full weapons, after an emote (essentially a non-standard animation) the animation can end up in a very different place than the "weapon ready" animation.

 

My solution was I think very similar to yours. Near the beginning of PM_Weapon (righ after the usingATST code), I place a big case statement to check the current animation. If the animation is problematic, I use PM_SetAnim() to reset to weapon ready. I use this just to clean up after emotes, but it could be used for any animation that ends "in the wrong place".

 

//lmo check for emote animations and clean up...

switch ( pm->ps->torsoAnim & ~ANIM_TOGGLEBIT )

{

case BOTH_SIT2: //sit

case BOTH_KNEES1: //beg

case 572: //looks

case 574: //looks

case 587: //flip

case 619: //dest

case 644: //cocky

case 639: //jedi

case 657: //way

case 661: //scratch

case 665: //dunno

case 668: //power

case 733: //barf

case 757: //throw1

case 767: //throw2

case 769: //throw3

case 672: //adjust

case 710: //secretissafewithus

case 626: //spintaunt

case 603: //super

case 704: //thumbsdown

case 726: //draw

case 913: //dance1

case 914: //dance2

case BOTH_HEADNOD: //nod

case BOTH_HEADSHAKE: //shake

case BOTH_KISSER1LOOP: //kiss

case 666: //shrug

case 1: //sleep

case 937: //bounce

case 943: //breakdance

case 1049: //kneel

case 1055: //slap

case 131: //punch

case 130: //punch

PM_SetAnim(SETANIM_TORSO, WeaponReadyAnim[pm->ps->weapon], 0, 0);

break;

default: // do nothing

break;

}

 

cheers,

 

Lee

[LeeOattes]

You may have seen this too. When you have force speed or force rage on, try a roll. The roll seems to stop you short and occurs almost "in place". I would rather expect that the roll would behave "normal" just at a higher speed and carry you the same distance (although faster).

 

The problem is in the the speed control code for the roll. In PM_SetAnimFinal, tmer duration is adjusted if force speed and rage are on. However, in BG_AdjustClientSpeed, this potential adjustment is not accounted. To "fix"...

 

if ( BG_InRoll( ps, ps->legsAnim ) && (m_rs.integer ? ps->speed > 200/tck.ps[ps->clientNum].speed_scale : ps->speed > 200 ) )

{ //can't roll unless you're able to move normally

BG_CmdForRoll( ps->legsAnim, cmd );

if ((ps->legsAnim&~ANIM_TOGGLEBIT) == BOTH_ROLL_B)

{ //backwards roll is pretty fast, should also be slower

ps->speed = (m_rs.integer ? ps->legsTimer/(2.5*tck.ps[ps->clientNum].speed_scale*tck.ps[ps->clientNum].speed_scale) : ps->legsTimer/2.5 );

}

else

{

ps->speed = (m_rs.integer ? ps->legsTimer/(1.5*tck.ps[ps->clientNum].speed_scale*tck.ps[ps->clientNum].speed_scale) : ps->legsTimer/1.5 ); //450;

}

if (ps->speed > (m_rs.integer ? 600/tck.ps[ps->clientNum].speed_scale : 600))

{

ps->speed = (m_rs.integer ? 600/tck.ps[ps->clientNum].speed_scale : 600);

}

//Automatically slow down as the roll ends.

new! //lmo fix force speed and force rage weirdness

new! if ( ps->fd.forcePowersActive & (1 << FP_SPEED))

new! {

new! ps->speed *= 1.7*1.7;

new! }

new! if ( ps->fd.forcePowersActive & (1 << FP_RAGE))

new! {

new! ps->speed *= 1.3*1.3;

new! }

}

 

Note, your code wont look excactly like this, cause this code is already modfied for the duelers mod. However, the lines marked with new! are the parts you want to add.

 

Note, the first factor is to remove the factor introduced by PM_SetAnimFinal and the second factor is to correct roll speed for force speed or rage.

[LeeOattes]

I have also corrected a number of things that bothered me about the base game. I did this a while back and did not keep notes about how, sigh. However, I wanted to note them and if there is general interest, I will "rediscover" the fixes and post them here.

 

1. Force points. Do you allocate all your force points in saber only games and then find that the next time you connect you have some force points again? When you check do you wonder why the game took the force points away from some force power (e.g. saber throw) when you clearly have enough points to allocate?

 

2. I like to use a red team skin by default. The game never remembers! It sets me back to a default skin the next time I play.

[razorace]

Originally posted by LeeOattes

I tried your code (with my shorter anmiation) and what I saw was a kind of flutter of hands at the end of each roll. I am not sure this is "better", but what the heck. However, the change does seem to keep you from rolling again right away. That is you cannot string two rolls (or more) back to back. Do you see this too?

Well, yeah, what happens is your player is exiting the roll, going to the BOTH_STAND2 and then moving to the correct position. At the time, it was the only way I knew of to make it switch to the current corrent position with animation interplotation. Now that I'm going to fix the animation system, I can probably fix that better, but just haven't gotten to it yet. As for not being able to string two rolls together, there's gotta be something different in your code since I can string together rolls just fine.

[razorace]

Originally posted by LeeOattes

I have seem similar problems with "emote" animations. If you are using saber only you wont see this. However, with full weapons, after an emote (essentially a non-standard animation) the animation can end up in a very different place than the "weapon ready" animation.

 

My solution was I think very similar to yours. Near the beginning of PM_Weapon (righ after the usingATST code), I place a big case statement to check the current animation. If the animation is problematic, I use PM_SetAnim() to reset to weapon ready. I use this just to clean up after emotes, but it could be used for any animation that ends "in the wrong place".

There's a problem with your strategy, you're assuming that the torso timer is always set correctly. While this might work ok for those animation, Raven decided to NOT use timers for a lot of stuff. Meaning that you'll have situations where your animation timers are invalid when they SHOULD be valid. While this works for the most part, it creates a double-standard for people trying to change the code.

 

I've been going thru and making it use PM_SetAnim for everything but I haven't finished that task yet.

[zERoCooL2479]

When the server talks to the clients on it, it prints messages rather ugly. Doesn't return an endline. This is a very small fix but it cleans it up and looks a lot better. In g_svcmds.c, scroll all the way to the bottom where it says:

 

 

if (g_dedicated.integer) {

if (Q_stricmp (cmd, "say") == 0) {

trap_SendServerCommand( -1, va("print \"server: %s\"", ConcatArgs(1) ) );

return qtrue;

}

// everything else will also be printed as a say command

trap_SendServerCommand( -1, va("print \"server: %s\"", ConcatArgs(0) ) );

return qtrue;

}

 

Just change the word 'print' with the word 'chat'

[Wudan]

Why not just change the way the print command is handled in CG_ServerCommands (or whatever it is called).

[zERoCooL2479]

I'm creating the Serverside only mod, thats why

[zERoCooL2479]

Complaining about not being able to kick people when their doing red? Well, here is the fix!!

 

In g_active.c....void ClientThink_real( gentity_t *ent ) function, search for

 

if ( faceKicked->client->ps.weapon != WP_SABER || faceKicked->client->ps.fd.saberAnimLevel < FORCE_LEVEL_3 || BG_SaberInAttack(faceKicked->client->ps.saberMove) && !PM_SaberInStart(faceKicked->client->ps.saberMove) && !PM_SaberInReturn(faceKicked->client->ps.saberMove) && !PM_SaberInTransition(faceKicked->client->ps.saberMove)) )

{

 

 

replace the < FORCE_LEVEL_3 with <= FORCE_LEVEL_3

 

Take care!

[razorace]

You can't kick people when they're in the red stance?!

[zERoCooL2479]

Yeah you can kick them but they dont get knocked down or move back...A good example of this is have someone in red stance swinging the saber around in loops and kick them. You will see no effect. With this fix, they'll get kicked back or on the ground like in all other stances

[razorace]

I see, thanks for the heads up.

[LeeOattes]

It is not clear to me that this is a bug. Why would the animation level test be there at all if not for the fact that someone *intended* that the red stance would be special? Although I had not noticed this feature in the game, it could make a kind of sense that the "strong" stance would allow you to not be knocked down/back by a kick.

 

However, with the extra orange and purple stances in duelers (or other jedimod based mods), this code does become problematic because it confers the benifits of red stance to orange and purple as well (level 4 and 5). Certainly even if you accept my argument that the base code is representing a "feature" rather than a bug, there is no reason why you should be 'invulerable' to knock-back with the orange and purple stances!

 

thanks!

 

Lee

[Wudan]

It is not a bug, it is that way by gameplay design.

[razorace]

"It's not a bug, it's a FEATURE!"

[zERoCooL2479]

Have you guys heard of this bug? Its where you create your saber shield (throw saber, and when it starts to come back...press and hold attack, move to the right) and then you fall off a cliff.

 

You then respawn with an "invisible saber" that does like 30 damage when you have it holstered. It only resets when you throw the saber again. Anyways, a friend and I had found a way to solve the problem. If you're interested, I can post it here. Or if ya dont know what I'm talking about, I'm sure there are people you know that do.

 

Peace!

[LeeOattes]

Yes, I have been working on this bug. However, though I have a few work arounds, I have not found the actual code problem yet. If you know exactly where it is broken, let me know. The symptoms are in the saberbacktoowner routine, but as yet I don't know why the checks there are failing.

 

 

Lee