some help needed here please for changing texture

I'm trying to make a script that will change the texture on one side of a prim.
I'm using uuid numbers to change the texture, what I would like is 2 textures on the same side and to "flick" from one texture to the other by clicking the side of the prim.

default
{





touch_start(integer total_number)
{
llSetTexture("uuid texture 1",4);


{ llSetTexture("uuid texture 2",4);

}


}

it changes the texture to texture 2 but when clicking again it doesnt change to texture 1. any help appreciated thank you.

You need a switch.

integer ON = TRUE;
default
{

touch_start(integer total_number)
{
if (ON)
{ 
llSetTexture("uuid texture 1",4);
}
else
{ 
llSetTexture("uuid texture 2",4);
}
ON = !ON;
}
}

Thank you Rolig
much appreciated

alternate switch

integer gBooSwap;
list    vLstPicKeys = ["uuid#1", "uuid#2"];
default{
  touch_start(integer total_number){
    llSetTexture( llList2Key( vLstPicKeys, (gBooSwap = !gBooSwap) ), 4 );
  }
}

or the alternate cycling version which allows more than 2 pics

integer gIdxSwap;
integer gIntPicCount;
list    vLstPicKeys = ["uuid#1", "uuid#2", "uuid#3"];

default{
  state_entry(){
     //-- (vLstPicKeys != []) == llGetListLength( vLstPicKeys ) :faster, smaller.
    gIntPicCount = (vLstPicKeys != []);
  }

  touch_start( integer total_number ){
    llSetTexture( llList2Key( vLstPicKeys, (++gIdxSwap % gIntPicCount) ), 4 );
  }
}

Wow... I had no idea you could do that, you're specifying the list entry AND performing the statement gBooSwap = !gBooSwap to toggle the variable between zero and one all in one shot! Jeez Void, you are Über Scripter!

llList2Key( vLstPicKeys, (gBooSwap = !gBooSwap) );

I of course knew you could do math, i.e. llList2Key (vLstPicKeys, (gBooSwap + foo)); but I had no idea you could supply a value AND perform a statement from within a function like that!

I'd like to know why (vLstPicKeys != []) works as a substitute for llGetListLength( vLstPicKeys ). I was hoping that my morning coffee would bring enlightenment, but I'm still as foggy as I was last night.

because when you do direct comparions between lists, the list length is actually what's being compared, not the contents

using (A != B) returns returns (A.length - B.length)
if you reverse the order, you'll get a negative index which could actually be used to walk the list forward instead of backwards in an increment loop since -(index count) = the first element (because indexs wrap around for most things in SL)

Note: you should always contain logical comparisons in () for accurate returns

all those tricks were publicized by Strife Onizuka

I'm hoping to update the wiki soon so that you can see what operators work on what variable types and how, and then I may have a few more useful tricks, just waiting for feedback on the layout (I'm aiming to make it more like the Types category, because all the extra info that will be included will clutter a single page)

ETA:
for clarity, the difference between using ++X or X++ is that X will be read after the increment in the first example, and before the increment in the second example. -- works the same way. this is standard behavior for languages that use those operators

Lovely! Thank you.

Ok, so you are saying that == and != are not direct comparisons by LSL, instead the operator is overloaded to return A.length - B.length for a list, as opposed to just a simple TRUE or FALSE?

If that is so, another reason for LL to actually release some documentation on how the hell these operators and such work.

for lists, apparently, yes. (although it's vaguely possible it's just implemented differently for different types, but that seems really stupid), although it looks just to be the != operator.

although if we assume that they have similar implementations then == may be set up (for lists) as
(!(A.length - B.length)) and it still yields a boolean ( unlike != )

none of this applies to any other Type though, they all return boolean [0|1]

SO is it just me, or is the shortcut they took, by not doing a simple boolean return on that operator just lazy? I understand how it's useful, and it's a nice "feature" even though undocumented by LL. But really? shouldn't a boolean operator return a boolean value, or am I just being hard nosed?

heh you're not the only one to feel that way, although because of conditional analysis it USUALLY has the same effect. it is inconsistent, but oddly enough LSL isn't the only language to pull a similar trick. VB also did (still does?) something similar in treating arrays as their length for comparison operators.

I think the whole length comparison thing comes from the fact that the length is encoded in the variable header, so is easy to access.

and, anyway, nothing in LSL returns a boolean; TRUE and FALSE are integers, so why not enjoy this side effect. I must say, it is rather unexpected though and could cause problems for anyone who assumes TRUE will always be 1. I only ever assume FALSE will be 0 and TRUE will be anything but 0.

supposedly this behavior MAY go away in the LSL3 update... I see many broken things in the future if so (and yes this is recent news to me, so you won't see me using this trick anymore on the forums)

Yeah, I know that is why it was done, anything but 0 is True, but my major complaint about it, is that it's undocumented (or if it is documented, I missed it). How hard is it to document a function, with the types it takes, and an output, especially for a boolean operator. Just seems like sloppy, uncaring coding to me

lol nothing in lsl is documented (by LL anyways), but it IS inconsistent with the returns from the same operator used on other data types

ETA:
correction, there IS an official ll document on scripting, that comes with the client, however it never metions how the comparison operators != and == work

I think LL lives by the "If you use it the way you are suppose to, it works just fine, so why should we bother fixing it!"

Reminds me of a guy who was working for a large software company, based in Seattle. He emailed his boss asking him "If this conditional comes up in this switch statement, what should I put?" His bosses reply was that it will not come up so put this in, of course this was highly offensive. We know the rest of the story, once users got a hold of it, of course that conditional came up all the time, so the user was bombarded by the offensive material. Luckily the programmer kept the email with his bosses reply, and kept his job, the boss, nice pink slip.