TSShape::computeBounds bug

I've looked on the forums and it appears that the consensus is that you can't have a vehicle that has multiple meshes (not sure if I'm using the correct terminology).

Well, stupid me, I created a vehicle with multiple meshes and, like is probably well know, the game crashes.

But, maybe there's a quick fix and possibly a real fix.

TSShape::computeBounds (tsShape.cpp line 500 or so) has this block of code:

// run through objects and updating bounds as we go
   bounds.min.set( 10E30f, 10E30f, 10E30f);
   bounds.max.set(-10E30f,-10E30f,-10E30f);
   Box3F box;
   start = subShapeFirstObject[ss];
   end   = subShapeNumObjects[ss] + start;
   for (i=start; i<end; i++)
   {
      const Object * object = &objects[i];
      TSMesh * mesh = od<object->numMeshes ? meshes[object->startMeshIndex+od] : NULL;
      if (mesh)
      {
         static MatrixF idMat(true);
         if (object->nodeIndex < 0)
            mesh->computeBounds(idMat,box);
         else
            mesh->computeBounds(gTempNodeTransforms[object->nodeIndex-start],box);
         bounds.min.setMin(box.min);
         bounds.max.setMax(box.max);
      }
   }

The problem is that if you have multiple nodes in a vehicle, object->nodeIndex is zero for each one, yet start is non-zero. In my mesh, for some reason (I didn't follow the code to figure out why) start is 7, end is 8, and the offending line attempts to access a negative element of an array (object->nodeIndex - start = -7):

mesh->computeBounds(gTempNodeTransforms[object->nodeIndex-start],box);

A quick hack might be:

if (object->nodeIndex < 0 [b]|| object->nodeIndex < start[/b])
            mesh->computeBounds(idMat,box);
         else
            mesh->computeBounds(gTempNodeTransforms[object->nodeIndex-start],box);

but I'm unsure if this would be the appropriate fix.

Maybe the object->nodeIndex is being initialized incorrectly and instead of all of them being "0" maybe they should have another value, making it so the offending line of code no longer computes a negative element index.

I'm sure this bug exists in TGE as well as TSE... or, possibly, it's not a bug and my model is just incorrect. I can e-mail you my model (it's a relatively small Blender model, about 1000 polygons) if you need.