Full Birght On/Off?

Hey everyone :3 just curious, but is it possible to have an on-touch script that toggles full bright on or off? If so, do you think I could find it in the Wiki or library here?


thanks a ton in advance!

integer FACE = 0;
default {
touch_start(integer n) {
integer on = llList2Integer(llGetPrimitiveParams([PRIM_FULL_BRIGHT,FACE]),0);
llSetPrimitiveParams([PRIM_FULL_BRIGHT,FACE,!on]);
}
}

whoo! Thanks Argent, but it's giving me this error (I tried playing around with the order of things, but I can't figure out why it's giving me an error) "Name not defined within scope"
It's putt the marker inbetween BRIGHT and the comma x.x;
([PRIM_FULL_BRIGHT,FACE])

The word FULLBRIGHT shouldn't have an underbar in it. It's just FULLBRIGHT.

ETA: LOL I went back to edit my note and Dora got it in the meantime..... Yay Dora!

Try: PRIM_FULLBRIGHT instead of PRIM_FULL_BRIGHT

Will do Dora!

for the integer since i'm changing the faces to "ALL_SIDES" (it's a mask, so I'm only looking to put 1 side full bright, really...but I think it'd get too technical to try and tell which side to full bright?) do I change integer FACE = 0; to integer ALL_SIDES; or take it out entirely? x.x

You can tell I wrote that off the top of my head. Sorry for the typo.

I don't know what will happen if you GET primitive parameters from ALL_SIDES. I would leave FACE in the GET line and change it to ALL_SIDES in the SET line. That will use the full-bright-ness of face 0 as what it's toggling on.

uu, yay! It works!

XD mind helping me with something else? It's a little more advanced.. Void linked me to this script before, it's a color picker that finds the name of specific prims inside a linkset and only changes the colors of those prims... can I do that for the FullBright function?

her script: http://wiki.secondlife.com/wiki/User:Void_Singer/Programs#v7-D_Enh._Color_Picker

I'm sure I can, tried figuring out what I can take out/replace... but there's a lot of words/phrases/half substrings etc I don't understand that might be useful x.x

the mask's visor is in three parts, two side panels and the front- need those to go full bright. So instead of clicking one at a time, I can use the method in that script to just click the linkset and toggle "On/Off" in the menu to turn it.. on and off <3

I would recommend just going and trying it. You'll learn a lot from figuring out the changes you need to make, and WHY you need to make them.

I'll just say, yes you can but you have to keep track of the FULLBRIGHTness of the prims yourself, you can't GET that remotely from another prim.

You might find this thread /54/06/265951/1.html useful, particularly the second example Hewee Zetkin very kindly gave me. It's the same as Void's method, but just gives you the basic function that finds the named prims and changes them, so you might find it helps you into Void's rather more complex example.

:3 thank you Innula~ unfortunately I'm really not that great at this, so I couldn't get past the syntax error... I'm not sure how to go about putting something after default... or if default goes before the string @_@ -not proud of that- I think I'm just too right brainded for this XD; ahh..

but I did give editing Void's script a go... I'm stuck at what to do with this:

http://img.photobucket.com/albums/v38/neko-vamp/Error.gif

I get the feeling "16" is relating to the color value, but I don't know if I need the two lines, the entire set, or if I should take out the 16? Wouldn't make much sense in the pattern I see that goes along with the coding so far...

I'm sure if I figure this bit out, they'll be more errors... I'd be really, ungodly indebted to anyone who's willing to take my hand through this & explain what's going in the script as the errors pop up. I know it says in the bottom, but it might as well be an inside joke from a different culture's standard of funny XD;

thanks all <3 am willing to learn, as long as someone's willing to teach

Try this. Name the prims you want to change "visor" (without the quotes) and then drop this into the linkset:

string TARGET_PRIM_NAME = "visor"; // name of the prims you want to change
changeAllTargetPrims(list primParams)
{
   integer i;
   for (i = llGetNumberOfPrims(); i > 0; --i)  // loop through the linkset
   {
      if (llGetLinkName(i) == TARGET_PRIM_NAME) // if the name of the prim is what I'm looking for
      {
         llSetLinkPrimitiveParams(i, primParams); // change the prim's characteristics
      }
   }
}

integer bright = FALSE;

list  params = [PRIM_FULLBRIGHT,ALL_SIDES,bright]; //forgot this the first time
default
{
    state_entry()
    {
        changeAllTargetPrims(params);  // start with fullbright off
    }

    touch_start(integer total_number)
    {
        bright =!bright;  //toggle bright between on and off each time you touch the prim
        params = [PRIM_FULLBRIGHT,ALL_SIDES,bright]; // change the value of bright in my list of params
        changeAllTargetPrims(params); //and apply it to my target prims
        
    }
}

