Need help learning scripts.

So I'm a programmer, which puts me right at home in a game like SL, but the problem is when I look at the code used here... OMG, it's like nothing I've ever used before, and I'm totally lost. So what I need is just a good tutorial to help me learn SLL so I can get better at coding at my own objects.

I'm already OK at modeling here. Can't say it's easy in this environment though. If possible, could someone also help me with sculpted prims?

OK, that's all I need. Thanks to anyone who can help.

Have you looked in the scripting forum? I believe some knowledgeable people post there.

May I suggest the College of scripting, music and science, an excellent place with self-study tutorials as well as books and classes:

College of scripting, music and science (it is located in Horsa)

The tutorials are easy to read and follow, and the place is easy to navigate (my opinion, anyway).

This is probably a good place to start...

http://lslwiki.net/lslwiki/wakka.php?wakka=HomePage

Look under the Getting Started section for links to tutorials, etc.

Check out the LsL Portal @ http://wiki.secondlife.com/wiki/LSL_Portal

Most definitely check out all of the excellent suggestions from the above posters... Also, check out the in-world classes that are on offer..... I did attend one scripting class for beginners but I'm afraid that even that was way out of my depth. But since you've mentioned that you're already a programmer, it should be as much of a problem for you as it was for me...

Its actually a pretty easy language to pick up (if you're already a programmer), its a somewhat limited event-driven scripting language. Start with the tutorials on the wiki (except the vehicle one - NO ONE understands vehicle scripting except for a fortunate few). Do a basic "hello, world" script, then read through the events and toss debugging messages into some events to see when they fire off. From there you can play around with the various data types and run through some of the basic functions for them. Once you're comfortable with those, look at lists, and then the permissions system (work through a basic poseball script, and don't be embarassed if you don't pick it up right away - you'll need to throw in a lot of debugging statements to understand how it works).

From there, start reading other scripts for comprehension.

You're going to run into some pretty basic limitations, particularly concerning the user interface and there are NO compound datatypes (records, etc) ... its basically a toy language. HTML and EMail interfaces are also very limited. No database access or writeable data areas (except for some kludges), so for anything with real persistance and data storage people end up writing PHP interfaces to MySQL as a back end.

I highly recommend joining the Friends of Second Life group, which is devoted to announcing scripting classes taught by Simon Kline. Simon is outstanding and usually holds two classes each week. He is open to questions during those class sessions.

If you're interested in a book, "Scripting Your World: The Official Guide to Second Life Scripting" was published in Sept. 2008.

Free hint:
don't start with particles, vehicles, guns, or networked vendors...

... unless you already have some coding experience (preferable in event driven models) and LIKE pain =)

for novices I reccomend starting with simple items, sit telepoters, TP huds, data manipulators (simple calculators), av greeters/loggers, and such... stay away from physics stuff to start

oh and definately learn the build tools.

when you dive into particles go to the particle laboratory in world, IIRC they have some info for useful build tutorials as well. I've yet to see anywhere that's really good for physics, vehicles, or networked item tutorials, so best of luck there

the scripting forums (listed above) and the wiki are your friends
https://wiki.secondlife.com/wiki/LSL_Portal

Particles aren't hard to *program*. They just require setting up a lot of parameters, which can be difficult to visualize the end result of, and they are a mite touchy over typos since you just give one long, un-validated list as parameters.

I always start with this skeleton script when building a particle effect, going through each parameter and adjusting it to something reasonable, and then fine-tune from there.

http://talirosca.wikidot.com/particle-script

It's nothing like the programming languages I have learnt either - in fact it seems more like writing sets of macros than anything else, to my way of thinking.

Don't think "structured" - think object oriented and state transitions. I've been told LSL is similar to C++, if that is any help to you.

You could try the texturing and building fora for sculpted prims - and I remember Torley did a vidtut on sculpties too.

C++ is not a good comparison. There are obvious traces of the C syntax in LSL (as in a lot of other modern languages), but none of the object-orientation of C++, nor the direct access C grants you.

It is "object-oriented" in the very literal sense that it's purpose is to define the behavior of objects/prims in the SL world, and as such you can see a prim and it's properties and script as one object, with the script only defining the methods while the prim defines the data, but that's a somewhat philosophical approach, really.

It is, as has been mentioned, on a higher level events-driven, much like normal GUI programming, but the code which runs inside those events is very classically procedural, and somewhat simplistic in it's structures, compared to many languages.
It has one rather unique concept in "states", but it is somewhat specialized, and many scripts have no need of it. States are pretty much exactly that, a new state an object shifts into, with a new set of behavior (as defined by the event handlers in that state).

I must admit, if you say you're a programmer, I am surprised you claim that LSL is nothing like anything you've ever seen before. Which languages are you used to?
The only "trick" is to recognize that your code is always event driven, triggered by external events (like, say, a touch) which fires specific, pre-defined event handlers (e.g. touch_start(integer i){}). From there it's purely procedural code.
-And learning all the llSomething calls to interact with the world, of course, but that is no different than learning, say, the IO libraries of a specific language. That's mostly a matter of recognizing "there ought to be a function which can manipulate this aspect of the world", and then go hunt it down.

ETA: As has been mentioned, definitely take a look at http://lslwiki.net/lslwiki/wakka.php?wakka=LSLTutorials . It is a really good and quick introduction to LSL scripting.

Yeah, and I'd suggest avoiding states until one has a fair grasp of event handling in LSL. There are some "gotchas" in states that will just seem diabolical at first-- they're actually useful, but not likely to make sense right away.

Another thing that trips up LSL learners is rotations. Unless "quaternion" is a familiar notation, or one is a compulsive geometer, any combined rotations might best be avoided for the first script or two, just to avoid frustration. These things aren't that mysterious (except for a built-in bug that everyone encounters eventually), and at some point it all just "clicks", but... well, I think about 1/3 of the posts to Scripting Tips are problems with rotations, one way or another.

Oh, and as for sculpted prims.... think of them as a mesh which at the beginning has all it's vertices bunched up at 0,0,0.
Each pixel in the sculpt map is not a color but a vertex in this mesh, with the color values acting as coordinates to offset the vertex from the origin. The red channel carries the X axis, green Y and blue Z. Using an image is just a practical, if somewhat roundabout, way to carry these coordinates.
There's additionally some issues about how you wrap this mesh in 3D; whether (and how) edges meet to form a shape with volume or is a flat plane, but that is polish on top of this basic principle.
This explanation may either click for you, or make *no* sense at all; it's how I wrap my brain around sculpts.
In any case, take a look at SculptyPaint, http://www.xs4all.nl/~elout/sculptpaint/ . It is one of the easiest ways to play around with sculpts and see what the maps look like and and what you can do with them.
And it is in fact a quite powerful tool for making sculpts practically, unless you need the full mesh modelling of something like Maya or Blender. Highly recommended!

the best way to think of states is a collection of events that you WILL pay attention to, (to the tune of the old mounds/almond joy jingle) o/ sometimes you want to be touched... sometimes you don't... =)

never said particles were especially hard, just nerve wracking for the beginner =)

