change face to black on touch

[AdamZadig]

is there a script i can use to change a specifir prim face to black color on touch, and then to whte on second touch. 

i have an animated gif on a tv i made, and changing the face color to black on touch makes it look like an off switch. but need to be able to change the color to white on the next touch to turn it back on. 

[steph Arnott]

13 minutes ago, AdamZadig said:

is there a script i can use to change a specifir prim face to black color on touch, and then to whte on second touch. 

i have an animated gif on a tv i made, and changing the face color to black on touch makes it look like an off switch. but need to be able to change the color to white on the next touch to turn it back on. 

Firstly black is not < 0.0, 0.0, 0.0 >  it is < 0.6, 0.6, 0.6 >. Using all zeros throws up an error. Second, that is a basic switch. An open door close door is the same.

Edited January 8, 2019 by steph Arnott

[Rolig Loon]

Certainly.  When you write your script, treat it like any other toggle switch.  Set a global integer variable to TRUE when the face is white and FALSE when it's black, so
 

touch_start(integer num)
{
    llSetLinkPrimitiveParamsFast( link_number, [ PRIM_COLOR, face_number, llList2Vector( [ <0,0,0>, <1,1,1> ], (iON = !iON)), 1.0 ]);
}

where link_number is the number of the link that you are affecting, face_number is the number of the face on that link that you are coloring, and iON is your global switch integer.

[steph Arnott]

1 minute ago, Rolig Loon said:

Certainly.  When you write your script, treat it like any other toggle switch.  Set a global integer variable to TRUE when the face is white and FALSE when it's black, so
 

touch_start(integer num)
{
    llSetLinkPrimitiveParamsFast( link_number, [ PRIM_COLOR, face_number, llList2Vector( [ <0,0,0>, <1,1,1> ], (iON = !iON)), 1.0 ]);
}

where link_number is the number of the link that you are affecting, face_number is the number of the face on that link that you are coloring, and iON is your global switch integer.

<0, 0, 0> is ZERO_VECTOR. It is not a valid colour value. Also it is a float not and integer.

[Rolig Loon]

2 minutes ago, steph Arnott said:

Firstly black is not < 0.0, 0.0, 0.0 >  it is < 0.6, 0.6, 0.6 >. Using all zeros throws up an error.

Sorry, Steph.   < 0.0, 0.0, 0.0> is indeed black.  <0.6, 0.6, 0.6> is a nice grey color, but not black.  Neither one should throw up an error.

[steph Arnott]

Just now, Rolig Loon said:

Sorry, Steph.   < 0.0, 0.0, 0.0> is indeed black.  <0.6, 0.6, 0.6> is a nice grey color, but not black.  Neither one should throw up an error.

No, it is not. The system will at regular intervals conevert is to 'ZERO_VECTOR'. Even using <0.01, 0.0, 0.0>  will define it as not ZERO_VECTOR. And BTW the colour scope entirely depends on what computer monitor is used.

[AdamZadig]

thanks for this. im getting name not defined errors. the object is 1 prim and the face is 5. how would i write that properly?

8 minutes ago, Rolig Loon said:

Certainly.  When you write your script, treat it like any other toggle switch.  Set a global integer variable to TRUE when the face is white and FALSE when it's black, so
 

touch_start(integer num)
{
    llSetLinkPrimitiveParamsFast( link_number, [ PRIM_COLOR, face_number, llList2Vector( [ <0,0,0>, <1,1,1> ], (iON = !iON)), 1.0 ]);
}

where link_number is the number of the link that you are affecting, face_number is the number of the face on that link that you are coloring, and iON is your global switch integer.

thanks for this. im getting name not defined errors. the object is 1 prim and the face is 5. how would i write that properly?

[Rolig Loon]

Go ahead.... try it:

integer iON;

default
{
    touch_start(integer num)
    {
        llSetLinkPrimitiveParamsFast( LINK_THIS, [ PRIM_COLOR, 0, llList2Vector( [ <0,0,0>, <1,1,1> ], (iON = !iON)), 1.0 ]);
    }
}

