Transparency Issues

I have a multi-prim HUD I'm trying to create. There's the front of the HUD that has a bunch of buttons on it that you can click and then a rectangle flat prim behind that one that should be hidden until a user clicks a button on the HUD. When a button is clicked the rectangle prim in the back moves to the left and it gives the illusion that the rectangle appeared from inside the HUD. The problem is that the rectangle prim located behind the main HUD is always visible even though the other prims are CLEARLY located in front of it, all of the buttons are still clickable but I can't see them. Is there anyway to resolve this issue?

Sounds like an alpha sorting issue. Whenever you overlap two or more 32-bit-textured surfaces in 3D space, the renderer will have trouble determining which one to draw in front of the other. This is true in just about every 3D engine in existence, including the one SL uses.

I'd suggest you redesign your HUD to use a different method of hiding/exposing buttons. Trying to hide one partially transparent image by putting another in front of it is never a good idea. How about simply toggling visibility instead of overlapping?

Toggling visibility, as Chosen suggests, is a good approach. You can do it by writing your HUD script so that it flips from one texture to another as you activate it, something like this ....

integer ON;
default
{

state_entry()
{
     llSetTexture("Texture 1",1); //This is your "deactivated look" texture
     ON = FALSE;
}

touch_start(integer num)
{
     ON = !ON
     if (ON)
     {
          llSetTexture("Texture 2",1); //This is your "activated look" texture
          // Then do all the things that make the HUD work
     }
     else
     {
          llSetTexture("Texture 1",1); //Here's where to turn it off again
          //And do whatever you do to deactivate your HUD
     }
}
}

In order to minimize rez time as you switch from one texture to the other, I'd suggest putting both textures on the sides of your HUD object (the faces that you never see when it's on the screen). That will fool your graphics card into rendering the textures before you actually toggle them onto the visible face.

Instead of flipping between images, how about simply toggling between 0 and 1 for the alpha value? The texture stays the same, so there's no re-rezzing. Only its apparent visibility changes.

Hmmm... Thanks, Chosen. As I go back and look at the OP's post, it looks like I was envisioning a somewhat different physical setup. I skimmed past the part about moving the rectangle to the left to make it visible. Assuming that the device is already scripted to do that sliding bit ... then yes, simply toggling from llSetAlpha(0.0,1) to llSetAlpha(1.0,1) is the easier route, although that won't make the rectangle look like it's emerging smoothly from behind the button panel. Unless I'm still not understanding thing correctly (a real possibility), the only way I can imagine to create the illusion of smooth emergence is to script llSetAlpha to change gradually as the rectangle slides out -- not simply toggling from totally transparent to totally visible. I don't imagine it would be tough to do, depending on how the OP's script is written.

What I was envisioning was a different setup in which the rectangle replaces the texture with the buttons. You could do that, for example, if you want to use the same scripted button locations for different functions. You just rotate a texture with new button labels onto the visible face of the HUD as you branch to a new section of the script that uses them.

Obviously, any scripted solution assumes that the OP has mod permission on the script itself and can make the appropriate changes.

Here's another option, which could accomodate the scrolling. It could be a 2-frame texture, set to animate into place on command. One half of the texture would be fully transparent, and the other would have the button image on it. By default, the transparent half would be the only part showing. Then when the button is needed, the texture would scroll over to the other half, to expose the button.

Ooooo .... I like that. You really could do that smoothly.