Can you build successfully without knowing LSL?

I'm one of those who likes to do everything themselves. That way, it works exactly like I want. There's a long list of problems when you bring someone else into the fold.

I beg to differ

Even monkies can build stuffs out of wooden cubes...

LSL = Linden Script Language ? And, yes, it's definitely about as fun as having a root canal. I was semi-joking about it being play. Don't worry about me wasting any Single Malt. I only sip a nightcap neat on special occasions.

Well, I must say I've gotten some very mixed opinions on this thread. And it's split down the middle. Interesting.

Do Not Learn Perl if you want to apply what you learn to anything else.

I would suggest Javascript and a Lisp-family language like Lisp, Scheme, or Tcl.

I would go with alien speak - done with a lisp by a nearsighted, four eyed, myopic deaf alien... - oh yeah, with a penchant for speaking in tongues...

/me waves frantically at Amar. Good to see you posting!

Argent: I think TCL is a good analog to LSL. I hope you mentioned Lisp in jest - is recursion really required when turning on a light in SL? *smiles*

Actually, though, all these languages we've suggested are more complex than LSL, which is really very simple. So Weston, my real advice, if you're going to learn it, just do the tutorials and ask questions in Scripting Tips. Or go to the horse's mouth and send Qie a lot of IMs and a box of chocolates!

If you are a talented builder, you could do without scripting knowledge. Many scripts you can buy, or have others create them for you.

Knowing how to script can add value to your products though. One of the strong points in my furniture for example, is that I have written my own menu for it. Anyone can (re)create the chairs, but they do not have the implemented menu.

But lets say you like building houses, most if not all scripts for that are already done, and some darn good ones. Spending a few thousand on that, and do not bother with it if you dislike scripting.

Good luck!

wow learning to script was key to me taking the next step in my sales in SL.

When we started we had maternity clothing.The I mapped out theme shops ,neko,vamp so on.
Still good sales,but I wanted to make this worth the time.
I sat down with a few full perm scripts and sl wiki on my laptop.
then i just looked up ever function i could find.I used the wiki site and full perm scripts as learning tools for months.
I made a talking tummy,basic simple chat a few lil effects.Nothing huge.
Then a simple baby (god i hope those are still not out there) I added holds and lil sounds.Still just basic designs.

a year later i just finished a talking tummy with customs animations ( yes,you have to learn that next to really have fun) a smart system that walks the user threw all the functions and high lights every button with a OwnerSay explanation of each step of their maternity.It chats off multi notecards with settings for timer and language controls.
Fully interactive with people and food the mother eats threw her cycle .
I added things like baby talk,where you can make the tummy speak in his ir hers given name by the parents.
due date timers that do not fail and a system that looks for hang ups in the timing and resets on region changes.
my new babies about to be out had add on clothing huds and just a ton of new things I am making.
Take the time,learn the scripting!! It will make you so happy to bring your designs to life in SL.
and yes it can improve your sales!
But in the end sales are great but I think being able to make what you want and work the way you want is a huge personal win!!
I love SL and building!!!
Learn it all!!!!!

The issue I had with most other people's scripts (for sale or otherwise) is that most of the scripts are bloated, poorly written and/or laggy etc. I have bought or taken as freebies scripts that are Frankensteined (excellent term, by the way) with unnecessary code in them.

I only know enough about scripting to recognize these issues, not always to repair and improve them.

I am fortunate to have someone who has created some bang up custom scripts for me that are low lag -- she is the most anal retentive scripter I know in that regard, so that works well for me. But she is not always available.

For those things I've really needed, I have searched out and investigated as thoroughly as possible the lowest lag/best for me script to perform a certain task. I do not mind paying for scripts, but they must be well written.

The script will also reflect on my products, so if I'm not entirely happy with the script, I doubt my customers will be either. I'd rather have no script than a bad one in my items and while that may detract from its features, I'd rather charge less for something non-scripted than give my customers a poor experience.

Good luck!

What kind of scripts are you looking for Weston?

Honestly the 'quick' way is to go over to Yadni's, and buy a couple hundred simple scripts for $L 2 or $L 3 or whatever it is. Get the oooold stuff. Yeah. The old simple junk from 2004/5 if you can.

Then go through and look at each one. That will stick about 70 or 80 ideas of "what is easily possible" in your head.

Then later, when you need a script that "makes a particle" or "opens a door this or that way" or whatever, there's a reaaaally good chance you'll remember the simple script that did close to it. After some rummaging, you'll be able to find it and maybe poke the script to change a color, or the timing, or whatever you need.

It sounds stupid, but it's a bit like discovering dad's toolbox as a kid. You don't know you are gonna need pliers when you first see them, but when you run into a problem needing pliers, it's good that you saw them in the box and know they exist

/me waves back @ Nika and Czari - still around, just not as much

i can't build anything today..i have 4 prims 5 meters away from the center point and they won't link..maybe a script would help

i probably have some stupid thing checked or unchecked..who the hell knows anymore..
there is a skill to just figuring out if it was me or if it was LL or if it is just lag or the software..
lol

Ceka, I would respond but i am still terrified of the panther in your sig.

THIS I would stand a better chance of understanding.

Qie has already been very generous to me with help on scripted things. I could not impose again.

This is a good compromise approach that may work for me. All I really want to do is move some prims slowly (I mean almost imperceptably slowly) and change their size, have them shrink and grow. Embarrassingly simple stuff. But most scripts are about opening doors or camping or spying on people.

