V1.9 Leaves You In The Dark

Wow! I'm no expert (or even beginner) scripter, but I know enough to see that the new lights in SL will leave you in the dark if you have a house that is scripted with lighting!

The street lights don't appear to work either...because they are scripted I suppose. I created a new object and made light with it though! Kewl! But it's like the electric company shut the whole world off...an SL BLACK OUT! and you have to use your lanterns! HAHAHA

Now I see a lot of products on SLBoutique that are scripted with lighting, especially houses. So I am wondering how all of you house makers who have prefabs are going to deal wit dat?

Funny I'd put a lightbulb on this message Title! lmao

This is pretty troubling -- stuff that was intentionally lit now needs to be manually re-lit. Moreover, there are no script-driven ways to manipulate the light features. Further and possibly most problematic, lighting needs to be set on a prim-by-prim basis. Which means properly re-lighting a complex link set will be exceptionally tedious, since each prim requires not only the checkbox set but its light color specified, as well as all the associated parameters set.

That really sucks.

In a perfect world, all the legacy light material prims would have their light feature checkbox enabled, their light color defaulted to the average color value of all their prim faces and the light parameters defaulted to a minimal but appreciable value. This perfect world would also make the light feature consistent with the rest of prim parameters by letting me set all of these values on several prims at once.

If that isn't done... damn, that's going to be a pain in my ass.

Because I sell ONLY scripted ligths, I expect I can close my shop.....
And then I will get all the questions about the lights I sold sofar (think in those two years i sold several 1000 lights). I can expect an IM overflow with the next version.

well think of it this way, in the dark you wont have to see all the "noodles" and limp prims

This was intentional and is a GOOD THING. Light was so insanely overused that I would often find my FPS dropping below 0.1 when I turned lighting on. I mean, you had people making wearable vodka bottles out of light! Lighting had become useless... and if you're one of the fraction of a percent of people in SL who had video cards fast enough for light to be usable for you AND with the sense to use it sparingly, I'm sorry... and for the remaining 99.9% of people using light EVERYWHERE and making it useless... I dance on your glowing graves.
Previous Linden comments indicate that this will be addressed before 1.9.1 release.
This isn't going to be a problem, because with almost everyone using hardware lighting ONLY and a hard limit of 6 hardware lights nobody is going to put more than a few light prims in a room.
In this perfect world, you would be buying me a new computer and video card so I could see your lights the way you want me to.

PS: You left off the "Pie" and "Thank God the Old Lighting is Dead" options.

You know everyone who ought lights from you. Get ready for a mass update drop session with new lights when the new API surfaces.

I've had to mass update one of my scripts already, when it got broken by updates. Surely anyone selling scripted objects has run into this once or twice?

You are just looking at the dark side.

This is a golden opportunity to *repeat* all those sales.
There is more than enough time to revamp all your products and have them ready for the new release.

It is NOT posible anymore to control lights with a script. llSetPrimitiveParms does not work anymore and there is no alternative in 1.9.1. It makes all scripted light useless.

You confuse between local lighting, a setting in your client, and the possibility to change the material type of a prim to light. Local lighting decreases your fps a lot, but not prims of type light. It is true that a lot of prims of type light decrease fps slightly (think there was some testing done more than a year ago, results were published in the forum).

I support the use of HW lighting in 1.9.1, but as long as everything is backward compatible. This means that scripts works like before.

Yet.
Well, you can't cash out Lindens from the preview grid , so unless they roll out 1.9.1 (which, given the state of the preview, won't be for a while) without some kind of controls for lighting it's too early to say that.

No, I'm not. If you don't have "local lighting" turned on in your client those prims with type "light" might as well be "wood".

Really.

Without local lighting there's no difference I can see (and I've looked, on multiple computers with different video cards) between setting a prim to light and setting its faces to full bright... so if that's all you want to do with your "light scripts" you should already have been using full bright instead. People using light instead of full bright to get full bright effects are why local lighting is useless in 1.8, and they're why Linden Labs is breaking the old light type, and I am so happy that they're finally fixing this.

Do I hear base 64 encryption all over again ?

How many times must LL hear it before they believe it -

YOU CANNOT TAKE OUT FUNCTIONALITY THAT IS BEING USED AND GIVE NO ALTERNATIVE.

Add a new function or increase the array in llSetPrimitiveParams

BUT KEEP THE OLD ONE THERE AND PHASE IT OUT


Oh well - feel better for that - not that it will do any good.


