Arcadia's Scripts

[Snoots Dwagon]

EDIT: Snoots completely removed this answer because of learning something new from John (see below), and coming to the realization that LsL structure is totally insane. ;D

[Koshari Mahana]

Thank you for explaining

If there is time maybe we could work on this project together. My price: I get one to put at the Wellspring Tiny Playground. ;D

Of Course! I can pass you the ones that I have scripted directly but all of them unscripted can be found at:
hop://grid.kitely.com:8002/Arcadia-Aley%20Library/462/119/3

Not all of them are scripted and a few of them are not copyable.

I've added thee scripts to weight scale, whack a pirate, the wheel, the shooting gallery (I changed out the guns and the targets... I don't like shooting African animals so I used bottles), and I redid the ducks entirely but I have the scripts too. I also have the circus organ and I've put additional sounds in it you want those. You are welcome to anything I have from Arcadia. I probably won't do Zoltar because there are much better ones on the Kitely Market.

I love her work but you should know that everything is sculpted prim, not mesh.

If you think we can get the High Striker working that would be amazing. (I'm not much help with scripts)

[Snoots Dwagon]

Of Course! I can pass you the ones that I have scripted directly

Sure thing Kosahri. You can just drop stuff in a box and IM them to me, along with a notecard if you like telling me what you need done and what you've succeeded at so far. We'll try to figure it out. : )

[Koshari Mahana]

Sure thing Kosahri. You can just drop stuff in a box and IM them to me, along with a notecard if you like telling me what you need done and what you've succeeded at so far. We'll try to figure it out. : )

Great, I'll box them up tomorrow for you.

[John Mela]

= is a logic comparison (Boolean) if (A = TRUE)

This isn't quite true, Snoots - it's a lot simpler than that[1]. Consider this code:

Code: Select all

        integer b = FALSE;
        if (b = TRUE) llOwnerSay("huh?");

If = were a boolean comparison operator, you'd expect no output, but it prints "huh?". Why?

The reason is that = is always an assignation in LSL. And that b = TRUE is not testing if b is TRUE, but actually setting b to TRUE. So what's happening here?

An assignation does return a value - the value of the assignation itself. So if (b = TRUE) is setting b to TRUE, and then returning the value TRUE to the if statement, which is why the output is printed.

Now consider this:

Code: Select all

        integer x = 123;
        if (x = 234) llOwnerSay((string)x);

That will print "234" because x will be set to 234, and the assignation will return 234, which is non-zero and so treated by LSL as TRUE.

This behaviour is actually useful. For example, the following two snippets are equivalent:

Code: Select all

string PrimName() {
    return llGetObjectName();
}
default {
    state_entry() {
        string name = PrimName();
        if (name == "Object") llOwnerSay("This is " + name);
    }
}

Code: Select all

string PrimName() {
    return llGetObjectName();
}
default {
    state_entry() {
        string name = "";
        if ((name = PrimName()) == "Object") llOwnerSay("This is " + name);
    }
}

Not a great deal of use in that example, but in certain circumstances it can keep code neater if you take advantage of that. A much more common example is this - say you have three variables that you want to assign the same value to, you can do this:

Code: Select all

      x = y = z = GetValue(); // set x, y and z to output of GetValue()

which is much neater than:

Code: Select all

    x = GetValue(); // set x to output of GetValue()
    y = x;
    z = x;

These, of course, are silly examples, just to demonstrate, but this feature can be especially useful in more complex contexts, keeping things looking neat and readable - assuming you understand the underlying principles, that is!

As a personal aside, I'm not in favour of terseness for its own sake. Some programmers love to come up with code that will do in one line what would normally take six lines, but at the cost of easy readability. Many years of working in teams in real-world software companies knocked that habit out of me pretty quickly, and unless absolute efficiency is required (and the code is very well commented), it's much better to have things plainly laid out. So I use the above techniques quite sparingly in production code.

[1] Depending on your interpretation of the word "simple"

[Snoots Dwagon]

Well John, that's twice today you've taught me something new about scripting. And about LsL insanity. Thank you... kinda.

integer b = FALSE;
if (b = TRUE) llOwnerSay("huh?");


... is in my mind an ultimate example of really bad coding structure. It explains why some scripts "don't work right". The fact that LsL documentation itself has stated that = within a decision structure is a boolean operator makes things that much worse. Makes me want to kick the creators of LsL and the SL Wiki right in the slats. (I do have to admit I have wondered for years why = is used at all within if() structures.)

I suppose a more proper way to write the above would be: if ( b & TRUE) ? Or of course, just: if (b) ...

