Primitive Params Point Light Help

[Raven Huntsman]

Hey guys I'm having some problems trying to switch a linked light on and off. Sounds like a simple task, but I'm having to use llGetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast.

I only want to switch the light on and off. Without touching the other light parameters. What I've noticed (maybe im screwing something up) is that when I retrieve all the parameters on touch and dump them to chat, they all have the correct values, I then send those values plus the flipped on/off bool back to the object. The subequent touch to turn it back on has all the point light values set to zero along with the color as black. (FYI, these point lights are probably flagged internally as projectors as I also have a projector texture set).

What's going here? (Note, I got verbose with the point light data and pulled it out into individual values as I was initially just using the original param list but couldn't figure out what was going wrong).

default
{
    touch_start(integer total_number)
    {
        //  Grab touched light link num
        integer link = llDetectedLinkNumber(0);
        
        //  Get it's point light params.
        list params = llGetLinkPrimitiveParams(link, [PRIM_POINT_LIGHT]);
        
        //  Enabled
        integer on = llList2Integer(params, 0);
        vector color = llList2Vector(params, 1);        
        float intensity = llList2Float(params, 2);
        float radius = llList2Float(params, 3);
        float falloff = llList2Float(params, 4);
                
        //  New param list with flipped enable bool
        list newParams = [PRIM_POINT_LIGHT, !on, color, intensity, radius, falloff];
        
        llSetLinkPrimitiveParamsFast(link, newParams);
    }
}

 

Edited September 9, 2020 by Raven Huntsman

[KT Kingsley]

My first suspicion is that you're using the wrong link number. Is the link you're clicking (as returned by llDetectedLinkNumber (0)) the same as the link that's intended to act as the light source?

[Fritigern Gothly]

Found your problem. The exclamation mark is a logical NOT. like if(!on) then .... (if not on, then...)

I think you intended to  use ~on instead.

[Rachel1206]

32 minutes ago, Raven Huntsman said:

Hey guys I'm having some problems trying to switch a linked light on and off. Sounds like a simple task, but I'm having to use llGetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast.

I only want to switch the light on and off. Without touching the other light parameters. What I've noticed (maybe im screwing something up) is that when I retrieve all the parameters on touch and dump them to chat, they all have the correct values, I then send those values plus the flipped on/off bool back to the object. The subequent touch to turn it back on has all the point light values set to zero along with the color as black. (FYI, these point lights are probably flagged internally as projectors as I also have a projector texture set).

What's going here? (Note, I got verbose with the point light data and pulled it out into individual values as I was initially just using the original param list but couldn't figure out what was going wrong).

default
{
    touch_start(integer total_number)
    {
        //  Grab touched light link num
        integer link = llDetectedLinkNumber(0);
        
        //  Get it's point light params.
        list params = llGetLinkPrimitiveParams(link, [PRIM_POINT_LIGHT]);
        
        //  Enabled
        integer on = llList2Integer(params, 0);
        vector color = llList2Vector(params, 1);        
        float intensity = llList2Float(params, 2);
        float radius = llList2Float(params, 3);
        float falloff = llList2Float(params, 4);
                
        //  New param list with flipped enable bool
        list newParams = [PRIM_POINT_LIGHT, !on, color, intensity, radius, falloff];
        
        llSetLinkPrimitiveParamsFast(link, newParams);
    }
}

 

#Fritigern Gothly pointed thew nasty error .

If you use fixed values but in on, it all works correct:

        //  Grab touched light link num
        integer link = llDetectedLinkNumber(0);
        
        //  Get it's point light params.
        list params = llGetLinkPrimitiveParams(link, [PRIM_POINT_LIGHT]);
        
        //  Enabled
        integer on = llList2Integer(params, 0);

        on= !on;

        vector color= <1.0, 1.0, 1.0>;
        
        float intensity = 1.0;
        float radius = 10.0;
        float falloff = 0.1;
                
        //  New param list with flipped enable bool
        list newParams = [PRIM_POINT_LIGHT, on, color, intensity, radius, falloff];
        
        llSetLinkPrimitiveParamsFast(link, newParams);

 

Edited September 9, 2020 by Rachel1206

[Rolig Loon]

Interestingly, there's a note regarding that behavior in the discussion tab for PRIM_POINT_LIGHT in the wiki:

If the light is being switched off then the colour will be multiplied down to <0,0,0> (black), but it seems that this is set when a light is disabled anyway (if you turn a light off then back on via script, it will be coloured black, with 0 for all values). -- --Haravikk 03:10, 17 February 2016 (PST)

The behavior was reported earlier (2007) in SVC-858 by Homer Horowitz and confirmed as a minor bug by several other people, but the JIRA was closed in 2010 and marked "Won't Finish".  So, I guess it is now expected behavior, although Rachel has found a way to beat it.  😉

[Wulfie Reanimator]

3 hours ago, Fritigern Gothly said:

Found your problem. The exclamation mark is a logical NOT. like if(!on) then .... (if not on, then...)

I think you intended to  use ~on instead.

But the logical NOT is correct, that's not the problem. That value ("on") can only be 1 or 0. If you try to use bitwise NOT (~), you get totally wrong values.

~(1) = -2
~(0) = -1

The script is written correctly, but the real problem is exactly what Rolig pointed out. Light goes off, color information gets removed. (I don't really understand what the benefit of this could be.) The solution would be to store the color data into a global variable. If there can be any number of lights (of different colors) in the linkset, maybe use a list of colors.

Edited September 9, 2020 by Wulfie Reanimator

[Raven Huntsman]

Thanks for this guys. So basically, for some odd reason the point light values are getting zero'd out when the point light is disabled. Which isn't expected behaviour, because if you manually turn a point light on and off via the build window, it will retain it's light settings. But by script this isn't the case. So when I switch it off, and then pull data to switch it on again, I'm getting a bunch of zeros. 

Seems like the only way to fix this is what I didn't want to do and cache the light values globally (I'm working with multiple lights) so that's a good 5-6 strided list potentially eugh. Is it worth me reporting this bug again? Seems like it was closed or lost with a jira upgrade?

[Raven Huntsman]

For anyone running into this problem in a simple context like this, this was my immediate solution. Most likely could use some optimisation.

 

//  5 strided list, link:link num, (vector)color, (float)intensity, (float)radius, (float)falloff
list data;

default
{
    touch_start(integer total_number)
    {
        //  Grab touched light link num
        integer link = llDetectedLinkNumber(0);
        
        //  Get it's point light params.
        list params = llGetLinkPrimitiveParams(link, [PRIM_POINT_LIGHT]);
        
        //  Enabled
        integer on = llList2Integer(params, 0);
        
        //  Flip enabled
        on = !on;
        
        //  Check if we have light settings data stored for this link
        integer index = llListFindList( data, ["link:" + (string)link] );
        
        vector color;;        
        float intensity;
        float radius;
        float falloff;
                
        //  If we have stored data, pull it out of the list.
        if( index != -1 ) {
            color = llList2Vector(data, index + 1);
            intensity = llList2Float(data, index + 2);
            radius = llList2Float(data, index + 3);
            falloff = llList2Float(data, index + 4);
        }
        //  If not, take it from the light params and add it to data (this should occur once)
        else {        
            color = llList2Vector(params, 1);        
            intensity = llList2Float(params, 2);
            radius = llList2Float(params, 3);
            falloff = llList2Float(params, 4);
            
            //  I'm storing the link number as a string with the format 'link:'+'number' because the link number could conflict with light settings data. This would give the possibility of not being unique which would not be desirable.
            data += ["link:" + (string)link, color, intensity, radius, falloff];
        }

        //  New param list with flipped enable bool
        list newParams = [PRIM_POINT_LIGHT, on, color, intensity, radius, falloff];
        
        llSetLinkPrimitiveParamsFast(link, newParams);
    }
}

 

Edited September 10, 2020 by Raven Huntsman

[Rolig Loon]

That's exactly what to do, and it's not all that clunky.  From reading Sue Linden's note in that JIRA, I get the sense that this was a minor enough bug that they didn't want to waste time fixing it at the time, so they just closed it.  Right now, while they are up to their ears moving stuff to the cloud, I doubt that they will be any more interested.  Your workaround is quick and easy.  I'd just smile and move on.

[Nova Convair]

What I do is: I put the light parameters in the description field of the light.
One script can easily switch many lights then, no need to store data and it's easy to change the light parameters.
Has additional possibilities like finding and switching a whole group of lights or alter the color (red alert) and so on, everything is possible.