Simple question

[Sunvile]

 i have a scriptю it has several actions. transparent, translucent, opaque. etc. 
How to do, that would i have only opaque and transparent at 25% ?

  float Alpha = 1.0;
  
  default
  {
  	touch_start(integer dnum)
  	{
  		if(llDetectedKey(0) != llGetOwner()) return;
  		
  		if(Alpha > 0.2) Alpha = Alpha - 0.2;
  		else Alpha = 1.0;
  		
  		llSetAlpha(Alpha,-1);
  	}
  }

[Madelaine McMasters]

---

Sunvile wrote:

 i have a scriptю 

it has several

actions.

transparent

, translucent,

opaque

. etc.

 

How

to do, that would i

have only

opaque

and

transparent

at

25% ?

float Alpha = 1.0;

 

default

{

touch_start(integer dnum)

{

if(llDetectedKey(0) != llGetOwner()) return;

 

if(Alpha > 0.2) Alpha = Alpha - 0.2;

else Alpha = 1.0;

 

llSetAlpha(Alpha,-1);

}

}

---

float Alpha = 1.0;    default  {  	touch_start(integer dnum)  	{  		if(llDetectedKey(0) != llGetOwner()) return;  		  		if(Alpha > 0.25) Alpha = 0.25;  		else Alpha = 1.0;  		  		llSetAlpha(Alpha,-1);  	}  }

 That should toggle back and forth between 25% opaque and 100% opaque.

[Rolig Loon]

Or simply:

integer gON;default{    touch_start(integer num)    {        if(llDetectedKey(0) == llGetOwner() )        {            llSetAlpha(llList2Float([0.25,1.0],(gON = !gON)),ALL_SIDES);        }    }}

 

 

[Sunvile]

Thats what i need. Thank you. 

[dd Temin]

Very clever script method Miss Loon....I must remember this technique

dd

[Madelaine McMasters]

Rolig, you know I'm a contrarian, so I had to test your claim of "simply". It seemed to me that calling a list processing function would be less efficient than a float comparison. So, I placed our two different ways of toggling a float between 0.25 and 1.0 inside a loop and timed execution.

First, I placed my script into cube to make sure it actually worked (I had no doubt yours would ;-). It did! Then I placed our two approaches to the decision logic inside a 10000 iteration loop and timed execution. Then I added a method Snugs suggested, which scales your 0/1 toggle to 0.25/1.0

Here's the test script...

 

integer i;integer gON;float Alpha;float StartTime;default{    touch_start(integer total_number)    {        StartTime = llGetTime();        for( i = 0;i<10000;i++){          Alpha = llList2Float([0.25,1.0],(gON = !gON));        }        llSay(0, "R "+(string)(llGetTime()-StartTime));         StartTime = llGetTime();              for( i = 0;i<10000;i++){            if(Alpha > 0.25) Alpha = 0.25;            else Alpha = 1.0;        }        llSay(0, "M "+(string)(llGetTime()-StartTime));                StartTime = llGetTime();              for( i = 0;i<10000;i++){            gON = !gON;            Alpha = (float)gON*0.75+0.25;        }        llSay(0, "S "+(string)(llGetTime()-StartTime));    }}

 And here's the result of three touches...

[21:22] Object: R 1.977127
[21:22] Object: M 0.111844
[21:22] Object: S 0.111773

[21:22] Object: R 2.111148
[21:22] Object: M 0.132805
[21:22] Object: S 0.090014

[21:22] Object: R 1.870228
[21:22] Object: M 0.110197
[21:22] Object: S 0.066898

The reported times are in seconds, for 10,000 iterations. As I suspected, invoking lists to handle the logic is expensive. I'd also argue that the list method isn't obvious. And I'll further argue that although Snugs' method may be faster than mine, it's also less obvious.

Also...

 

            if(Alpha != 0.25) Alpha = 0.25;            else Alpha = 1.0;

 

or...

            if(Alpha != 1.0) Alpha = 1.0;            else Alpha = 0.25;

Would have worked as well.

 

[Rolig Loon]

Yay!  I love it, Maddy.

You and I have talked around the topic of "simply" a few times -- at least enough to come up with multiple definitions.  I like yours.  "Simply" means "resulting in less work for the servers," or perhaps "faster." 

Unless I'm working on a larger script than can be a resource hog, I tend to use a different definition.  My "simply" means "results in less work for me" or perhaps "most compact".  I am guilty of having learned many of my LSL scripting habits from a mentor who put a premium on compactness, sometimes to the ridiculous extreme of making her scripts unreadable.