To be honest, I've never been a real fan of boolean operators. We're not writing in bit-code. if (b ! 0) works just fine. And eliminating == altogether would have worked fine. Poor language design.

I'm now starting to understand why so many scripts were troublesome to write. If this kind of stuff exists in LsL... that's just nuts. And like you say, coders using this kind of counter-logic in RL is just as crazy (and why some code is nearly unreadable). Scripting language should function and be written as people think for future readability. This just adds to the opinion pile that LsL is inherently a badly-designed language. (Cory Linden himself stated that years ago. I now fully agree with him.)

As a personal aside, I'm not in favour of terseness for its own sake. Some programmers love to come up with code that will do in one line what would normally take six lines, but at the cost of easy readability. Many years of working in teams in real-world software companies knocked that habit out of me pretty quickly, and unless absolute efficiency is required (and the code is very well commented), it's much better to have things plainly laid out. So I use the above techniques quite sparingly in production code.

I couldn't agree more. I think all the terse code mania is a holdback from the days when coders were trying to work within a limit of 4k RAM. Such is no longer necessary. In current days it's often a result of coder ego and "look how leet I wrote this"... which can be chucked out the window as well.

The shame of it is that I like the basic concept behind LsL. Event scripting is a fascinating concept within the virtual world environment (although far too limited. ONE timer event?). But now I'm starting to question the rationality of that entire structure... and the logic of how the language was designed from the ground up. Well to be honest, I've always questioned it, from the day I was introduced to LsL (after 20 years of professional coding in RL). I wonder if all the virtual worlds would be willing to change the entire concept of LsL at this point?



(In the early days of SL, there was serious discussion about adding a more logical, user-friendly coding language that would eventually replace LsL. Even Cory was for the idea, but LL wouldn't let anyone do it. Now it's far too late. Sigh.)

[John Mela]

You're welcome, Snoots. Information like this needs to be shared more widely than it is.

Some thoughts on specific points:

is in my mind an ultimate example of really bad coding structure

Absolutely! I only wrote that as a bare-bones snippet to demonstrate the behaviour of = in an if statement. Something like that should never be coded in an actual working script.

The fact that LsL documentation itself has stated that = within a decision structure is a boolean operator makes things that much worse.

Where is that stated? I've not seen that, but I could easily have missed it. This page seems pretty clear and correct.

I suppose a more proper way to write the above would be: if ( b & TRUE) ? Or of course, just: if (b) ...

if (b) is fine, or you could use if (b == TRUE]. No need to use bitwise operators such as & for something this simple.

Poor language design.

Really, LSL isn't particularly to blame for anything here. Sometimes the language makes me beat my head on a hard surface, but in this case its behaviour isn't all that different from other C-like languages. If Linden Lab messed up with LSL, we could come up with plenty of other things to complain about. In particular, it's a language that was designed to be usable by beginners, yet it uses C syntax (which I personally love, but is not for beginners), yet fails to provide so many things that an experienced programmer would expect to see. It's an unhappy alliance between ease of use and power that maybe would have been better achieved by splitting it into two separate languages, as Unity and other platforms have done.

I think all the terse code mania is a holdback from the days when coders were trying to work within a limit of 4k RAM

It's also due to the pride that programmers take in doing the most they can with the least. It's like people who produce intricate carvings in the lead of a pencil, or create an image of Marilyn Monroe using only tiny seashells of various colours - we can appreciate the skill that goes into it for its own sake, but ultimately and practically, it serves no material purpose and was never intended to do so.

ONE timer event?

Ha, yes! The core script in RezMela (bear in mind this is a script which can be reduced in size and complexity no further by splitting without increasing size and complexity with an interface) has TEN completely different timer usages. So the timer duration has to be set at the LCD of all those usages, with integer counts for the frequency of further calls - and, of course, we want the timer to stop completely when not in use by any of them. I could write a lengthy article on timer event sharing alone - but in C# (upon which LSL is based), you just create a new dynamic event for each use.

However, I can understand LL's position, frankly. Yes, it would have been wonderful to have had an easier scripting language for people new to programming, and a more "professional" language for experienced developers ... but LL, like any company, have had to look after their costs and this would have been a much more costly strategy than providing the compromise that we now live with. After all, proportionally very few residents are interested in coding - whatever level that might be - so LL's investments were directed elsewhere.

I had hoped that OpenSim would address this by providing a decently sandboxed C# scripting environment, but that was not to be. Again understandable - that's a massive undertaking for a volunteer organisation. Perhaps its best from a security point of view that neither this nor Region Modules (again, something I had high hopes for) saw the light of day. It's a cruel world out there.

[Tess Juel]

