PDA

View Full Version : Known Code Bugs and Solutions


razorace
03-31-2003, 12:08 AM
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_O VERRIDE|SETANIM_FLAG_HOLD, 150);
//} //PM_SetAnim(SETANIM_BOTH,BOTH_LAND1,SETANIM_FLAG_OV ERRIDE|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_OVERRI DE|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
03-31-2003, 11:33 AM
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
03-31-2003, 12:39 PM
Yeah, I had noticed that too. Please post if you figure out the solution again. :)

razorace
04-01-2003, 03:36 AM
I've just added a mention of the backward playing animations not working correctly bug to the list.

razorace
04-01-2003, 08:38 PM
Added Saber Spins Can't Hit Jack.

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

razorace
04-01-2003, 10:04 PM
Added My Models Axis Don’t match the ModView Axis!

razorace
04-11-2003, 01:03 AM
Added Sabers Returning to Spectators instead of the Players

LeeOattes
04-11-2003, 12:11 PM
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
04-11-2003, 12:19 PM
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
04-11-2003, 12:38 PM
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
04-11-2003, 12:44 PM
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
04-11-2003, 03:34 PM
Originally posted by LeeOattes
[B]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
04-11-2003, 03:45 PM
Originally posted by LeeOattes
[B]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
04-13-2003, 11:58 PM
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
04-14-2003, 09:52 AM
Why not just change the way the print command is handled in CG_ServerCommands (or whatever it is called).

zERoCooL2479
04-15-2003, 12:37 AM
I'm creating the Serverside only mod, thats why ;)

zERoCooL2479
04-18-2003, 01:01 PM
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
04-18-2003, 04:40 PM
You can't kick people when they're in the red stance?!

zERoCooL2479
04-20-2003, 01:16 AM
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
04-20-2003, 01:27 AM
I see, thanks for the heads up. :)

LeeOattes
04-20-2003, 05:53 PM
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
04-22-2003, 11:33 AM
It is not a bug, it is that way by gameplay design.

razorace
04-22-2003, 06:46 PM
"It's not a bug, it's a FEATURE!"

zERoCooL2479
04-24-2003, 03:51 AM
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
04-24-2003, 11:03 AM
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

Nemios
04-24-2003, 02:30 PM
Can I add a tip? I noticed in MP when you run forward it uses the same animation to run backward and the saber in your hand moves constantly in front of your face. Instead in SP the saber is held almost at your side. Is this possible to fix? Is it possible to simply "rename" the animation file (if it exist) to fix that without a MOD?

zERoCooL2479
04-24-2003, 11:55 PM
Originally posted by Nemios
Can I add a tip? I noticed in MP when you run forward it uses the same animation to run backward and the saber in your hand moves constantly in front of your face. Instead in SP the saber is held almost at your side. Is this possible to fix? Is it possible to simply "rename" the animation file (if it exist) to fix that without a MOD?

Anything that you edit in the game source has to be made into a "mod" However, there are cfg files you can use to substitute animations I think. Check here.

http://www.lucasforums.com/showthread.php?s=&threadid=98001



Originally posted by 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.

What I did was the following:

Do a search for Fall_fading. You will see it in g_active.c Under the part where it says "// die" put this:

WP_SaberInitBladeData( ent );

So now it should look like this:

//**************Cut Text*******************
if (ent->client && ent->client->ps.fallingToDeath &&
(level.time - FALL_FADE_TIME) > ent->client->ps.fallingToDeath)
{ //die!

WP_SaberInitBladeData( ent ); // Invisible Saber Fix
player_die(ent, ent, ent, 100000, MOD_FALLING);
respawn(ent);
ent->client->ps.fallingToDeath = 0;

G_MuteSound(ent->s.number, CHAN_VOICE); //stop screaming, because you are dead!
}

That pretty much does it. But the root of the problem still lies within the saber shield bug. I can't seem to figure out that one. Any leads?

LeeOattes
05-02-2003, 10:58 PM
Originally posted by zERoCooL2479
That pretty much does it. But the root of the problem still lies within the saber shield bug. I can't seem to figure out that one. Any leads?

Well, your fix will work in the case where the player dies by falling, but you can also reproduce this by dieing in other ways ;-). Jumping off a cliff is the easiest....