Void's script is for changing the colour values of target prims in the linkset by adjusting the RGB values of the colour separately. She's doing this by giving you the hex values used in CSS/HTML and converting them to the colour vectors used by lsl (see https://wiki.secondlife.com/wiki/Color_and_Scripting for an explanation).

You could certainly adapt her script to feed color vectors to your parameter list; llSetLinkPrimitiveParams lets you change lots of things at once. That's a bit more complicated, though, than my simple example for turning PRIM_FULLBRIGHT on and off with a touch toggle, since you would probably want to control everything from a single dialog menu and change the values of

 [PRIM_FULLBRIGHT,ALL_SIDES,bright,PRIM_COLOR,ALL_SIDES,my_color_vector,my_alpha_value]

. You'd then feed values to the list from the responses to the dialog menu, and change the visor prims when you get the new values in the listen event.

If there's many prims in the object it would be more efficient to make a list of the prims named "visor" once, and step through that list.

i think it averages out the colors between all the faces somehow
try this, change the color on each face to something different, and look at the results from the changed event, and then touch each face, the results probably won't be the same

float colorx;
float colory;
float colorz;
default
{
    state_entry()
    {
        vector color = llGetColor(ALL_SIDES);
        llOwnerSay("the test with all sides is " + (string)color);
        integer len = llGetNumberOfSides();
        integer i = 0;
        for(i;i < len; ++i)
        {
            color = llGetColor(i);
            colorx += color.x;
            colory += color.y;
            colorz += color.z;
        }
        color = < colorx,colory,colorz >;
        llOwnerSay("the result combined from the loop is " + (string)color);
        color = color/len;
        llOwnerSay("the averaged color is " + (string)color);
    }
    
    touch_start(integer n)
    {
        integer face = llDetectedTouchFace(0);
        vector color = llGetColor(face);
        llOwnerSay((string)color);
    }
    
    changed(integer change)
    {
        if(change & CHANGED_COLOR)
        {
        vector color = llGetColor(ALL_SIDES);
        llOwnerSay((string)color);
        }
    }
}

Something on the lines of this? I know this works but I'm wondering if it's the best way to do it, since I want to use something similar on some very large linksets.

list visor_prims;
integer bright;
string target_name = "visor";

build_list(){
    integer i;
    integer max = llGetNumberOfPrims();
    for (i=max; i>=0;--i){
        if(llGetLinkName(i)==target_name){
            visor_prims+=i;
        }
    }
}

change_prims(list params){
    integer i;
    integer n;
    integer max=llGetListLength(visor_prims);
    for(i=max;i>=0;--i){
            llSetLinkPrimitiveParams(llList2Integer(visor_prims,i),params);
    }
}
        

default {
    state_entry() {
        build_list();
    }
    
    touch_start(integer num_detected){
        bright=!bright;
        list params =[PRIM_FULLBRIGHT,ALL_SIDES,bright];
        change_prims(params);
    }
    
    changed(integer change){
        if(change&CHANGED_LINK){
            build_list();
        }
    }     
        
}

All except for one thing:

integer i;
integer n;
integer max=llGetListLength(visor_prims);
for(i=max;i>=0;--i){

Last line should either be

for(i = 0; i < max; i++)

or

for(i = max-1; i >= 0; i--)

Whether you're counting up or down, you don't need to loop over it with i == max.

Also, if you're going to count down, and you don't care about the number of prims afterward, you can shed two variables:

integer n=llGetListLength(visor_prims);
for(n--; n >= 0; n--)

Salt to taste: You can use pre or post increment and decrement as you like. I'm just accustomed to using predecrement and after 30 years I ain't changing.

Thank you.. shedding the variables makes a lot of sense.

also if you're decrementing from the last link to the first, you don't even have to check if it's more than 0, you can just leave it as true or false

integer max = llGetNumberOfPrims();
for(max;max;max--)

the second argument just checks if it's still true, which is any number but 0 and you're starting with a number higher than 0 so you don't need to worry about turning negative

1. That's only true for the specific case of llGetNumberOfPrims where the prim index is 1-based, not zero-based. For the loop over llGetListLength(visor_prims) that's not true.

2. I would recommend against writing a loop with an equality for the ending condition, because it's a dangerous habit to get into... because one day you'll use it for a case where you might not start out >0.

yeah i meant to make a note of that, i was talking specifically about links, for 0 based indexes i usually find the max, start at 0 and increment while it's less than max, but in the build list function it is using a 1 based indexing but with i >= 0, when you get to zero, the name will return "", of course it wouldn't matter for that script, but it could cause some problems if you need to keys or names of all the prims

Point taken, but I share Argent's caution; I find it far simpler to try to get into the habit of doing stuff in a way that's always going to work rather than trying to remember when doing something a particular way works and when it's going to introduce errors, because I know what my memory's like and how long it takes me to trace the error when it lets me down.

It's not so much that I can't remember when it's safe, it's just that I've run into too many cases where, for example, APIs documented as returning 0..N pop up a -1 after an upgrade because a new failure mode showed up down the line and the guy who modified the function forgot he was supposed to return 0 for failure.

That's not likely to happen here, but if you get in the habit of assuming the f***-up fairy's gonna coma knocking, you won't discover you left the door unlocked at an embarrassing moment.