Kitely Forums

paste the following code into a script in a prim that has zero transparency. Note that in code, zero transparency or alpha is supposed to have the value 1.00. If you APPLY an alpha of 0.000 to a face or prim, it will make it 100% transparent. 1.00 is fully opaque. Thus a prim that is fully opaque should return the value 1.00 with the following code:
Instead it returns a value of 0.0000, which is WRONG.

It appears that this function is returning a value of zero no matter what the actual alpha is.

Hi Mike,

Have you checked if there is an existing Mantis bug report for this problem? (there are quite a few bug reports about various problems with llGetLinkPrimitiveParams)

See: http://opensimulator.org/mantis/view_all_bug_page.php

Ilan Tochner wrote:Hi Mike,

Have you checked if there is an existing Mantis bug report for this problem? (there are quite a few bug reports about various problems with llGetLinkPrimitiveParams)

See: http://opensimulator.org/mantis/view_all_bug_page.php

There appears to be a mantis about the entire category of llGet/Set for primitive parameters thats two years old.
http://opensimulator.org/mantis/view.php?id=6824

It would help if other scripters commented there asking for this to be resolved.

I guess I need to go to an os dev meeting and raise a ruckus.

PRIM_ALPHA_MODE is not how I read the transparency of a prim, I use PRIM_COLOR and then alpha is the second item in the returned list. the good news is that I have been reading and writing the alpha values in lots of scripts this way and it works fine.

This is an example of "clumping" in the arguments of the LSL Params functions. You are not allowed to get or set color unless you also get or set alpha at the same time. I've had to do a read/modify/write cycle sometimes to change just one of them. In some cases you can't do a read because of permission issues, so you can't even do a read/modify write of the rest of the arguments. For example, you are not allowed to read the UUID of a texture map if the perms are restrictive. So PRIM_TEXTURE cannot change just the offset without changing everything else. And you cannot use llOffsetTexture() to change the offset by itself because it has a forced delay. And you cannot call any functions in OpenSim that have a forced delay because that locks up one of the threads for the Xengine. At some point OpenSim "fixed" that problem by recovering from using the name of a texture that is not in inventory. You can't use NULL_KEY because that will change the texture to the default one. So I change the texture to "dumy" and make sure I don't have a texture in the prim inventory with that name. When llSetLinkPrimitiveParamsFast cannot find that texture map, it leaves the texture map the way it is and moves on to the next argument in the list.

I don't even know what PRIM_ALPHA_MODE is returning, it returns two integers! An alpha_mode and a mask_cuttof, whatever those are.

Kayaker Magic wrote:
I don't even know what PRIM_ALPHA_MODE is returning, it returns two integers! An alpha_mode and a mask_cuttof, whatever those are.

alpha_mode is supposed to give you a 0 or 1 to indicate whether it is on or off. Mask-cutoff is supposed to tell you what the alpha transparency value is, but in Opensim it returns a null value all the time. if MASK_CUTOFF is something else, I haven't been able to find any documentation that contradicts my understanding of it.

PRIM_ALPHA_MODE is not a prim transparency. I guess this is an alpha mode:


First picture on the left - Alpha Mode, values None, Alpha blending, Alpha masking, Emissive mask.


If you want to change prim or object transparency, use llSetAlpha or llSetLinkAlpha, works for me in OpenSim.

Zuza Ritt wrote:PRIM_ALPHA_MODE is not a prim transparency. I guess this is an alpha mode:


First picture on the left - Alpha Mode, values None, Alpha blending, Alpha masking, Emissive mask.


If you want to change prim or object transparency, use llSetAlpha or llSetLinkAlpha, works for me in OpenSim.

a) an alpha mode is any transparency applied.
b) those are different modes of alpha transparency.
c) the problem is not about setting the alpha, it is getting the current value of the alpha accurately. the OP was about llGetAlpha.

Bumpiness is not alpha, it is a normal.
Shininess is not an alpha either, its a specular or caustic.
Emissive is not an alpha, it is full bright or a light source.

Kayaker is right; To get the transparency of a face, use PRIM_COLOR: What you tried to do is get the alpha mask cutoff point of a texture set to mode PRIM_ALPHA_MODE_MASK: PRIM_ALPHA_MODE. The returned mask_cutoff is an integer (!) and can range from 0..255 (see wiki). It defines the cutoff point on the texture where the 1-bit (!) alpha kicks in. The default alpha mode on newly textured faces (with 32-bit/alpha textures) is 'Alpha blending', and probably the reason why you got 0 returned as mask_cutoff is undefined with PRIM_ALPHA_MODE_BLEND.

Off-topic builder tip: Setting alpha mode to 'Alpha masking' instead can tremendously improve viewer side performance, it is just less pretty because it's 1-bit (on/off) so no pretty anti aliasing on the edges. Play with the cutoff point to see what looks nice; I suggest start with 128, and only if it fails to look good revert to alpha blending.