So--- are my math skills wrong, or did LSL forget how to do math?

[Phiona Mercy]

link_message(integer Source, integer Number, string String, key Key) // This script is in the object too.
    {
    integer Prim   = (integer)Source;
    integer Int    = (integer)Number;
    string  Str    = (string)String;
    key     Code   = (key)Key;
    integer NameServerCode = (integer)2;
    integer StatsServerCode = (integer)3;
    integer TargetServerCode = (integer)4;
    
    llOwnerSay("The source of this message is prim #" + (string)Prim + " .The Number coming with it is " + (string)Int + ". The Associated String is: " + Str + ". And the associated key is: " + (string)Code);
    
    //if (Source == 1)
      // {
       //return;    
       //}
    if ((integer)Int == NameServerCode);
       {
        NameServer = Prim;
        llOwnerSay("NameServer has been assigned to " + (string)NameServer);    
        }      
    if ((integer)Int == StatsServerCode);
        {
        StatsServer = Prim;    
        }
    if ((integer)Int == TargetServerCode);
        {
        TargetServer = Prim;
        //llOwnerSay("TargetServer has been assigned to " + (string)TargetServer);    
        }   
    }    
}

... Three different prims send messages. The content of those messages shouldn't even matter, because all I am reading is the integer attached to it. The read-out from those three messages ALL trigger the text of ALL three logical gateways...

 

The end-output from the strings? Is absolutely ridiculous:

 

[02:13] Sabina's HUD: The source of this message is prim #3 .The Number coming with it is 2. The Associated String is: NameServer!. And the associated key is:
[02:13] Sabina's HUD: NameServer has been assigned to 3
[02:13] Sabina's HUD: The source of this message is prim #4 .The Number coming with it is 3. The Associated String is: StatsServer!. And the associated key is:
[02:13] Sabina's HUD: NameServer has been assigned to 4
[02:13] Sabina's HUD: The source of this message is prim #2 .The Number coming with it is 4. The Associated String is: TargetServer!. And the associated key is:
[02:13] Sabina's HUD: NameServer has been assigned to 2
[02:13] Sabina's HUD: All Servers Loaded:
[02:13] Sabina's HUD: TargetServer = prim 2
[02:13] Sabina's HUD: NameServer = prim 2
[02:13] Sabina's HUD: StatsServer = prim 2

 

All three prims ... trip all three logical gateways every time no matter what I change the integer to. It's awe-inspiring to me. I feel like LSL (or rather, specifically 'link_message' events) might be experiencing a math-fail with it's == questions. I've tried writing them with resigning them as integers, I've tried them as numbers.

I need these prims to self-identify, rather then using it's link-position.... and I feel like link_message is having a brain-fart.

 

The only thing I haven't tried is turning them into floats...

 

And the main reason I'm doing it like this, is because when I link a new object on top of it.. (Select new object.. hold down shift, Select rest of link-set... Ctrl + Link) ... it stacks the new object on the end (link #4) as it should-- but when I pick the object up into my inventory -- next time I rez, or wear it... it has the new object as link #2. So I was trying to find a way around that...

 

All of them are sending messages with a seperate integer as displayed above, and below:

Sender = RootPrim (they're all receiving a 'RoleCall' LinkMessage that -is- striggering...)

//Prim #2
   llMessageLinked( Sender, 4, "TargetServer!","");

//Prim #3
    llMessageLinked( Sender, 2, "NameServer!","");

//Prim #4
    llMessageLinked( Sender, 3, "StatsServer!","");

It's so weird.

[Freya Mokusei]

Oooo I know what you've done.

Semi-colons on the end of the if's will always return TRUE (I'm sure there's a reason why, but reason is lost to swearing in these instances). I've done this myself a tonne of times!

So just:-

if(1 == 1){

 

 It's always a right headache.

 

[Phiona Mercy]

You are a walking diety, and I bow before your awesome digital power.

 

I was all;

 

"BUT MY MATH ISN'T WRONG! ; . ; "

 

LOL... Fix't and it worked instantly. Thank-you so much. 4 hours -- possibly more. Head-smashing keyboard.

 

"WHEN MY SCRIPT ASKS YOU... IF 2 IS THE SAME AS 3... OR THE SAME AS 4... YOU'RE SUPPOSED TO COME BACK FALSE!" lol.

[Freya Mokusei]

Hahaha.

I saw "maths.... wrong?" and was like, CHALLENGE ACCEPTED.

In this case it's just having a second pair of eyes. You wouldn't believe how long I've puzzled over the same issue before smacking the top of my head. I'm always happy to be there for that!

Glad it was an easy fix!

[Phiona Mercy]

You got my kudos! <3

[Freya Mokusei]

Wooooo~

Good luck with the project!

[Rolig Loon]

---

Freya Mokusei wrote:

Oooo I know what you've done.

Semi-colons on the end of the if's will always return TRUE (I'm sure there's a reason why, but reason is lost to swearing in these instances). I've done this myself a tonne of times!

[ .... ]

---

I think any LSL scripter has done that a "few" times, Freya.  The reason why is that an if test always applies to the scope that follows it immediately.  When you type a semicolon, the logical assumption is that you have provided an empty scope -- that is, a one line executible statement that doesn't have anything on it.  In this case, the block of statements in curly brackets after each test is therefore being interpreted as an independent block, unrelated to the preceding if.  It gets executed regardless of what the test says.

[Freya Mokusei]

---

Rolig Loon wrote:

I think any LSL scripter has done that a "few" times, Freya.  The reason why is that an

if

test always applies to the scope that follows it immediately.  When you type a semicolon, the logical assumption is that you have provided an empty scope -- that is, a one line executible statement that doesn't have anything on it.  In this case, the block of statements in curly brackets after each test is therefore being interpreted as an independent block, unrelated to the preceding

if

.  It gets executed regardless of what the test says.

---

That makes sense!

Kinda like the semi-colon orphans the indented block beneath it.

Thanks for the explanation.