Game Development Community

[BUG 1.1Beta] dStrchr or dStrrchr? Code Bug Typo?

by Steve Acaster · in Torque 3D Professional · 02/11/2010 (8:47 pm) · 6 replies

dStrchr
Is this a typo? Should it be == dStrrchr?

Around line 223 of source/ts/tsShapeConstruct.cpp, is where I've made the change.
char fileBuf[MAX_PATH_LENGTH];
      dStrcpy(fileBuf, mSequences[i]);

      // Determine if there is a sequence name after the filename, and if so,
      // split the filename from the sequence name.
 //     char* split = dStrchr(fileBuf, ' ');//yorks out - typo??
 //     char* split2 = dStrchr(fileBuf, 't');//yorks out - typo??
	  char* split = dStrrchr(fileBuf, ' ');//yorks in
      char* split2 = dStrrchr(fileBuf, 't');//yorks in
      if (split2 && (!split || (split2 < split)))
         split = split2;

      char* destName = 0;
      if (split)
NextNext Thread
PrevPrevious Thread
More from Torque 3D Professional


Associate Tom Spilman
Sickhead Games
#1
02/12/2010 (6:13 pm)
dStrchr is searching a string for a character.

dStrrchr is searching a string in reverse for a character.

So either could be valid... depends on what the code should be doing. Chris would know.


Associate Steve Acaster
[YorkshireRifles.com]
#2
02/12/2010 (6:19 pm)
Aha, it's just that it was listed as a correct bug fix in the forums for 1.0 or 1.0.1 (but I can't find the post now).

Hence why I noticed it again in 1.1beta.

Associate Konrad Kiss
Bitgap Games
#3
02/12/2010 (9:20 pm)
I remember this one. It checks for the animation alias - the thing passes it after the full path of the dsq file. If it uses dStrchr and the path has a space then it fails. So the fix should be using dStrrstr to find that space from the other end of the string.

Associate Steve Acaster
[YorkshireRifles.com]
#4
02/16/2010 (12:01 pm)
I'm glad someone's memory works!

--------------

As the subject of this thread is old bugfixes which may or may not have been fixed elsewhere in the code, here's the only other one I could find.

Player.ccp
void Player::onRemove()
{
   setControlObject(0);
   scriptOnRemove();
   removeFromScene();

 if( isClientObject() )//yorks add
   { //yorks add
   U32 i;
   for( i=0; i<PlayerData::NUM_SPLASH_EMITTERS; i++ )
   {
      if( mSplashEmitter[i] )
      {
         mSplashEmitter[i]->deleteWhenEmpty();
         mSplashEmitter[i] = NULL;
      }
   }
}//yorks add
   
   mWorkingQueryBox.minExtents.set(-1e9f, -1e9f, -1e9f);
   mWorkingQueryBox.maxExtents.set(-1e9f, -1e9f, -1e9f);

   SAFE_DELETE( mPhysicsRep );		

   Parent::onRemove();
}

Now, if my memory works ... this was because particles mounted on a player didn't delete with the player.

Associate Steve Acaster
[YorkshireRifles.com]
#5
02/18/2010 (10:44 pm)
And whilst I'm finding bits of codefix to move over from 1.0.1 to 1.1b1 without being certain of whether they're needed ...

There is this Camera Fix by Ryan Mounts.

Associate Rene Damm
#6
02/20/2010 (7:51 pm)

The dStrrchr fix above definitely looks good to me.

However, the Player::onRemove should not amount to any functional change. Splash emitters are set only on ghosts so the previous code will simply amount to a NOP on the server object. Explicitly checking for isClientObject() will only shave a few cycles off the function call on the server.