Tess, lol I did have trouble with this. I naturally thought since there were 12 prims that if I linked it second to last (with the root prim being last) that it would turn out to be link 11. But that wasn't the way it turned out, sometimes it came out to be link 2 and sometimes it came out to be link 12. I ended up linking it 3rd to last which made it link 11. It took a lot of trial and error though, I'm lucky it was only 12 prims!

The way to get a predictable link order, is to select the parts one by one but not link anything until you've selected them all. If you do it that way, the first object you selected will have the highest link number, the second one you selected will have the second highest link number etc.

I'm inclined to consider the lack of a linkset sorting function a bug, not just a flaw. Phillip Linden actually went way beyond that; the once said that the biggest mistake LL made when they developed SL was to not include hierarchical linking and that's linkset management quite a few levels higher than a simple listing/sorting function.

The workaround is of course well known to all reasonably experienced scripters: Don't use link number as an identifier unless you are absolutely sure the linkset will never ever be relinked. That works of course but it seriously limits what should have been a very useful LSL/OSL function.

[Snoots Dwagon]

"Where is that stated? I've not seen that, but I could easily have missed it."

Well to be fair, I got into LsL just shortly after SL was set up. (My group was the very first to purchase a non-business private sim.) So a lot of information I read regarding SL was from early days before major parts of the WIKI were updated. Early Wiki contained numerous errors (as would be expected). Stating that = within an IF statement was a boolean operator could have been an early error that had long-standing repercussions. Or I could be mistaken and it was something I read repeatedly on the SL scripting forums. That was a while back. At that time I was still a Ruther dressed in pajamas. : )

One of the things you mentioned was LsL being a C-like language, and you nailed it on the head when you said "it's a language that was designed to be usable by beginners, yet it uses C syntax (which I personally love, but is not for beginners)". Indeed not for beginners. I think LsL was designed by techs for techs, and intended to be used by experienced C coders. I wonder if Phillip or Cory either one ever considered its inevitable use by total newbs.

That's the real issue there. Logically considered, LsL should have been designed to be the easiest-to-use language ever. Considering who would be using it (newbies in virtual environments), what it would be used for (absolutely everything), and the fact that the majority of users / residents would have little or no prior coding experience... they should have never considered C-structure format. (Imagine yourself trying to tackle LsL if you'd never had prior C experience.) They should have used a very plain-language, super-simplified, intelligent-language format.

As an example, why is there no llDoor() function after all these years? Very complex scripts have been written just to open and close a door. Why does the llColor() statement use values of 0 to 1 instead of RGB values of 0 to 255 like the texture window uses? It was simply poorly planned, on so many levels. C was powerful... but never was a friendly language. Which is why they came up with C++, Pascal, Basic, etc etc. (To be honest, one of the best languages I ever used was the QuickBASIC compiler... which had the foundation of a true-English coding language that tried to get away from techno-babble computer language concepts. It just needed better foundation design.)

Of course we could go on and on about the poorly-designed nature of computer languages. Cory Linden (the designer of LsL) stated more than once that he "designed LsL in one day" and would never do such a thing again. He was under pressure to get it working, get SL up and running, and was probably living on caffeine.

I'm just ranting here of course. Blame that on years of having to deal with LsL, core system bugs, and the "logic" we've discussed here. But wouldn't it be nice to have a virtual coding language full of statement such as:

Door(degrees,speed)

BTW, I did realize you were using the b=TRUE as a bad example... and I appreciate that. It was a very effective bad example that had my jaw hitting the table. Since I've always used advanced intelligent coding languages (that could internally discern whether = was being used as an IF parameter or a variable assignment)... I'd never seen such a goofy coding structure. Was a real eye-opener... and explains a LOT about daily issues with virtual worlds.

[Snoots Dwagon]

Now here is something that further confuses the issue. Look at this modification of your script John:

Code: Select all

integer b;

default{

touch_start(integer a){
b = FALSE;
if (b = TRUE) { llOwnerSay("TRUE!"); }

b=TRUE;
if(b = FALSE) { llOwnerSay("FALSE!"); }

}
}

When this is run, it says TRUE! But the "reverse" logic doesn't say false.

I know why it does this... and of course C is a widely-used language (as is LsL). But this is visibly bad logic design. For beginning coders I'd simply tell them, "Never use = within a decision parameter." There are more sensible ways to do it.

So my newly-formed rule of thumb (which I've used for years in LsL anyway):
Always use == within decision parameters.
Outside of decision parameters use =.

Keeping the two completely separated would seem the smart way to code. Do you agree, or are there other things to consider? Because this whole ball of wax now has me truly curious. ;D