Howard, thanks for this post. I found this very helpful!
Thanks again!

Zena

The most immediate and practical use for states is that you can read a notecard into memory without having other events get in the way - typically you'll want the default state to only be focused on reading the notecard and then switch to an active state that responds to other events (or have the default state go into a state that performs the read, but I think the first is more straightforward).

well I suppose that's a variation on my baisc usage, e.g. turning of input sources to reduce changes in input variables (or clearing all listens cheaply)... I suppose between clearing listens and reading notecards, thoseare definitately the top immediate uses for states. there are however times you want to run those things side by side, and still others when you just want to completely change the behavior

Or in the more general sense, switching between a "configuration/administrative" mode, doing setup like reading notecards or sequences of dialogs, and a "running" mode for the actual everyday functionality.
Practically, different variations of operation often need to share so much functionality that it is easier to check a status flag than to spread it between states and having to duplicate code (literally or through function calls). But sometimes you really do switch between drastically different behavior, and in those cases states are a really elegant way to do it.

I find I use states a lot more since the introduction of llSetClickAction(). (Come to think of it, I suppose that says something about the kind of lame scripts I'm writing these days. )

Right, status flags and switching states are often interchangable ways of doing the same thing. The benefit of state switching is when you have a lot of other events enabled you can exceed the event queue stack and lose data, or have a physical object behave unexpectedly while you're still uploading and setting various parameters for it.

Also (and this is my main reason for posting) by "reading a notecard" that doesn't usually mean we're reading a Shakesperian sonnet or an inventory list - mostly notecards are used for holding configuration information in so far as scripting usage is involved.