Where can I learn how to LSL Script?

[thatshowigetmyvibes]

So I'm pretty new to SL, not new to programming, however I am rusty. I'd like a beginner trial on how to learn LSL? (what language is it?) scripting. To me the scripting looks like Java, kind of. The logic seems all the same however I'd like to learn from a basic level all over again. I hope someone can help me ❤️

 

Love you all thank you for caring ❤️ (also i hope I posted in the correct topic)

[sandi Mexicola]

LSL is a state-based programming language, which threw me at first.  

I imagine you likely found this site already: http://wiki.secondlife.com/wiki/LSL_Portal.  There are a lot of good examples there.  

There are scripting groups online.  Classes too (I think).  If I find more information before anyone else does, I'll try to remember to post here.  🙂

[Rolig Loon]

As Sandi says, there are very basic tutorials in the wiki to get you started.  They won't take you very far, though. If you have any experience in another computing language, you will find it fairly easy to pick up LSL by looking at example scripts that are peppered all through the Functions pages in the wiki (and  of course in the Examples tab as well).  Just start dissecting them, modifying things gently to see what happens.  That's how most of us learned, in fact.  As Sandi said, the greatest challenge will probably not be the various functions but the logical structure of the language. 

Unlike most languages you are likely to have used, execution does not proceed linearly in LSL.  That is, it does not start at the top of a script and follow along a path until you reach the bottom.  Execution in LSL is situational. A script is divided into states and events, any of which can be an entry point for a block of instructions.  A script waits, idling, until some external stimulus (a mouse click, a sensor, a received message ... ) triggers it to begin executing the operations in a specific event.  The script then executes those specific operations and either passes execution to another event or state, or it goes back to waiting for another trigger.  It can take a little while to adjust to thinking this way, but it's quite logical.

Again, the best way to learn LSL is probably to just tinker with scripts that already do something interesting.  If you run into tight corners and need help, post a question and a snippet of your code here in the forum.  We don't generally post complete scripts except as examples, but we enjoy trying to suggest ways to solve tricky problems (or work around them, anyway). We learn from each other.

[Istelathis]

I learned mostly by tinkering with scripts I found on outworldz, trying to make them work in SL.  Mind you, these are for opensim, so it does not always work in SL but that is kind of a good thing, it sets you on your way to learning how it works in Second Life.

https://www.outworldz.com/cgi/freescripts.plx

You can find some on the market place as well, in fact that would probably be your best bet - but when you can't find what you are looking for the above link has a ton of different scripts you can look over and try.

[animats]

Yes. The language is trivial. It's the interaction with the world that's complicated.

The main thing to realize about doing things to the world from LSL is that you're not running the world. You get to ask to do things to it. You can tell an object to move, and it usually will. But you can't be sure. Someone might be editing it from a viewer. If it's physical, it might hit something and be stopped. It might hit a ban line and be stopped. It might try to go off the edge of the world or into an offline sim. Some kinds of movement commands are approximate, not exact.

The other big thing to realize is that doing things takes time. Many LSL calls return before the requested action is complete. Rezzing objects, in particular, can be slow. Moving objects is not instantaneous. Even things like color changes have a visible delay before they appear in the viewer, because a network message has to go out to the viewer.

So you have to view LSL commands like robotics. You issue a command, and you check later to see what happened.

[sandi Mexicola]

In the past, script events that were set to run immediately when the object containing the script was rezzed did so.  

It seems now there is a variable and up to 2 second delay after an object is rezzed before a script will do anything.  I consider this a bug, but it's been a bug for a long time. 

[Quistess Alpha]

Like @sandi Mexicola said I would recommend skimming the LSL wiki, and maybe just try and see if you can figure out some simple projects without looking up a complete answer (light-bulbs, sliding doors, moving platforms etc. might be decent starting places.)

My recommended reading order for the wiki if you want to try skimming it:

1. http://wiki.secondlife.com/wiki/Category:LSL_Types and the category pages for integers, floats, strings, keys, rotations and lists. Most of the types are similar to other languages, but keys and rotations are a tad specific to LSL as far as basic types go, and lists aren't as fully-featured as they are in other languages.
2. http://wiki.secondlife.com/wiki/LSL_Operators pretty basic, and you don't need to 100% understand binary operations to do most things in LSL, but they come in handy more often than you'd think.
3. http://wiki.secondlife.com/wiki/Category:LSL_Flow_Control sub pages. usually you won't need to use loops unless you're dealing with a list, and these should be very familiar to anyone with other language experience.
4. http://wiki.secondlife.com/wiki/Category:LSL_Events the most common events for things I do are touch_start() touch_end(), timer() and listen(). Most of the other events are fairly specific to some functionality, but it's often useful to have a general idea of what entry points exist. You might also want to pay specific attention to the changed() event, as it's basically a catch-all for specific things that aren't important enough to get their own event.
5. http://wiki.secondlife.com/wiki/Category:LSL_Functions There are a lot of built-in functions in LSL, sort of like a standard library in other languages, but LSL has no concept of libraries, these are the functions you get unless you write them yourself or look up some user-written ones to add to your script. rather than reading through them all, it's easier and more practical to just consult the list when it seems reasonable that there's a thing you should be able to do with a function. a really good function to get familiar with off the bat though is llSetLinkPrimitiveParamsFast. (often abbreviated llSLPPF) it's a big multi-function that makes a fair number of other functions redundant.

Edited December 3, 2021 by Quistess Alpha
spellcheck

[Coffee Pancake]

The best way to learn LSL is to have a problem to solve. Find something you need and see if you can make it yourself.

[Quistess Alpha]

5 minutes ago, Coffee Pancake said:

The best way to learn LSL is to have a problem to solve. Find something you need and see if you can make it yourself.

100% agreed, although, figuring the difference between what's easy and what's hard or basically impossible is an acquired skill. Finding a good balance between putting in enough effort on a thing to actually see a project or two through, and not being so stubborn that you pursue an impossible project forever isn't quite as trivial as it seems.

[Rolig Loon]

2 minutes ago, Quistess Alpha said:

15 minutes ago, Coffee Pancake said:

The best way to learn LSL is to have a problem to solve. Find something you need and see if you can make it yourself.

100% agreed, although, figuring the difference between what's easy and what's hard or basically impossible is an acquired skill. Finding a good balance between putting in enough effort on a thing to actually see a project or two through, and not being so stubborn that you pursue an impossible project forever isn't quite as trivial as it seems.

As with many new skills you learn in life, you will have to balance impatience with caution.  Both can slow your progress.  If you try to rush things by trying a project that is well over your head, you'll get frustrated and give up before you give yourself a fair chance. If you resist moving ahead until you understand everything, though, you'll never make it past baby steps.  My version of Tessa's advice is to aim first for projects that don't involve a lot of steps or ones that can be easily modularized. Deal with chunks until you get enough of them in your head to start making more complex scripts out of them.  So, for example, make an object move before you worry about changing its appearance, making a noise, or launching a newly-rezzed object from it as it moves.  Most of the short examples in the Functions pages of the wiki satisfy that requirement.

[Profaitchikenz Haiku]

If you substitute "challenge" for "problem" then I think you've got the best situation for a learner.

Problems are as Sandy described - an unknown delay after rezzing an object before you cn get reliable communications with it.

A challenge is "Make this prim circle around your head emitting particles so that you have a halo"

The problem one is tiresome and you don't learn so much as plod doggedly on trying one thing after another.

The challenge one is fun, and the only tough part of it is rotations

ETA, as usualy, Rolig pipped me to the post  what she said...

Edited December 3, 2021 by Profaitchikenz Haiku

[Rolig Loon]

Thinking further about my comment above, I should mention the obvious ... every scripter I know has a collection of code snippets that work. We write some of them and steal others. When we sit down to write a new script, we turn to the collection for bits that we can cut/paste into the new work. After all, why reinvent the wheel if you have one that already works? For example, I no longer write a multipage dialog routine from scratch, or a routine to make a door open slowly.  If you dig around in the Script Library here in the forums, or if you look in the sticky threads in this Scripting forum, you'll find that we have contributed many of those snippets or short routines for shared use. I suggest starting your own collections and squirreling them away in inventory.

[sandi Mexicola]

3 hours ago, Quistess Alpha said:

100% agreed, although, figuring the difference between what's easy and what's hard or basically impossible is an acquired skill. Finding a good balance between putting in enough effort on a thing to actually see a project or two through, and not being so stubborn that you pursue an impossible project forever isn't quite as trivial as it seems.

nowwww u tell me, lol!

 

[Lucia Nightfire]

7 hours ago, Rolig Loon said:

Thinking further about my comment above, I should mention the obvious ... every scripter I know has a collection of code snippets that work. We write some of them and steal others. When we sit down to write a new script, we turn to the collection for bits that we can cut/paste into the new work. After all, why reinvent the wheel if you have one that already works? For example, I no longer write a multipage dialog routine from scratch, or a routine to make a door open slowly.  If you dig around in the Script Library here in the forums, or if you look in the sticky threads in this Scripting forum, you'll find that we have contributed many of those snippets or short routines for shared use. I suggest starting your own collections and squirreling them away in inventory.

Even with saved snippets, I occasionally challenge myself to reproduce them from scratch as there is the slim chance that I might find a slightly better or more efficient method or means.

[IvyTechEngineer]

I was watching a YouTube video entitled "Second Life: Download Scripts from Script Library" but I don't know if the library was on the National University Island or did Dr Taylor get the scripts from somewhere else. I wonder if Rockcliffe has free scripts available? I think he found or bought some scripts and placed them in what he called the "Teachers Tool Shed". Can't seem to find the island now maybe it is private or has been moved or renamed. 

) 

[Rolig Loon]

I remember that place, many many years ago.  If I recall correctly, the scripts it had were like the ones in that photo: very simple things no more than a dozen lines long and copied mostly from examples in the LSL wiki.

[Profaitchikenz Haiku]

I believe Builders Brewery run scripting courses from time to time.

[Quistess Alpha]

3 minutes ago, Profaitchikenz Haiku said:

I believe Builders Brewery run scripting courses from time to time.

They do, and maybe the class or two I went to wasn't representative, but I think generally they just walk you line-by-line through a pre-written script that demonstrates a certain feature (like listeners or the dataserver event). Certainly classes like that might be quite helpful if you're starting from absolutely no knowledge of LSL or other imperative programming languages, but nobody should expect to take their classes and come out knowing everything there is to know about scripting or LSL.

[Profaitchikenz Haiku]

9 minutes ago, Quistess Alpha said:

but nobody should expect to take their classes and come out knowing everything there is to know about scripting or LSL.

Is there anybody who could claim to know all and everything about LSL and be believed? (Kruger-Dunning jibes aside)

[Quistess Alpha]

29 minutes ago, Profaitchikenz Haiku said:

Is there anybody who could claim to know all and everything about LSL and be believed?

Of course not, although I suppose what I was getting at is that there's a big difference between being able to read and being able to write; you could argue that being able to read what someone else's script does at a basic level* is a good stepping stone to writing your own scripts, but actually learning to solve problems on your own is a distinctly different skill, and hard to teach directly. Almost everyone can read a novel; far fewer can write them.

* as scripts get increasingly complex, figuring out how they work and following their control-flow actually becomes a rather separate skill from scripting itself. The recent examination of a specific script for 'realistic animal movement' is a fine example. Reading a script at a 'what does it do?' level is easy; figuring out 'why does it do that?' and 'how can I change it to do what ~I want it to do?' can be very difficult without the original author to consult.

Edited December 9, 2021 by Quistess Alpha

[Rolig Loon]

35 minutes ago, Quistess Alpha said:

Reading a script at a 'what does it do?' level is easy; figuring out 'why does it do that?' and 'how can I change it to do what ~I want it to do?' can be very difficult without the original author to consult.

That's why the heart of scripting is not the grammar and syntax of whatever language you choose to script with, but logic.  As we see over and over again in questions that come to this forum, it's fairly easy to figure out what the various LSL functions do -- the LSL wiki is a remarkably good resource for that -- but it takes patience, insight, and a logical mind to think through the sequence of steps that make a script do what you want it to. For some types of scripts (those involving movement, in particular) it helps to be comfortable with expressing those logical steps mathematically. All of those qualities are hard to learn and significantly harder to teach.

[sandi Mexicola]

3 hours ago, Quistess Alpha said:

Almost everyone can read a novel; far fewer can write them.

👍

[Anna Salyx]

On 12/3/2021 at 4:25 PM, Rolig Loon said:

 .. I suggest starting your own collections and squirreling them away in inventory.

All good comment, but just on the last part, I loose things in my inventory, especially code fragments.  So I squirrel things into OneNote.  Much easier to organize better able to see and copy/paste w/out having to actually open up [script] files.  So that's my tip contribution: use an external note program that you can see the contents of the notes easily at a glance, all organized into categories.... if possible.