Those versions of "simply" aren't incompatible, but it's hard to optimize both at once.  Being a lazy person, I go with "less work for me" until I get in trouble.  Then I listen to you.  :smileytongue:

[Madelaine McMasters]

---

Rolig Loon wrote:

Yay!  I love it, Maddy.

You and I have talked around the topic of "simply" a few times -- at least enough to come up with multiple definitions.  I like yours.  "Simply" means "resulting in less work for the servers," or perhaps "faster." 

Unless I'm working on a larger script than can be a resource hog, I tend to use a different definition.  My "simply" means "results in less work for me" or perhaps "most compact".  I am guilty of having learned many of my LSL scripting habits from a mentor who put a premium on compactness, sometimes to the ridiculous extreme of making her scripts unreadable.

Those versions of "simply" aren't incompatible, but it's hard to optimize both at once.  Being a lazy person, I go with "less work for me" until I get in trouble.  Then I listen to you.  :smileytongue:

---

What's simple does depend on the scope. I'm lazy, so I certainly get the "minimize my own effort" motive. But I also want to be liked, so I endeavor to make things that delight. That means optimizing my code to get the best peformance for the least money, thereby offering a good value to the customer. And I want to be liked by my peers, who will take my place as I run away from the things I've done to puruse things I don't yet understand. So I write my code to be as understandable as possible, both by avoiding clever but opaque methods (which I sometimes don't understand myself!) and by documenting anything I think isn't obvious, because some things are simply hard to understand.

And that last bit is probably the biggest single reason I strive for simplicity. I can understand it. I can't count how many times I have looked at old code and wondered what the hell I was thinking when I wrote it. Only after noodling with it for a while do I realize that I actually knew what I was doing, but hadn't commented it well, or at all. What appeared obvious to me at the time, and in no need of explanation, became nearly impenetrable just months later.

So it's been a lifelong effort to guide my coding style to be both efficient and empathetic. I like people, including my future self.

;-).

ETA: I should have mentioned the huge grin you put on my face with your "Yay!". I was expecting it, looking forward to it, and I thank you for it.

ETA2: During my career, I got generally positive feedback from those who had to work on my code years after I left it. But there was also a good bit of "Your code appeared easy to understand, but strange. It wasn't until we tried to make it less strange that we discovered that normal wouldn't work." I've decided to take that as a compliment. But that does illustrate that we can develop a style without knowing it. I have an RL friend who's 63 years old, and turns heads whenever I'm out shopping with her (I presume she turns them even when I'm not shopping with her, otherwise I've got a problem to ponder). She puts no more time into cleaning herself up than I do, but gets vastly different results.

... puts an apple on your desk.

[Rolig Loon]

True.  All considerations of efficiency, readability, and "simplicity" aside, we each develop a coding style that feels comfortable, despite evidence that other ways of doing things might be just as effective (or better).  I suppose that some of our preference for a personal style comes down to laziness.  It's easier to re-use familar, practices routines than to reinvent them from scratch each time.  The flip side to that is that it's hard to justify the time and mental effort that it would take to learn a new technique when the old one does the job.  (This is also why I drive the same car for ten years and don't go out of my way to try the new, improved breakfast cereal on the grocery shelf.  I'm a fuddy-duddy at heart.)

I labor with the advantages and handicaps of having never been taught to write computer code. All of my personal scripting quirks are home-grown or were stolen shamelessly from people who write better code than I do.  I am gloriously inconsistent about following "the rules", although I have a touch of OCD about being internally consistent.  I grew up with scientific programming, where the task often involves handling large nested arrays and doing endless loops of numerical analysis to suck an answer out of the data.  I suppose that biases me toward seeing the world through list-colored glasses, even in a language like LSL that is not array-friendly.  Old habits are hard to break.  Besides, I understand my own code quite well. :smileywink:

I love this forum. I've been in and out of here for most of 8 years, learning like crazy from great scripters who have mostly moved on now.  The times I look forward to most are those few when we crowd-source different ways to solve a problem. I have "Aha!" moments when I see that somebody else has a clever solution that beats my plodding method, and I hope other scripters occasionally find things in my posts that are worth stealing.

[Nova Convair]

I need to throw in that performance is irrelevant.

If I really do 10000 iterations then I would priorize performance, but in 99.99% thats not the case.

Fancy code constructs are  a personal matter. Some of them I use because I understand them with one view and some I avoid since I need to decode them 1st.