It will work every time.  If you want face 5 instead of 0, just replace it.

Edited January 8, 2019 by Rolig Loon

[AdamZadig]

2 minutes ago, Rolig Loon said:

Go ahead.... try it:

integer iON;

default
{
    touch_start(integer num)
    {
        llSetLinkPrimitiveParamsFast( LINK_THIS, [ PRIM_COLOR, 0, llList2Vector( [ <0,0,0>, <1,1,1> ], (iON = !iON)), 1.0 ]);
    }
}

It will work every time.

THANK YOU!!!!!!

[steph Arnott]

1 minute ago, Rolig Loon said:

Go ahead.... try it:

integer iON;

default
{
    touch_start(integer num)
    {
        llSetLinkPrimitiveParamsFast( LINK_THIS, [ PRIM_COLOR, 0, llList2Vector( [ <0,0,0>, <1,1,1> ], (iON = !iON)), 1.0 ]);
    }
}

It will work every time.

Will not. It will periodicly throw an error. There is no such value in colour as <0, 0, 0 >. Firstly you force a float conversion, and second it confuses the system.

[AdamZadig]

HERES ANOTHER CHALLENGE|:

the tc has an animation script and a color script......

is is possible to put both codes in to the same script instead of having two?

 

script 1)

 

default
{
    state_entry()
    {
llSetTextureAnim( ANIM_ON | LOOP, 5, 5, 18, 0.0, 90.0, 15.0 );
    }
}

 

 

script 2)

integer iON;

default
{
    touch_start(integer num)
    {
        llSetLinkPrimitiveParamsFast( LINK_THIS, [ PRIM_COLOR, 5, llList2Vector( [ <0,0,0>, <1,1,1> ], (iON = !iON)), 1.0 ]);
    }
}

[Rolig Loon]

Yes.  Just do it. 

[chibiusa Ling]

27 minutes ago, steph Arnott said:

Will not. It will periodicly throw an error. There is no such value in colour as <0, 0, 0 >. Firstly you force a float conversion, and second it confuses the system.

http://wiki.secondlife.com/wiki/Category:LSL_Color

http://wiki.secondlife.com/wiki/LlSetColor

https://www.w3schools.com/colors/colors_picker.asp

https://rgbcolorcode.com/color/000000

 

 

Your referring to #111111 which is <0.067,0.067,0.067> but equally #000000 aka <0.0,0.0,0.0> is also valid. SL uses RGB in decimal form making <0.0,0.0,0.0> a valid shade

[steph Arnott]

1 minute ago, chibiusa Ling said:

http://wiki.secondlife.com/wiki/Category:LSL_Color

http://wiki.secondlife.com/wiki/LlSetColor

https://www.w3schools.com/colors/colors_picker.asp

https://rgbcolorcode.com/color/000000

 

 

Your referring to #111111 which is <0.067,0.067,0.067> but equally #000000 aka <0.0,0.0,0.0> is also valid. SL uses RGB in decimal form making <0.0,0.0,0.0> a valid shade

The ZERO_VECTOR error has been known about for ten years.

[Rolig Loon]

Could you please point me to a reference that documents it, Steph?  I have been scripting in LSL for almost 12 years and have never heard of that error or encountered it.  If it's there, I would love to know more about it.

[steph Arnott]

9 minutes ago, Rolig Loon said:

Could you please point me to a reference that documents it, Steph?  I have been scripting in LSL for almost 12 years and have never heard of that error or encountered it.  If it's there, I would love to know more about it.

For ten years people have been pointing out the ZERO_VECTOR issue. There is a thread here about it a month ago. We know the issue, and simply write it as <0.01, 0.0, 0.0>  the system will round it up to the lowest value.

[Rolig Loon]

If you can, please point me to a specific link, Steph.  I'd really like to know, because I'd hate to trip over a condition that has been well-documented but just escaped my attention.  I have been looking for JIRA reports on the topic for the past half hour and have found nothing yet.  The LSL wiki points consistently to advice like this, and  have found no mention of an error associated with black and ZERO_VECTOR:

 

