Strange SetAlpha behaviour

I am in the finishing stages of debugging my game and a strange behaviour has been seen.
The board has space for 121 prims to be rezzed over it for playing, 10 per player. Each prim (like a puck) has to be set to a different color RYGCBM and also to a different Alpha either 1.0 stable colored condition or 0.5 to represent the possible moves for the player to select. When a new piece is rezzed it will be created and then set to the 0.5 Alpha condition.

The problem I am getting is that when the prim is rezzed near the centre of the table it will not display the 0.5 alpha condition, it seems to go alpha 0.0. The prim is still there, I have checking methods which prove it has accepted the llSetAlpha command. It just will not display correctly.

I need some help and advice as to what to do next? Report it as a bug or what?

Could be a logic error. For debuggin, try hard-coding the .5 alpha value (and put a delay of 5 seconds right after it) when the object is rezzed. This will at least help insure 1) there is no problem with a value being passed in a variable, and 2) there is no problem with something else turning it back to 0.0 immediately after rez.

Thanks for the thought I will check that out, especially the delay action.

Also could have to do with known alpha ordering issues. Ie if you put one alpha texture behind another, all hell breaks loose. I'm not aware of a workaround but you'll notice it a lot when people with prim clothing walk over a partially alpha floor for example.

Thank for the input. I do not have any textures on the prim.
I have checked that the prim which "disappears" is still rezzed but just not visible.
I am still stumped what to do next I have invested more than 5 months developing this game and am loathe to just abandon it.

could it just be a glitch in the script? So you are able to do something like this:

float alpha = 0.5;
llSay(0, "Alpha: "+ (string)alpha);
llSetAlpha(alpha, ALL_SIDES);

and it registers you said 0.5?

Is it possible there is a second script at work overriding that with a 0 due to a logic flaw or something, part of the game logic perhaps?