(Sits back and waits to view the riot that is going to ensue when 1.9.1 is released "as is" and LL start saying :
"Wah ? Wah ? What you mean ? We improved it didn't we ?" )

There's two alternatives.

1. For the people using light to get full-bright effects, GO BACK ONLINE NOW AND CHANGE ALL YOUR SCRIPTS TO USE FULL BRIGHT INSTEAD OF LIGHT. NOW! You're the people who are responsible for LL making such a drastic change to lighting.

2. For the few remaining people who are actually using scripted lights with restraint and discretion: I can't find the announcement now, but I'm pretty sure that when they announced the new lighting model they said that the new parameters would be scriptable by the time 1.9.1 was released.
They did. Many versions ago. It's called "full bright".
They did that. You weren't paying attention.

Did I miss it in the small print that THIS FUNCTION WILL NO LONGER WORK.

I mean they advertised that llSetexplosion and its ilk were going to be phased out for about a year ( they didnt switch it off over night )

( I would have preferred it to be full and bright so i noticed it )

So whats wrong with leaving it in then if they have already altered the structures to cope with the new stuff and putting something IN BIG FULL BRIGHT LIGHTS on the old stuff that this is facing redundancy and should no longer be used in new stuff.

And for your info all of my stuff uses fullbright as I never had the time or patience to sit around with local lighting switched on.

edit

Just to make sure - i just read the wiki entry on llSetPrimitiveParams - not one little iddy biddy mention of this part of the function is facing redundancy and will no longer be supported

Actaully Material Type Light can be a significant Lagger if there is enough of it used.

About a year ago our texture shop was all single box texture sets. Each box set to light (Full Bright did not exist then). This was on the order of 1500 boxes. Lag was a bear!

Put them all in vendors. We could move even with the vendors set to light (before full bright once more).

When they introduced "full bright" they said they intended it t be used to replace most use of "light" prims. If people had actually reduced their abuse of "light" prims when they did this, they probably wouldn't have nerfed light. They probably never intended to nerf light... they figured people would be smart enough to realise that "full bright" was a better tool. But if they introduced this new lighting without nerfing the old light, it would be so broken it wouldn't be worth doing because there's so much light-abuse you'd never notice the new lights among the glare from the old.

As for the Wiki... it's not authoritative. It's resident maintained and not updated by Linden Labs. It contains much information that is just plain wrong (I fix that when I find it, do you?).

Well I just pointed out an error on it to you

Best you pop over there and fix it eh ?

( I am not allowed to )

Or you could get off your 'the world owes me!' kick, spend the 5 whole seconds it takes to register, and edit it yourself when you first looked it up, considering you didn't have any problem with utilizing the resources of people that HAVE taken the time to put that information there in the first place. I suppose that might be too much to ask.

You should be allowed to - you just have to register an account on the wiki, a process that takes seconds - defining a user name is all.

And to comment on one of your earlier posts, although it's possible fullbright will be nerfed by the update that's not the announced intended behaviour. The announced behaviour is everything currently set to light will turn to fullbright rather than try to interpolate a light setting for it. If your lights are all fullbright then by release time you should see no difference.

Any existing "Light' object becomes a Full Bright object. To get a new Light object, you have to use the new UI in 1.9.1.

The question is whether the script calls for changing lighting will be re-enabled, or whether there will be new ones. If the scripting calls are changed to activate the new effect, it will at least allow existing scripts to work.

I'll admit that I never saw the effect of pre-1.9.1 lighting; all of my video cards are too slow for it to work acceptably, so I have not been able to turn it on. (When you turn it on and your frame rate drops to 0.1fps, you turn it off in a hurry!) The new lighting in 1.9.1 actually works quite well on my systems; not much effect on the frame rate. So the Lindens giveth as they taketh away; you might have to redesign your lighting items, but the potential market for them will expand considerably. (I doubt that more than 5% of residents have Local Lighting turned on currently, because it's such a performance killer.)

The reason llSetPrimitiveParams hasn't been updated for 1.9.1 is because 1.9.1 IS STILL IN PREVIEW. Duh. If, upon 1.9.1's PUBLIC release, and there is no "light" parameter, THEN it will make sense to update the function.

Can you control these newfangled-to-be lights with a script that controls an object that moves in front of them, or an object that encloses them and gets turned from clear to opaque?

Huh? Non-light, or even lit, prims/objects can still be scripted to move and/or change alpha. The actual "light" command just can't be scripted (yet).

My idea - question, really - is for a kludgy workaround. To make a light effectively be "on or off" by covering it up.