Game Development Community

The LH_HACK code...

by James Urquhart · in Torque Game Engine · 07/07/2004 (9:53 am) · 3 replies

Lets have a look at this snazzy code block in game/player.cc...

#define  LH_HACK   1
// Hack for short-term soln to Training crash - 
#if   LH_HACK
static U32  sBalance;

bool Player::displaceObject(const Point3F& displacement)
{
   F32 vellen = mVelocity.len();
   if (vellen < 0.001 || sBalance > 16) {
      mVelocity.set(0, 0, 0);
      return false;
   }

   F32 dt = displacement.len() / vellen;

   sBalance++;
   
   bool result = updatePos(dt);
   
   sBalance--;

   getTransform().getColumn(3, &delta.pos);
   delta.posVec.set(0, 0, 0);

   return result;
}

#else

bool Player::displaceObject(const Point3F& displacement)
{
   F32 vellen = mVelocity.len();
   if (vellen < 0.001) {
      mVelocity.set(0, 0, 0);
      return false;
   }

   F32 dt = displacement.len() / vellen;

   bool result = updatePos(dt);

   mObjToWorld.getColumn(3, &delta.pos);
   delta.posVec.set(0, 0, 0);

   return result;
}

#endif

From what i can tell, by default the code uses the "LH_HACK" method, which is identical to the normal method, except there is a "sBalance" counter.
However, the "sBalance" counter does not appear to do anything useful - it is incremented once before updatePos(), and decremented again afterwards.
Another thing is that even if "sBalance" reached 16, there is no way for it to decrement back down so the rest of the code is called at a later time.
Perhaps sBalance was meant to be altered by script - but i'm pretty sure its not so anymore.
Whats even more shocking is that it is not even initialized - so there is no guarantee its going to be 0!

Seems like this is a very long term short term hack :)

#1
07/07/2004 (10:40 am)
You're active today, James. :P

I think that sBalance was put in place in the tribes 2 days to work around some obscure problem that involved a non-terminating recursion. I agree that this is a horrible hack, if you have a fix I'd love to see it! :)
#2
07/07/2004 (10:49 am)
Hmm... from the comments it would appear this was a fix for a crash that occured in the training missions
#3
07/07/2004 (11:18 am)
Looks like a nasty way to cap the maximum input into a cumulative variable (i.e. dont let velocity go over too big a number).

Presumably this code is called multiple times to tick some physics function and often went out of range (i.e. in team17 parlance it "went off to neptune", so someone hacked in a cap that just stopped it iterating after 16 goes.

Nasty nasty stuff.