Maybe attack the mysterious disappearing prim in the editor. Contol-Alt-T to show transparent (I realize that's probably how we already know for sure the prim is rezzed), select it with Edit linked parts, and see if Transparency is 50. Even though its not supposed to have a texture, as long as it's in the editor anyway, Control-Alt-Shift-T while selected to see whether the texture is indeed opaque. If Transparency is 100, then somewhere in some script llSetAlpha(), llSetLinkAlpha(), llSetPrimitiveParams(), or llSetLinkPrimitiveParams() must be getting called with an uninitialized variable as the value to alpha... or the prim being rezzed is starting out full-alpha and never getting changed. Or there's some horrendous bug.

I hope it is not a glitch but would welcome a review. A section of the rezzing script follows:

    listen(integer channel, string name, key id, string message)
    {
    	if(channel == CHANNEL1001)
    	{
    		if(llGetSubString(message,0,2) == "Add")
        	{
        	    Pos = llGetPos();
        	    integer itemp1 = (integer)llGetSubString(message,3,5);
    	        integer itemp2 = itemp1 + 3000;
        	    if (itemp1 >= 2 && itemp1 <= 61)
        	    {
        	        vector vtemp = llList2Vector(PC2_61,itemp1 - 2);
        	        llRezObject("Piece",(Pos + vtemp),ZERO_VECTOR,ZERO_ROTATION,itemp2);
        	        llSetScriptState(llGetScriptName(),FALSE);
        	        llWhisper(CHANNEL2206,"Restart");
        	        llWhisper(CHANNEL2209,"Continue");
        	    }else	// end of 2 - 61 block
        	    if (itemp1 >= 62 && itemp1 <= 122)
        	    {
        	        vector vtemp = llList2Vector(PC62_122,itemp1 - 62);
        	        llRezObject("Piece",(Pos + vtemp),ZERO_VECTOR,ZERO_ROTATION,itemp2);
        	        llSetScriptState(llGetScriptName(),FALSE);
        	        llWhisper(CHANNEL2206,"Restart");
        	        llWhisper(CHANNEL2209,"Continue");
        	    }else	// end of 62 - 122 block
        	    llOwnerSay("Add number less than 2 or greater than 122");
        	}	// end of Add blocks
        }else	// end of CHANNEL1001 block
        if(channel == CHANNEL9001)
        {
	        if(message == "Where")
	        {
	            llOwnerSay("at: " + (string)llGetPos());
	            llOwnerSay("RootPos: " + (string)llGetRootPosition());
	        }else	// end of Where block
	        if(message == "Memory")
	        {
	            llOwnerSay("Memory: " + (string)llGetFreeMemory());
	        }		// end of Memory block
	    }	// end of CHANNEL9001 blocks
    }	// end of listen event handler

PC2_61 and PC62_122 are lists of vectors to position the prims on the board. The script contained in the prim being rezzed:

// Global Constants
integer CHANNEL2109 = 2109;        // Notify channel Output
integer CHANNEL8002 = 8002;         // Command channel
// Global Variables
integer Strt_Parm;                // Local copy of start_param
integer Flashing;                // Control for flashing
string Status;                    // Status: Col, Dim, Fls or Mpt
string Color;                    // Color: Red, Yel, Grn, Cyn, Blu or Mag
// Functions
string LPADS(string src)
{
    return llGetSubString("000" + src, -3, -1);
}

// States
default
{
    state_entry()
    {
        llListen(CHANNEL8002,"",NULL_KEY,"");
    }
    
    on_rez(integer start_param)
    {
        Strt_Parm = start_param;
        llListen(Strt_Parm,"",NULL_KEY,"");
        llListen(CHANNEL8002,"",NULL_KEY,"");
    }    // end of on_rez event handler
    
    touch_start(integer total_number)
    {
        llWhisper(CHANNEL2109,"Tch" + LPADS((string)(Strt_Parm - 3000)) + (string)llDetectedKey(0));
    }    // end of touch_start event handler
    
    listen(integer channel, string name, key id, string message)
    {
        if (channel == Strt_Parm && llGetSubString(message,0,2) == "Fls")
        {
            Status = "Fls";
            llSetTimerEvent(0.5);
        }else    // end of Flashing block
        if (channel == Strt_Parm && llGetSubString(message,0,2) == "Dim")
        {
            llSetTimerEvent(0.0);
            llSetAlpha(1.0,ALL_SIDES);
            Status = "Dim";
            if (llGetSubString(message,3,5) == "Red")
            {
                llSetColor(<1,0,0>,ALL_SIDES);
                llSetAlpha(0.5,ALL_SIDES);
                Color = "Red";
            }else
            if (llGetSubString(message,3,5) == "Yel")
            {
                llSetColor(<1,1,0>,ALL_SIDES);
                llSetAlpha(0.5,ALL_SIDES);
                Color = "Yel";
            }else
            if (llGetSubString(message,3,5) == "Grn")
            {
                llSetColor(<0,1,0>,ALL_SIDES);
                llSetAlpha(0.5,ALL_SIDES);
                Color = "Grn";
            }else
            if (llGetSubString(message,3,5) == "Cyn")
            {
                llSetColor(<0,1,1>,ALL_SIDES);
                llSetAlpha(0.5,ALL_SIDES);
                Color = "Cyn";
            }else
            if (llGetSubString(message,3,5) == "Blu")
            {
                llSetColor(<0,0,1>,ALL_SIDES);
                llSetAlpha(0.5,ALL_SIDES);
                Color = "Blu";
            }else
            if (llGetSubString(message,3,5) == "Mag")
            {
                llSetColor(<1,0,1>,ALL_SIDES);
                llSetAlpha(0.5,ALL_SIDES);
                Color = "Mag";
            }
        }else    // end of Dimmed block
        if (channel == Strt_Parm && llGetSubString(message,0,2) == "Col")
        {
            llSetAlpha(1.0,ALL_SIDES);
            Status = "Col";
            llSetTimerEvent(0.0);
        }else    // end of Colored block        
        if (channel == Strt_Parm && message == "Mpt")
        {
            Status = "";
            Color = "";
            llDie();
        }else    // end of Empty block
        if (channel == Strt_Parm && message == "FlashOF")
        {
            llSetTimerEvent(0.0);
            llSetAlpha(1.0,ALL_SIDES);
            Status = "Col";
        }else    // end of FlashOf command block
        if (channel == CHANNEL8002 && message == "Who")
        {
            llOwnerSay("I am in Status: " + Status + " and Colored: " + Color);
            llOwnerSay("Strt_Parm: " + (string)Strt_Parm);
            llOwnerSay("Prim Params: " + llDumpList2String(llGetPrimitiveParams([PRIM_COLOR, 0]),","));
            llOwnerSay("Prim Alpha : " + (string)llGetAlpha(0));
            llOwnerSay("Prim Color : " + (string)llGetColor(0));
        }        // end of Who command block
    }    // end of Listen event handler
    
    timer()
    {
        if (Flashing == 0)
        {
            llSetAlpha(0.0,ALL_SIDES);
            Flashing = 1;
        }else
        {
            llSetAlpha(1.0,ALL_SIDES);
            Flashing = 0;
        }
    }    // end of timer event handler
}    // end of default state

The rezzed prim responds to a different channel for each different prim in the range 3002 - 3122 and also to a command channel 8002 to obtain the confirmation you seek.
This confirms the prim is stillthere by responding and giving its Alpha and Color. When prims near the outer part of the board are rezzed and checked they correctly appear and respond when prims nearer the centre are rezzed they very briefly appear then disppear.
They still respond as if they were there and correctly colored.

Yes it correctly displays the texture transparency as 50 or Alpha 0.5.
What is so puzzling is the effect of being nearer the centre of the circular board seems to cause the Alpha setting to fail to display.
As for an overriding script effect it would, I suggest, be the same for all the rezzed prims but it is not.

Could the timer be going off unexpectedly? How about putting some SAY messages in the timer event to check, since it looks like that could cause unexpected alpha settings if it does (or if the "Flashing" variable is wrong...)

I think you may have struck it right. I had assumed that setting the timer off would cancel the timer events but there may still be one queued. I will investigate doing the timer llOwnerSay as you suggest and see if it changes the behaviour. Thanks

I have tested the script with changed timer event llOwnerSay added. It still fails without trigerring the event timer.

If the invisible prim is moved in the editor away from the center of the board, does it magically appear? If the editor shows an opaque texture as having a 0.5 alpha, it doesn't sound like it's the script that's making it invisible. I'm thinking Shadow may have hit it right on the first reply, and that it's an alpha-sorting artifact.

Or maybe something else glitchy, is the board built on top of a 20x20.0.5 huge prim by chance? The 'hacked' huge prim types have all sorts of wierd behaviors when it comes to rezzing objects, mostly not allowing them to rez, but I have rezzed objects I dropped on a huge prim and had them show up way beneath it in the past. Could it be below ground?

Just on the off chance that something distance related is going on, you could try changing your llWhisper to llRegionSay? (whisper has a range of 10m I think).

Maybe thats irrelevant if your gameboard is small.

I have discovered that the prim although located at the same position in-world is displayed below the board top surface. The top surface of the board has a texture to represent the positions for the pieces. If I remove the texture and rez the prim it appears correctly positioned. If I then change it's Alpha it displays correctly.

The cause of the problem is indeed Alpha sorting, whatever that is.

What do I do to fix the problem?

Incidentally from different view points the dimmed piece appears always further away from the viewer. I am a novice at 3D graphics so have no ideas how to remedy the effect.
The texture applied to the surface of the board could be the cause. Should I recreate it without any Alpha channel in it? or am I barking up the wrong tree?

See above for possible solution as yet unsolved. The board is circular about 2.5 metres in diameter 0.5 metres thick.

(paste handy reference URL for alpha-sorting here--if only I could find it)
Yes, it will help to make the game-board texture be "opaque"--without an alpha channel.

It's my understanding that all OpenGL programs--indeed, all real-time 3D graphics programs--suffer to some extent from this "alpha-sorting" problem, due to the computational complexity of getting layers of transparency properly overlaid in the rendered image. SL has the problem very noticeably, especially when two textures with alpha channels overlap, and to a lesser extent when opaque textures with applied transparency overlap with an alpha-channel texture (and I *think*, to an even lesser extent, when two surfaces with applied transparency overlap each other). Sometimes the surfaces can be very distant from each other and at quite different orientations, yet the artifact persists for some viewing angles.

To solve the problem, make your game board non-transparent. Meaning Transparency set to 0 AND use a texture without any Alpha channel.

Thanks for the thought. I will need to try a number of options to see which is best.
1. Change the newly rezzed pieces to be Alpha 1.0 White and then change the color to the player's color when selected for final placement.
2. Try the approach you suggest.
3. Think of more solutions.

I dont want to use option 1 as it sort of destroys the game flow a little.

+1

If the board is partially transparent and the newly rezzed piece is too, you will suffer from this issue when viewing them in such away that the transparent bits of one are behind those of the other.
So
1. removing transparent bits from the game board itself
or
2. from the newly rezzed pieces.

This is presuming that there aren't many newly rezzed pieces side-by-side in such a way that they will interfere with eachother as well.

I see this all the time at my skybox, I have a transparent (metal grate) floor and any time I put anything alpha near it things go whacko-bananas.

Your experiences must be horrible. I have rechecked the texture I used and it can be used without any Alpha channel content. To be on the safe side I am going to adopt option 1, rezzing a White prim and when selected as the piece to play by the player turn it to their color. All of which will get me back to finishing evrything. Until I come across the next 'Gotcha'.

For what it's worth, but I'd wager that there wouldn't be a problem with the gamepieces interacting with each other when llSetAlpha() is applied. No idea why but I've found it much harder to trigger the alpha-sorting artifacts when non-alpha-channel textures overlap even if they've had transparency applied to them, compared to when one--or worse, both--of the overlapping textures themselves contain an alpha channel.

Problem has been solved by removing the Alpha from the texture on the top of the game board. The pieces have no textures and are only set Alpha = 0.5 for a short time and are either deleted or changed to Alpha 1.0 at the end of a move.
Thanks for the help.

memo to self read up about Alpha channel generation.