Game Development Community

ShapeBase setImage Implementation Question

by William Todd Scott · in Torque Game Engine · 01/10/2006 (7:36 am) · 0 replies

Hi all,

I have three questions on the implementation of ShapeBaseImageData and related functions in the ShapeBase class.


First:
If setImage is called for an image slot that is in a state that does not allow an image change then the following variables are set and the image change is buffered for later:

nextImage
nextSkinNameHandle
nextLoaded

On the next update if the image is in a state that will allow an image change, then another call is made to setImage() with the variables listed above as parameters.

My question is why aren't there nextAmmo, nextTriggerDown, and nextTarget variables as well? If a call is made to setImage() with ammo, triggerDown, or target as parameters but the image change needs to be buffered then we will lose the values in these parameters.

edit: Another way to think about this is, why does mountImage() have a parameter for the "loaded" variable, but not for "ammo"?

Second:
As the following code snippet from setImage() illustrates, if the image is in a state that does not allow an image change, then the change will be buffered only if we are on the server. The client will continue on and change the image despite the fact that the image state indicates such changes shouldn't be allowed. In the snipped below, shouldn't we remove the check for whether or not we are on the server?

// Check to see if we need to delay image changes until state change.
   if (!isGhost()) 
   {
      if (imageData && image.dataBlock && !image.state->allowImageChange) 
      {
         image.nextImage = imageData;
         image.nextSkinNameHandle = skinNameHandle;
         image.nextLoaded = loaded;
         return;
      }
   }


Third
In the ShapeBaseImageData class there is a data member "ProjectileData* projectile" that is only referenced in C++ to 1) check it exists when the datablock is downloaded to the client and 2) pack and unpack it for transmission. Given that the projectile is only used in the script call of the firing state, it seems like this is an unnecessary data member. In the crossbow.cs example there is a "ProjectileType" dynamic field added to the image datablock that is used only in the firing script and it is not part of the C++ class, so it seems like "projectile" should be treated the same way.



Thanks
Todd