Hey, leave my vector alone!

Is there a way to have a light script respect the colour vector set by anyone using the normal light-color setting on the Features pane of the Edit panel? So that a user could set their own light colour for a prim, using the Features/ Light Color control, and then switch the light on and off (using scripts) and the script would NOT override the user-set light-colour setting?

In other words can I disable, ignore or somehow re-route the colour vector in the standard light command, llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <1,1,1>, 1.0, 20.0, 1.0]) ?

Is that possible?

Have the vector user definable in the script. Have it ask for it, and then listen, and store the said value.

And then use that value in the llSetPrimitiveParams() line.


So like...

vector colour;
default
{
        state_entry()
                    {
                          llListen(11, "", llGetOwner(), "");
                     }
         listen(integer channel, string name, key id, string message)
                     {
                           colour = (vector)message;
                      }
          touch_start(integer number)
                      {
                                 llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, colour, 1.0, 20.0, 1.0]);
                       }
}

Or something. Note that this script was written off the top of my head in the forums. it may or may not work in world as is, and is just to demonstrate method.

What it's supposed to do is be able to store a vector said on channel 11, and when touched turn on a light of that colour. If you say a new vector, then touch it, it will change to that coloured light, not turn off.

Message example t set colour: /11 <0,0,1> for blue.

ETA:: Tested and appears to work exactly as written.

Yes the method that Keira described is more user friendly But there is a way to make it like u wanted. Maybe it would be a bit laggier but i dont think it would be noticable if u do it right. Include a timer event that will check the color of the point light every few seconds (5 second shouldnt make lag) and if it is different from the one before change it to current. All u need is one variable for color. Then in timer get color with llGetPrimitiveParams and compare it with the last saved vector of color. If it is different make it change to this current vector.

This should do what you asked. There is a failure mode, the old color will be forgotten if the script is reset while the light is off. Perhaps you could back it up in the description if that would be a problem in real life, but this doesn't seem like an especially reset-happy situation.

// assume default local light params until we see user ones
list last_known_light = [<1., 1., 1.>, 1., 10., 0.75];


FlipLight() {
    // get the current local light setting
    list lightparams = llGetPrimitiveParams([PRIM_POINT_LIGHT]);

    integer light_is_on = llList2Integer(lightparams, 0);
    

    // llGetPrimitiveParams only returns the old color etc. if the light is on.
    // Bummer, the editor remembers if you switch it off.
    if (light_is_on) {
        last_known_light = llList2List(lightparams, 1, 4);
    }

    llSetPrimitiveParams([PRIM_POINT_LIGHT, !light_is_on] + last_known_light);

}

default
{

    touch_start(integer total_number)
    {
        FlipLight();
    }
}

Thnx so much for the prompt replies! You've made me think thru the problem much more clearly and, of course, now i have more questions...

Thnx for the script idea Keira, it's not gonna work in this instance but it's really useful in itself - consider it filed for future use, thnx!

Now I'm wondering if it's possible to mash-up Urrong and Viktoria's ideas slightly...to explain; I'm using a link_message setup so the light-prim contains a script like -

default
{
    link_message(integer sender_num, integer num, string message, key id)
    {
    if (message == "ON")  llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, <1, 1, 1>, 1.0, 20.0, 1.0]);
    else 
    if (message == "OFF") llSetPrimitiveParams([PRIM_POINT_LIGHT, FALSE, <1, 1, 1>, 1.0, 20.0, 1.0]);

    }
}

Now I'm wondering if it's possible to trigger the 'llGetPrimitiveParams' call when the script receives the 'ON' link_message and just before it actually switches on the light? Rather than use a repeating Timer event, which I'm always wary of, could the script do a quick check to get the current user-set colour and then switch the light on to that colour?

If that's possible would a script reset matter, assuming that every 'ON' link_message would trigger the script to re-check the colour first?

Bit out of my depth here, but i really appreciate the help...

The trick with the llGetPrimitiveParams thing is that it will only return useful values if the light is already on. But, you have to turn on the light manually when you set it in the editor anyway, so this isn't that big of a problem.

What you could do for an ON link message is save away the value if the light was already on (no need to switch it on if it's already lit), else switch on with whatever values you saved earlier.

For an OFF message, again store away the colors (if the light is actually on), but go ahead and shut if off after saving.

Are we making this a little more complicated than it needs to be? From the original post it looks to me like the OP might just be looking for the llGetColor() function. Simply reuse the color returned for the color of the light when you call llSetPrimitiveParams(). For example:

vector primColor = llGetColor(ALL_SIDES);
llSetPrimitiveParams([ PRIM_POINT_LIGHT, primColor, intensity, radius, falloff ]);

http://www.lslwiki.net/lslwiki/wakka.php?wakka=llGetColor

Erm...oh, I don't know. FALSE is a useful value for telling you that the light is off, isn't it?

I guess so, you get one bit of information from a 5 element list, and one of those slots is a vector. So you're right, it's only it 86% useless!

OK, it seems I'm asking for the awkward if not quite the impossible? Thanks for the script Viktoria! As you said, it's not very reset-resistant, which might be a problem and it stores all the light settings not just the colour vector - but thanks, i appreciate it and I'll probably find a use for that later too...

The original idea was to have a very user-friendly way of setting a light colour, I figured using the graphic colour picker was the easiest, and to have that choice 'respected' by the script inside the prim.

Now I'm realising the better way, as already mentioned, might be storing a colour vector in the Description field, allowing the builder or end-user to edit that to their liking? How do I implement that into a link_message script - as I said before , this is a bit out of my depth?

There is a little set of color picker things I have for just this kind of situation, it's at
https://wiki.secondlife.com/wiki/User:Viktoria_Dovgal/Named_Color_Finder

To use it, you would paste in everything but the "test script" part at the bottom. Then, the end user could type any of the named colors, an LSL-style RGB vector, or an HTML-style #aabbcc color in the description.

For your snippet, it would work something like:

// color functions pasted here

default
{
    link_message(integer sender_num, integer num, string message, key id)  {
        if (message == "ON")  {
            vector lightcolor = GetColor(llGetObjectDesc()); // grab the color from the description

            // If the description's color is bogus, use white.
            if (lightcolor == _COLOR_ERROR)
                lightcolor = <1.,1.,1.>;

            llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, lightcolor, 1.0, 20.0, 1.0]);
        }
        else  {
            // We don't care what color it is if the light is off.
            if (message == "OFF")
                llSetPrimitiveParams([PRIM_POINT_LIGHT, FALSE, <1, 1, 1>, 1.0, 20.0, 1.0]);
        }
    }
}

Wow, fantastic! Problem solved and in a user-friendly way. I'd seen this implemented before but somehow never found my way to your original scripts.

Thanks again!

Oh, there are some better known commercial scripts around that use a smaller selection of the SVG colors. I put this one together out of frustration, had found the home of the other color scripts but the vendor was broken.