I have a lot of great options it seems. Now I just need to make time!

// Moving a prim (or bunch of linked prims) by 1 meter in the X direction
// ============================================

vector position; // where you are

default
{
state_entry()
{
llSay(0, "Hello, Avatar!";
}

touch_start(integer total_number)
{
llSay(0, "Touched.";

position = llGetPos();
position.x = position.x + 1;
llSetPos(position);
}
}



// Growing a prim. Start with a .5 meter cube
// ============================================

default
{
state_entry()
{
llSay(0, "Hello, Avatar!";
}

touch_start(integer total_number)
{
llSay(0, "Touched.";
llSetScale(<10, 10, 10>; // grows to a 10m prim on touch. Stand back!
}
}



As you can see, I've just added a few lines to the default "Hello Avatar" script for both of these.

Neither have been tested, generally my scripts work on the first shot but if there's a bug, generally some overly anxious scripty type will write a ridiculously huge treatise about how the script is wrong, and how they've done it better, and how they have also sorted out some Obscure Problem, Jira #OMGWTFBBQ111, by doing it their way.

I've spent decades doing software professionally, been out of it for years, and looking back I see it as something ridiculously overrated as a skill. Cooking a decent fluffy dessert pastry, or aligning a close~fitting door so it doesn't jam in a few years, is far harder.

Minor cavil: in vectors -- the stuff in < these brackets > that LSL uses for positions and colours and so on -- you're supposed to put floating point numbers rather than integers; that is, < 10.0, 10.0, 10.0 > . Similarly, in the first example, you're adding 1.0 to the x value of position.

It still works fine if you leave out the decimal points, but only because, behind the scenes, every time the script executes, the sim comes to what looks like an integer, thinks, "What's this? I'm expecting a float here, not an integer; oh well, I guess he just forgot to put the decimal point in, so I'll assume that he meant 10.0" and treats it as a float.

In itself it's not a huge deal, but each time that happens it takes the sim some time to figure out what you mean and to fix what it sees as the problem, so it all contributes to server-side lag, completely unnecessarily.

It's a nuisance, but actually writing floating point numbers as floating point numbers and integers as integers is a good habit to get into.

Then impose on me next time. For simple things I do not mind one bit and I enjoy writing a quick script to help someone out.

As this is compiled code, lexical analysis and parsing generally happens at compile time, and all that is sorted out before the p code is even translated to native machine code. Meaning there shouldn't be any runtime lag due to it at all; in fact in some really high end compilers (which the LSL compiler probably isn't) ~ good optimisation passes will use integer methods in place of float wherever they can, and you'll pick up tons of speed by not specifying floats.

I suppose LSL could theoretically be botched in such a way that what you describe could happen, but I'd doubt it. A junior level computer science major would write a compiler that is more efficient than that. What you are talking about generally does happen with purely interpreted languages.

It is, however, a good habit I suppose to write out 10 as 10.0 when it comes to floats. It's all good

The LSL compiler does no optimization at all, other than some very simple optimization at the global level, so a global "vector size = <10,10,10>;" is the same as "vector size = <10.0,10.0,10.0>", but otherwise it's actually doing the equivalent of "push 10; int2float; push 10; int2float; push 10; int2float; float2vector;" every time. Whether it's Mono or LSL... the only optimization is Mono's peephole optimizer in the JIT code generator.

Oh my god.

Someone oughta take on LSL for their senior college project or something.

I'm going by the LSL wiki, which says,
But if you tell the wiki is mistaken in this, that won't be the first time I've been misled by it.

I did some work on optimizing it, and they did pick up part of it, but I didn't have time to really do a proper parse tree optimizer and they decided not to pick up the incomplete work I'd done on optimizing in the yacc source. Which was probably the right decision.

There are some odd decisions in the code generation too... right to left evaluation of subexpressions is not something I've seen outside of APL, for example... but it's not a bad job and really not inappropriate for the intended goals. The p-code interpreter itself is quite well done, for a pure interpreter. It satisfies the requirements. I would rather they applied their efforts to extending the runtime than fiddling with the language or the compiler.

Well, I'd put a lot of stock in what Argent just described. Insofar as global declarations get optimised and everything else doesn't.

Converting integers to float isn't exactly a demanding operation, it would take ridiculous amounts of that to lag a region noticeably, but the fact that LSL works that way pretty much puts it in the realm of "someone's cool project" rather than typical compiler territory.

I had no idea it was that... I won't use the word "bad" I'll use the word "simple."

Could be that I'm just used to my old industry, which was embedded firmware. Products with embedded firmware can be highly cost sensitive due to consumer pricing of electronics, so compiler optimisation was always a huge deal. The more you could squeeze out of some ridiculously underpowered cheap processor with not enough memory, the better.

I just call a scripter and pose my problem to him, while batting my eyes and looking cute and helpless. Which is easy, because when it comes to LSL, I *am*.

Yeah, it's brutal to get anyone to pick up a project sometimes. Most people would rather work from scratch for a week, than follow someone else's line of reasoning for more than ten minutes.

All things considered, LSL's got remarkably few bugs for what it is, but that may have more to do with the hordes of unwitting testers than anything else...

Me too. Polyforth and PL/M-80 and 4- and 8- bit CPUs with, if you're lucky, 4k-16k of RAM. Compiled languages? We had no such honor-sapping luxuries!