Jump to content

change face to black on touch


AdamZadig
 Share

You are about to reply to a thread that has been inactive for 1057 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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. 

Link to comment
Share on other sites

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 by steph Arnott
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by Rolig Loon
  • Thanks 1
Link to comment
Share on other sites

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!!!!!!

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ]);
    }
}

Link to comment
Share on other sites

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.

Screen-Shot-2019-01-08-at-23-07-14.png

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

Screen-Shot-2019-01-08-at-23-12-32.png

 

Screen-Shot-2019-01-08-at-23-12-42.png

 

Screen-Shot-2019-01-08-at-23-12-53.png

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

  • Like 1
Link to comment
Share on other sites

1 minute ago, chibiusa Ling said:

Screen-Shot-2019-01-08-at-23-07-14.png

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

Screen-Shot-2019-01-08-at-23-12-32.png

 

Screen-Shot-2019-01-08-at-23-12-42.png

 

Screen-Shot-2019-01-08-at-23-12-53.png

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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:

9a86d64c57962f2f0794f6a59db938b1.png

 

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.  😉

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1057 days.

Please take a moment to consider if this thread is worth bumping.

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...