[steph Arnott]

4 minutes ago, Rolig Loon said:

 

 

This is one off hundreds about the issue.

 

[Rolig Loon]

Thanks, Steph.  That particular thread doesn't say anything about the problem, though.  As KT Kingsley points out, correctly, "Yes, in a condition test the zero vector (whether intended or the result of a failed conversion from a mangled string) is treated as false, and any other valid vector is treated as true."  The OP in that thread is not being tripped up by the fact that he's using ZERO_VECTOR for the color black.  His problem is that he's testing ZERO_VECTOR in an if statement, where it will always be evaluated as FALSE.  That's a different problem.  I'm still looking for any documented case where ZERO_VECTOR does not evaluate to Black when it's applied as a color vector.

[steph Arnott]

1 minute ago, Rolig Loon said:

Thanks, Steph.  That particular thread doesn't say anything about the problem, though.  As KT Kingsley points out, correctly, "Yes, in a condition test the zero vector (whether intended or the result of a failed conversion from a mangled string) is treated as false, and any other valid vector is treated as true."  The OP in that thread is not being tripped up by the fact that he's using ZERO_VECTOR for the color black.  His problem is that he's testing ZERO_VECTOR in an if statement, where it will always be evaluated as FALSE.  That's a different problem.  I'm still looking for any documented case where ZERO_VECTOR does not evaluate to Black when it's applied as a color vector.

The issue crops up even as defined value in a script. The script can run a day, a month whatever then suddenly refuse to play. The issue was resolved as a work around by simply adding a stupid low value.

[Rolig Loon]

That just doesn't make sense to me, Steph.  Each of the r, g, b values in a color vector can take  a value in the range from 0.0 to 1.0, so <0.0,0.0,0.0> is just as valid as <1.0,1.0,1.0> and all values between them.  I'm not doubting you personally, but I would really like to see a documented case where that is not true, so that I can understand it..  I've written thousands of LSL scripts in the past 12 years and have not run across a hint of the problem myself.  If it's out there, though, I would really love to see an analysis of it.  Something fundamental like that could affect a ton of scripts.

[steph Arnott]

Just now, Rolig Loon said:

That just doesn't make sense to me, Steph.  Each of the r, g, b values in a color vector can take  a value in the range from 0.0 to 1.0, so <0.0,0.0,0.0> is just as valid as <1.0,1.0,1.0> and all values between them.  I'm not doubting you personally, but I would really like to see a documented case where that is not true, so that I can understand it..  I've written thousands of LSL scripts in the past 12 years and have not run across a hint of the problem myself.  If it's out there, though, I would really love to see an analysis of it.  Something fundamental like that could affect a ton of scripts.

Rollig the issue has been around as long as the touch start issue.

[Rolig Loon]

3 minutes ago, steph Arnott said:

Rollig the issue has been around as long as the touch start issue.

Maybe, but until I see some documented evidence of it -- or even credible mention of it somewhere -- I remain unconvinced, though curious.  😉

[steph Arnott]

Just now, Rolig Loon said:

Maybe, but until I see some documented evidence of it -- or even credible mention of it somewhere -- I remain unconvinced, though curious.  😉

LL have dropped the subject. Simply use <0.01,........................>

[Wulfie Reanimator]

1 hour ago, steph Arnott said:

the issue

You've gone off your rocker again, Steph. These are facts and not bugs:

1. "Using all zeroes" does not produce an error message.
2. Converting an integer 0 to float 0.0 does not "confuse the system." It seems to confuse you.
3. ZERO_VECTOR is a constant for <0,0, 0.0, 0.0>
4. <0.0, 0.0, 0.0> is the value of pure black color
5. In a conditional, <0.0, 0.0, 0.0> is intentionally treated as "false." It has nothing to do with color.
6. The color range of your monitor has no effect on what colors can be set in LSL.

You're flaunting your lack of understanding of LSL basics again, while stubbornly pretending that it is some bug that LL refuses to fix.