using script to control glow?

hi

is there a line that will turn glow on off? I have an item that uses glow but i need it to show/hide and even though i set to alpha for hide i believe because texture is blank (white) glow is still working off of this.

if i stick a alpha texture on the object glow stops( which is why i think its working off the whiteness of the texture option being blank.)

So is there a line of code that will make glow on/off?

thanks!

EDIT: Sorry I found a post that has a fix for this

/54/42/223524/1.html

// Studio Dora Lamp script, Dora Gustafson d.2008-01-27
// v1.2 'Glow' replaces 'Full bright'
// 'Glow' introduced in 'WindLight' viewer: 1.19.2

// touch prim toggles prims point light on and off
// toggles fullbright as well, it looks more convincing

vector colour = < 1.0, 0.5, 0.0 >; //orange light (R,G,B)
float intensity = 1.0;
float radius = 5.0;
float falloff = 0.75;
float glow = 0.5; // [0.0; 1.0]

integer PRIM_GLOW = 25;

integer on_off;

default
{
    touch_start(integer total_number)
    {
        on_off = !on_off;
        llSetPrimitiveParams( [ PRIM_POINT_LIGHT, on_off, colour, intensity, radius, falloff, PRIM_GLOW, ALL_SIDES, glow * on_off ] );
    }
}

anybody! use this and stop please, repeeting this question

happy scripting

thank you Dora

although it didnt toggle fullbright as well i guess you forget to add it

llSetPrimitiveParams( [ PRIM_POINT_LIGHT, on_off, colour, intensity, radius, falloff, PRIM_GLOW, ALL_SIDES, glow * on_off, PRIM_FULLBRIGHT, ALL_SIDES, on_off] );

What happens if you declare an integer variable PRIM_GLOW in your script, and then Linden Lab makes that a constant later on? Will the script break, or just accept the override?

PRIM_GLOW is a constant in the newest viewer (The RC at least)

llSetPrimitiveParams([PRIM_GLOW, ALL_SIDES, 1.0 - glow]);


(Taken from the blog here: http://blog.secondlife.com/2008/04/09/updated-new-release-candidate-viewer-120-rc0-available/#more-1858)

I've thought the same thing, and I keep seeing everyone post 'integer PRIM_GLOW = 25;' all over the place. The proper thing to do is to set something similar, but not what LL will obviously use down the road.

integer primGlow = 25;

is much smarter to use. When those scripts compile on the newer viewers, the scripts will break. Personally, I've been coding using primGlow rather than PRIM_GLOW. If you attempt to set a constant to any value, even the value it's set to, it will generate a script error when the script goes to compile. Using primGlow instead of PRIM_GLOW will still work once PRIM_GLOW is made into a constant, and your scripts wont break (and piss off your customers if you sell them as such). Saves having a bunch of customers banging down your door with broken scripts in hand.

personally, I just put "25" in the actual statement, with a comment that says // 25 is a standin for "PRIM-GLOW"

Actually, I PREFER that the same identifier is used, and will break when the constant gets implemented. It indicates we are relying even less on the numerical value of the constant, which is the right thing to do for maintainability. Once the constant is implemented and we get a compiler error, we know immediately to fix it and start using the correct symbol. This is one of the right ways to use a compiler IMO.

Well, I suppose, if you're not writing scripts for sale, and don't mind fixing your broken scripts. But in the real world of programming, it's typical to code your scripts such that they will not break. As a scripter in SL, you'll know when PRIM_GLOW is implemented by reading the forums, blog, etc. I suppose if you want your scripts to break, it's your prerogative, but I just feel it's silly to define a variable that you know ultimately will be defined as a constant, and therefore, cause an error down the road.

Maintainability??? Huh??? What's the point, once a script is written, it's written. If you define a variable as primGlow, and use that, what's not maintainable about that? What's up with 'It indicates we are relying even less on the numerical value of the constant' ??? The numerical value of the constant is ENTIRELY what we're relying on to make the script function. Constants are simply in place so you dont have to remember the values. Defining a variable is the best thing to do. It allows for easy readability, and it will continue to function just as well once the constant is defined. If you define a function, and LL ultimate incorporates that same function into the Linden Library, are you going to go back and pull out your function from all your programs and modify your code to use the new LL one? Of course not. So why bother setting up your scripts to break. Just doesnt make any sense.

This makes sense to me, and, until the constant is properly implemented, I'll start using this technique on any new script I write using glow. I also intend updating existing scripts as and when I have a need to tweek or otherwise change them, or any which are likely to end up in commercial products.

A simple 'Edit | Replace' is all it takes in the LSL Editor; less than 15 seconds work per script but with the potential of saving many hours in the future in time-consuming debugging, customer compliants and other such things.

We should never rely directly on the value of symbolic constants in the LSL library if we can help it. That violates encapsulation and depends on an implementation detail. With some languages/platforms, the compiler may not even use a fixed value and may instead allow it to be done during linking/runtime/JIT compiling, and SL/LSL is even growing measurably in the direction of this type of environment as we speak. What is maintainable is that by using a name that will purposefully conflict with the planned official constant, you are directly on the road to using that official constant as soon as it is available. It certainly may be a good idea to throw a clear comment in there if you plan to give the source code to anyone you don't think will understand the issue, but it IS only going to apply to those who are recompiling it.

In the "real world of" software engineering, this kind of thing is done all the time when planning code merges. Wherever the compiler can help you with the tasks that would otherwise be left up to human memory and thoroughness, it is invaluable. Coding it purposefully to break in a predicable way is better than running into a sloppy runtime issue somewhere down the line (due to, say, a constant that has changed value). Better for/of us to program defensively than to plan on being mules about backwards compatibility (e.g. "If LL ever gives us a symbolic constant, darn it, they'd better not change the value, EVER!".

Ok, point taken, if the value changed, the script would break, an by using PRIM_GLOW as a globally defined variable would be easy enough to fix one PRIM_GLOW joins the ranks of constants, as simply removing the declaration would fix the program. Still, my money is on PRIM_GLOW retaining it's value for a while. Typically, revisions usually try to keep as much as possible the same, and I'm betting the glow constant will remain 25 for some time, if not forever, still, I see your point.