The actual problem is the following. When a saber is in flight, the server entity is visible to the client and uses a different think function than normal. When a saber is attached to a player it is not visible to the client at all and only the server "sees" it. The think function when attached to a player should be "saberupdateself". However when the bug/exploit is engaged the think function is "saberreturntoowner" -- this is the think function for a flying saber. When the bug/exploit is engaged, the damage is caused because you have a saber attached to a client that thinks it is in flight (it does not check re: holstered state).

Now why is this the case? Well that is interesting indeed and I don't think I can claim anything more than a guess. Here it is:

When the saberreturntoowner function is the "think" function for the saber it is constantly checking to see if the owner is dead. Eg. in the function you will see:

if (g_entities[saberent->r.ownerNum].health < 1 || !g_entities[saberent->r.ownerNum].client->ps.fd.forcePowerLevel[FP_SABERATTACK] || !g_entities[saberent->r.ownerNum].client->ps.fd.forcePowerLevel[FP_SABERTHROW])
{ //He's dead, just go back to our normal saber status
saberent->touch = SaberGotHit;
saberent->think = SaberUpdateSelf;
saberent->bolt_Head = 0;
saberent->nextthink = level.time;

saberOwner->client->blockedThrow=qfalse;
MakeDeadSaber(saberent);

saberent->r.svFlags |= (SVF_NOCLIENT);
saberent->r.contents = CONTENTS_LIGHTSABER;
VectorSet( saberent->r.mins, -SABER_BOX_SIZE, -SABER_BOX_SIZE, -SABER_BOX_SIZE );
VectorSet( saberent->r.maxs, SABER_BOX_SIZE, SABER_BOX_SIZE, SABER_BOX_SIZE );
saberent->s.loopSound = 0;

g_entities[saberent->r.ownerNum].client->ps.saberInFlight = qfalse;
g_entities[saberent->r.ownerNum].client->ps.saberThrowDelay = level.time + 500;
g_entities[saberent->r.ownerNum].client->ps.saberCanThrow = qfalse;

return;
}


This code *should* work and correctly set the saber think function (and a few other things) back to "normal" if the saber owner is dead. However, when you hold the attack key down while you die, you spawn *right* away. This code does not actually get a chance to run before you respawn and your health is no longer < 1.

I tried setting the think time very short (eg. zero wait) and the code still fails to run. I can only conclude that when you respawn right away, the actual path taken through the game code does not actually run the saberreturntoowner function before the spawn.

Here is how I fixed it:

- go to player_die and check the saber think function when a player dies.
- if it is saberreturntoowner, reset the saber think (and other bits).

In combat.c, player_die, i added the following:

if ( self->client->ps.saberEntityNum )
{ // player has a saber, check it out for invisible saber bug/exploit (lmo)
// not sure why the code in w_saber.c does not catch this. I can only assume
// that if you respawn really quickly, that code never see's health less than 1hp!
// So, i just check here to make absolutely sure....
saberent = &g_entities[self->client->ps.saberEntityNum];
if( saberent->think == saberBackToOwner )
{ // reset think function to normal

saberent->touch = SaberGotHit;
saberent->think = SaberUpdateSelf;
saberent->bolt_Head = 0;
saberent->nextthink = level.time;

self->client->blockedThrow=qfalse;

MakeDeadSaber(saberent);

saberent->r.svFlags |= (SVF_NOCLIENT);
saberent->r.contents = CONTENTS_LIGHTSABER;
VectorSet( saberent->r.mins, -SABER_BOX_SIZE, -SABER_BOX_SIZE, -SABER_BOX_SIZE );
VectorSet( saberent->r.maxs, SABER_BOX_SIZE, SABER_BOX_SIZE, SABER_BOX_SIZE );
saberent->s.loopSound = 0;

self->client->ps.saberInFlight = qfalse;
self->client->ps.saberThrowDelay = level.time + 500;
self->client->ps.saberCanThrow = qfalse;
}
}


cheers,


Lee

zERoCooL2479
05-15-2003, 08:38 PM
Nice job Lee...Works great. I never knew you can get the "invisible saber" other than falling. :(