Is PRIM_GLOW live in LSL

Unless I'm mistaken, Windlight is now standard in the SL client. (Feel free to correct me if I'm wrong.) So my question is did the option of PRIM_GLOW go active in LSL yet? I thought this would be useful in light scripts.

LSLEditor doesn't throw an error when the option is used in llSetPrimativeParams but lslint does. So making sure before I make use of it.

You could try to use it in your viewer and see if it compiles.

If it doesn't compile, just add this line to the top of the script...

integer PRIM_GLOW = 25;

I believe it is in the release candidate but not yet in the official stable viewer yet. And the release candidate now crashes every time on startup for me in Linux, so I hope they fix that before the RC goes to full release. The release version is the only way I can get in-world now (so no more pretty cloudscapes for me for the time being).

So llSetPrimativeParams should interpret the rest of the statement for the PRIM_GLOW if I add it as a variable? Such as they have the function in there, just not the global constant which in theory would keep people from using it.

Sure..

There's really nothing special about the newer versions of the viewer that have PRIM_GLOW built into their LSL compiling - they just know to replace any instances of "PRIM_GLOW" with "25".

Or you could just not type PRIM_GLOW at all and use 25 instead. It's really all the same thing in the end.

edit: look closely at the 2nd table at http://wiki.secondlife.com/wiki/LlSetPrimitiveParams and you'll see that PRIM_GLOW has a value of 25. You could also, for example, do...

llSetPrimitiveParams ([22, -1, 1]);

...which would change all sides of the prim to be planar. The 22 is PRIM_TEXGEN and the -1 is ALL_SIDES and the 1 is PRIM_TEXGEN_PLANAR. The PRIM_THIS and PRIM_THAT stuff is just a convenience for us, so we don't have to remember what the numbers are.

Not quite... setting PRIM_GLOW in a script will work for the moment, but as soon as the new client is released, and PRIM_GLOW becomes a constant, the script will break. It's better to use 25, or another variable, one that's not going to be turned into a constant in a few weeks, something like primGlow would be functional, and free from breaking the script in the future. Once PRIM_GLOW becomes a true constant, one can go back and change the primGlow's to PRIM_GLOW, and the scripts are good to go for good.


http://www.secondscripter.com

I respectfully disagree. If you define PRIM_GLOW for now, the compiler itself will tell you when it is time to change your code, and then you will only have to change (comment out) a single line of code at the top of your script, instead of every place you might use it.

Use an RC client, they leak memory less, they have the new features and crash less. I don't know why LL hasn't killed the 1.19 client and released a 1.20 client yet. None of the 1.19 bugs being reported are all that relevant to 1.20. They need to stop adding new features to the RCs and release what they have. Or at the very least do a 1.19 refresher with some of the new features. The PRIM_GLOW stuff is silly, PRIM_GLOW is here to stay. LL would be breaking content if they removed it or changed it now. It's too late for them to change it.

I still use 25, with a comment afterwards that // 25 = PRIM_GLOW

That means my code compiles now, will compile later, AND I can change it if I desire to do so. Adding "integer PRIM_GLOW = 25;" will compile now, but WON'T compile later. I don't like the idea of owning a script with a timebomb in it. Worse yet, having to go back and sift through my own code a year from now, to find out why it worked yesterday and now won't compile. Bleh.

Presently, the 1.19 client is more stable for me than the 1.20, the 1.20 RC is the only RC that has given me more problems than the main client.

I agree. Having this line at the top of the script...

integer PRIM_GLOW = 25; // delete/comment this line if you're using a 1.20+ viewer

...seems a lot better than having '25's all over the script or, worse, '25's all over the script with a comment at each one.




I haven't used 1.19 in ages. Once they got past the initial couple rounds of it (which were horrible for me) I've been pretty happy with it. Some of my Mac-based friends don't agree, though.

I feel for the mac crowd it's no fun when things don't work. I hadn't updated my video drivers for many months because of the problems with the newer drivers (because I didn't trust that LL had worked around them). Now with a newer video card I was forced to.