SL Scripting acts like garbage more and more each day...

Ok here tell me what you think

Wheel1 = 6;
Wheel2 = 1;
Wheel3 = 6;


if(wheel1 == 6 && wheel2 == 6 && wheel3 == 6)
{
         plays += 1;
         winning += rollingbet * firstprize;
         llSay(0, "1");
}
//... a bunch of other else if's are omitted for this post.
else
{
}

tell me what do you think will happen? Will it go to the else or will it pull off the first "if".
If you thought else, you're wrong. Why? I don't know! HELP! lol.

I've tried it doing diff things like "if ((wheel1 == 6) && (wheel2 == 6) && (wheel3 == 6))" and no matter what it doesn't work. I think the SL compilier is messed up and can't handle a few if's and else if's lined up in a row.

Well, wheel2 = 1, so nothing should happen. Am I missing something?

I see your point because i am using a 1 but still it shouldn't stop at that if statement. I am trying to show you that the SL compiler is screwed. I have about 15 if/else if statements in a row for a paychart (that might seem like a lot of if's but there is no way to reduce that amount). Now it works fine when I use maybe 2 or 3 if statements but when I try to use more in a script then the SL compiler starts going a little crazy.

The SL compilier is complete garbage if you want to write anything big. I spread my scripts across multiple scripts in an attempt to make anything work but then lag starts to come. I'm not a n00b to programming, in a few years i'll be graduating wtih a major in computer science. I've talked to Adam Linden before about the SL compiler and i've shown him some source where it was broken and he agreed with me that there was nothing I could do but spread around scripts because although there are a few things taht should work, they don't.

He also told me that it wuold be awhile before they come out with a new SL compiler but they are working on one. ALthough i am not having a compiliation errors, the SL script run time in this case is buggared up.

Large if/else tables can kill compiler from what i hear, indeed.

Would suggest to break them up into a series of if() { // do stuff; return; } instead.

I'm by no means a scripting expert, nor a computer science major, but from my very limited experince with LSL, I can two problems right off the bat.

You define variable Wheel1, Wheel2 and Wheel3. The first letter in the variables are capitalized.

In the IF statement, your variables that you are comparing are all lower case. Variables are case sensitive.

The second thing I see is that your variables are not typecast. Wheel1 = 6; should probably be integer Wheel1 = 6;, etc.

If I'm missing something here, I'd appreciate it being pointed out to me, as I am trying to learn LSL.

Regards,
Sam

yes i know, i just quickly typed it in to use as an example on the forum. I know it's case sensative etc. My conclusion is that 22 if/else if's will not work in an SL compiler.

Yeah, if blocks can die. One solution that worked for me was just to have say 9 if/else-if's then an else, and inside the else put the remaining if/else-ifs and repeat as needed.

Use lslint from:
http://w-hat.com/lslint/

It will tell you when your code exceeds the lsl compiler stack limits.

I organize my code so that I use a return statement instead of else.

  if (condition1) {doOneTHing (); return;}  
  if (condition2) {doTwoTHing (); return;}  
  if (condition3) {doThreeTHing (); return;}
  // nothing matched - error

Would not pass Programming 101, but it works.

yea thats what i ended up doing, using return statements. THanks for the tips everyone, you've all been helpful. Problem solved

integer a = 1;
integer b = 1;
integer c = 1;

default
{
    touch_start(integer total_number)
    {
        if ( (a == 1 && b == 1) && c == 1) llOwnerSay("equal");
        else llOwnerSay("not equal");
    }
}

you can still line them up like you want, i think my statement got lost in the moment
but it boils down to mathmatic order of operations

(a == 1 && b == 1) in () so it goes first

if a comes out to be true and b comes out to be true then (a == 1 && b == 1) = TURE

then if (a == 1 && b == 1) = TRUE and c==1 returns TRUE the entire statement is true

else ...

There is a limit (24) to if... else's in order: http://secondlife.com/badgeo/wakka.php?wakka=ifelse

I recently did something similar to this. The one I was working on paid out if all three wheels matched, whatever the result, but different numbers depending on which one came up. I used (in pseudo code)

if(wheel1 == wheel2 && wheel1 == wheel3)
{
    if(wheel1==1)
    else if(wheel1==2)
    etc.
} else if .... //whatever the next set of payouts was. I think it was if any 2 match so:
if((wheel1==wheel2) || (wheel1==wheel3) || (wheel2==wheel3))
{
   do stuff for the right values, ignore the others...
}

If you have a large number of repeated combinations which just have a different payout, you could also turn the wheel positions into a vector and have it matching to a list.

e.g.

list gPayouts = [
<1, 6, 2>, 10,
<2, 1, 1>, 50
...
];
...
integer pos = llListFindList(gPayouts, [<wheel1, wheel2, wheel3>]);
if (pos > -1) {
   integer payout = llList2Integer(gPayouts, pos + 1);
   llSay(0, "kaching");
}
else {
   // do other stuff
}

Just a thought, anyway.

Not sure if this is a real problem in sl, but floats do no always accurately shadow integer numbers, so I would think the use of vectors containing float components not always infallable. Comparing floats should allow for a very small delta to be reliable.

No, that's true. I thought that the implicit casting of integers in both the list and the creation of the vector might solve that - but I've not tested it.

Actually, come to think of it, you wouldn't even have to use vectors, that was an odd idea at an odd time of the morning. You could just use an integer list, something like

list gPayouts = [
1,1,1, -1000,
1,2,1, -500,
2,1,2, -100,
3,1,1, -50
];

check_wheels(key id, integer wheel1, integer wheel2, integer wheel3)
{
   integer pos = llListFindList(gPayouts, [wheel1, wheel2, wheel3]);
   if (pos != -1) {
      integer payout = -llList2Integer(gPayouts, pos + 3);
      llGiveMoney(id, payout);
      llSay(0, llKey2Name(id) + " is a winner!");
   }
   else {
      // whatever
   }
}

default
{
   touch_start(integer n)
   {
      check_wheels(llDetectedKey(0), llCeil(llFrand(6.0)), llCeil(llFrand(6.0)), llCeil(llFrand(6.0)));
   }
}

Note that the payout is stored as a negative integer, just in case it is below the maximum value of a wheel and a combination gets duplicated somewhere.