Game Development Community

Missing bug fix in 1.42 (solved)

by Duncan Gray · in Torque Game Engine · 10/12/2006 (12:45 am) · 9 replies

Refering to This TDN writeup about what has been fixed in TGE 1.42.

Regarding
Quote:
Sometimes the AudioDescription datablock would arrive after the AudioProfile on the client. Added a handler for this situation in onAdd()

I am experiencing this problem and did a diff on the cvs version and my current audiodatablock.cc but see no buf fix as mentioned.

Does anyone know what this fix looks like and can you post it here please.

#1
10/12/2006 (12:48 am)
Actually I would expect the fix to consist of ensuring that the server sends all the AudioDescription datablocks before sending the AudioProfile datablocks.... unless its a network packet delay issue.
#2
10/15/2006 (6:59 pm)
The fix can be found here in case anyone else needs it.

It's not in cvs yet so I assume there is another 1.42 release due sometime....
#3
10/16/2006 (8:09 am)
1.4.2 isn't officially released yet so is suppose there will be another update sometime
#4
10/16/2006 (8:25 am)
Duncan,

Does not that fix touch on something completely different? (Using audioDescriptions on clients rather than server?) I can not see how that fix will load descriptions before audioProfiles, unless I misunderstood your post.
#5
10/16/2006 (1:59 pm)
@Stephan, all datablocks are needed by the client and therefore have to be passed by the server so that the client can't cheat by modifying his vehicle datablock for more speed etc. The problem is that some datablocks are dependent on others being there first etc.

The solution was best described by Marcello
Quote:
The problem is that the audiodatablock is searching for the object in the unpack() function, but when unpacking the object may be not created yet, the correct way is to store the read Id and search for it only on onAdd() function.

It seems that the onAdd method is only called after all the datablocks have arrived and been unpacked so the idea of storing the datablock id when it arrives at the unpack point will eliminate any out of sequence problems at the onAdd point.

The solution is to move the Sim::findObject(id, mDescriptionObject); from the unpack to the onAdd method but you obviously need to store the id to do that.

I suspect there will be other situations within the engine where some datablocks are dependent on others being there ahead of them and if so, the above approach will solve that problem too.
#6
10/25/2006 (10:50 pm)
I just looked at the source code...the fix appears to be there...what specifically are you seeing missing?
#7
10/25/2006 (11:40 pm)
The audiodatablock.cc file I got from cvs has the following
bool AudioProfile::onAdd()
{
   if (!Parent::onAdd())
      return false;

   // if this is client side, make sure that description is as well
   if(mDescriptionObject)
   {  // client side dataBlock id's are not in the dataBlock id range
      if (getId() >= DataBlockObjectIdFirst && getId() <= DataBlockObjectIdLast)
      {
         SimObjectId pid = mDescriptionObject->getId();
         if (pid < DataBlockObjectIdFirst || pid > DataBlockObjectIdLast)
         {
            Con::errorf(ConsoleLogEntry::General,"AudioProfile: data dataBlock not networkable (use datablock to create).");
            return false;
         }
      }
   }

   if(mPreload && mFilename != NULL && alcGetCurrentContext())
   {
      mBuffer = AudioBuffer::find(mFilename);
      if(bool(mBuffer))
      {
         ALuint bufferId = mBuffer->getALBuffer();
      }
   }

   return(true);
}

The bug I had and the fix described higher up require changes similar to the following
bool AudioProfile::onAdd()
{
	if (!Parent::onAdd())
		return false;
	[b]
	   if(mDescriptionObjectID )
	   {
		   Sim::findObject(mDescriptionObjectID , mDescriptionObject);
	   }
	 [/b]  
	   // if this is client side, make sure that description is as well
	   if(mDescriptionObject)
	   {  
		   // client side dataBlock id's are not in the dataBlock id range
		   if (getId() >= DataBlockObjectIdFirst && getId() <= DataBlockObjectIdLast)
		   {
			   SimObjectId pid = mDescriptionObject->getId();
			   if (pid < DataBlockObjectIdFirst || pid > DataBlockObjectIdLast)
			   {
				   Con::errorf(ConsoleLogEntry::General,"AudioProfile: data dataBlock not networkable (use datablock to create).");
				   return false;
			   }
		   }
	   }
	   else
	   {
		   Con::errorf(ConsoleLogEntry::General,"AudioProfile: dataBlock DescriptionObject not present.");
		   return false;
	   }

   if(mPreload && mFilename != NULL && alcGetCurrentContext())
   {
      mBuffer = AudioBuffer::find(mFilename);
      if(bool(mBuffer))
      {
         ALuint bufferId = mBuffer->getALBuffer();
      }
   }

   return(true);
}

The point being that that Sim::findObject search was originally being done at the unpack stage which is what caused the bug if the datablock had not arrived yet.

I tried the cvs version and it did not fix the bug I had, the above did. ( need to 1st store the ID at the unpack point)

Sorry for sounding cranky but GG staff seem unresponsive to these bug reports and fixes that people provide and that tends to anoy people.

I'm still waiting on a response on that master server bug. Even emailing Mark Frohnmayer got no response.
#8
10/26/2006 (12:22 am)
You need to do a fresh CVS pull. I just checked and that bug has been fixed in HEAD for *months*:

bool AudioProfile::onAdd()
{
   if (!Parent::onAdd())
      return false;

[b]
   if (!mDescriptionObject && mDescriptionObjectID)
      Sim::findObject(mDescriptionObjectID , mDescriptionObject);
[/b]

   // if this is client side, make sure that description is as well
   if(mDescriptionObject)
   {  // client side dataBlock id's are not in the dataBlock id range
      if (getId() >= DataBlockObjectIdFirst && getId() <= DataBlockObjectIdLast)
      {
         SimObjectId pid = mDescriptionObject->getId();
         if (pid < DataBlockObjectIdFirst || pid > DataBlockObjectIdLast)
         {
            Con::errorf(ConsoleLogEntry::General,"AudioProfile: data dataBlock not networkable (use datablock to create).");
            return false;
         }
      }
   }

I personally fixed 200+ bugs for TGE 1.4.2 and a lot of them came directly from the bug reports/resolutions here on the forums. Just because we don't always have the time to personally reply to every single bug report doesn't mean we aren't paying attention. I glanced over your master server bug just yesterday and saved it into my bug database to review later when I have finished shipping Constructor.
#9
10/26/2006 (1:25 pm)
Matt, I did do a fresh cvs pull yesterday prior to making my post, and my post was based on what I got out of cvs. I am unable to check this morning (Australia time) because I can't connect. I think the server is too busy.