For begining and intermediate scripters- what confuses you the most?

Hello begining and intermediate scripters: what part(s) of scripting do you find most confusing? Why? I'm curious if the same things that stump me stump others. This isn't so much as to complain but as to identify "trouble spots" Perhaps if problem areas are identified, more knowlegable scripters can help us fill in the gaps.*


Complex scripts- most of my stuff is simple: Float up and Float down. Recite something random from a list when clicked. Big wow. I'm not sure where to start when it comes to objects that do anything more complicated.

The wiki (and the scripting boards) are great, but sometimes they seem to assume the reader knows a bit more than s/he actually does.


*By this I do not mean handing out complete scripts for free or doing the hard part for us... or holding our hand through every step. I want to learn how to do this stuff, but I keep hitting dead ends.

p.s. to moderator- this is in the gerneral forum (as opposed to the scripting one) because I figure that people who have had limited success with LSL are less likely to look there.

Hey I can actually participate in this thread as I just started a scripting project!

My issues tend to be more conceptual. Problem solving in general, like "how would I go about doing THIS". Once I got a general idea and a list of functions I will need, I'm fine.

Also, my lack of familiarity with LSL's features usually means I will spend all night solving a problem, only to have someone tell me "You didn't have to go through all that trouble...LSL has a function that does it in one line"

How to even begin.

coco

With a pre-existing script and the Wiki, I can generally mod something to a good extent. (M. Sojourner's free lockable door script is a good example - I now have versions of that script that will work as a trapdoor, sliding glass door, etc.)

But making a script from scratch boggles my mind. State default? What about the other states? Where do they come in?

I can't seem to wrap my mind around how to properly set up a script. I can find the commands that I will need in the script, but no idea how to put them in properly - I'm always getting syntax errors.

I think what would help me is if someone was able to set up a framework for a script (with translations into english for each part) where I would then "drop in" my functional bits of code that make the thing work. If that's possible. At least then I would be able to study that part aside from the bits that make the script work.

After my first "basic basic scripting" class, I was no longer "confused" so much. Though I went into that class with the same question Cocoanut asked above. Since that one class, I figured out how to make a door swing the opposite direction than it was swinging. And that's pretty much it. hehe

I think what is "confusing" to me most, is where the commands are for the most basic scripts that people use. When I taught myself HTML 1.0 (back then.. hehe).. I had the basic code and had to teach myself the filler. Once I knew how a few functions worked, I was able to see the "harder" stuff that people added.

I think if there were a way to color code scripts, or at the very least if those teaching scripting did a step by step "this is what happens next" type thing, it would be much easier. Even for those of us used to looking at similar things.

If I could see how some of the more basic stuff was done/laid out/created, I would be more likely to take it to heart and figure out the harder stuff.

My thoughts!

Alright, I would probably qualify as a "pre-beginning" scripter. I have some programming experience in other languages prior to SL and I've printed off the list of LSL functions from Wiki, but I haven't actually attempted to do anything yet.

What I have found in the past was this: Familiarity with functions comes in 1/10th part from actually reading the functions manual, another 4/10th from taking apart and playing with example work from others and 5/10th from having a real application need. That's the real key - knowing what you want to do first.

Second, *any* new programming language is going to be confusing at first. (Speaking here from Clipper, Pascal, Basic, C, C++, Java, SQL, VBA experience). Don't let it daunt you, because it's like riding a bicycle. After skinning the crap out of your knees a few times, you figure out how to keep going forward instead of falling down.

All that said, what I want to know is this: how do I make those pretty particle effects?

i actually got reasonably good at VBA (not just macros, but creating classes, objects, methods, error handling, etc) as a scripting language, but I have a **great** deal of trouble with LSL. I am always getting syntax errors. I don't think i've created a script yet that worked the first time. I hack at the wiki, usually to no avail, pull out my hair, and then usually have to come begging to various friends for insight.

The wiki is designed by engineers for engineers, unfortunately, and assumes a lot of knowledge. Not surprising that this is so, I guess.

topics to cover: how LSL's if...then...else works, using timers, states and events, the difference between = and ==, dealing with variable types (if you need to convert a number to a string etc), and key functions like llMessageLinked.

After literally *hours* of scouring the LSL Wiki, I feel pretty comfortable with different functions of LSL and what they can do, how to feed them arguments, that sort of thing.

Some things that *really* throw me off, though:

- Script events (on_rez, attach, etc)
- How to use the output/results of one LSL function as part of an argument for another
- Lists

Plenty of other things, too, but those are some real headscratchers.

I'd characterize my scripting knowledge as very basic. I can adapt sample scripts to do more interesting things depending on my needs, I can construct simple scripts to do simple things. Anything with the complexity of a commercial product, though, is beyond my grasp at the moment.

"Alright, I would probably qualify as a "pre-beginning" scripter. I have some programming experience in other languages prior to SL and I've printed off the list of LSL functions from Wiki, but I haven't actually attempted to do anything yet."

If you are a "pre-beginning" scripter, then I am a Pre-pre-pre-pre beginner. I have no programming experience in ANY language.

Needless to say, I need a bottoms up teaching by a good teacher - or, something written down that does the same thing. The Wiki is of course useless for me.

I did manage to build and program a door by taking one apart and working at it, but I forgotten how now. Also, when you are having to teach yourself by trial and error, half the time things that worked before now don't work, and you have absolutely no reason why.

I HATE HAVING TO TEACH MYSELF SCRIPTING WITH NO MANUAL.

coco

I learned what little I know about LSL through reverse-engineering other scripts using the LSL wiki. I'm good at that sort of thing, though -- I've been picking apart problems and user interfaces and broken machinery since I was a tike.

I definitely do not recommend my method of learning LSL to anyone else -- I've got holes in my concepts and understanding and I don't even know where they are.

Best bet is instruction by a real person. I believe you can track down scripting classes to teach you the basics.

I remember the hardest part for me first starting out was that damn syntax. The curly brackets and the semicolons were killing me. At this point I have the same savant's understanding of the syntax that I do of written English. Don't ask me to explain why the semicolon goes here; I only know that it does.

I learned pretty much the same way you did, hack, cut, paste, brute force, reverse engineering etc. It certainly has it holes, but it's a good way to learn.

I have attended a few scripting classes in the past, but they usually get derailed by someone who has no knowledge of the interface or some of the most basic functions.

So yours and my methods are an okay way to get started. I recommend it.

Haha, brute force.

(Save)
ERROR: Function call mismatches type or number of arguments

"Fuck!"

(Edit things, Save again)
ERROR: Function call mismatches type or number of arguments

"...Fuck!"

(Repeat this process several times)

Compile successful, saving...

"Thank you, Lord!"

(After saving, the scripted elevator makes itself physical and bounds several sims away)

"Fuck."


Yeah, I know what you're saying.

With the scripting wiki, taking apart free scripts, and questions to the scripting forum, I've managed to script everything I've wanted to, but I haven't attempted anything really complicated.

But this confounds me:
(From the wiki)
"A state and a set of global variables can serve the same purpose, and each can be expressed in terms of the other."

Bugger!

I can get everything to work, but I can't figure out the best way to structure it. If I have a bit of code - do I do it in a function, a state, or even a different script in the same object?!? I try out all three and it works using all all of them, but I have no idea which is, er, best?

What would help me is a sanity check - someone who could read over my scripts and point out potential laggy bits, wrong function choices, and incidents of ugliness. I wonder how many people would be willing to pay for such a service?

I know it mightn't be practical for people wanting top secret scripts, but I'd love a stamp 'Approved by Smart Scripters as considerate, elegant, and low-footprint code'.

Don't know how to start or how to organize it because I don't know what all the available codes are and what they do. Too embarassed to ask anything.

I know what I want. I know what I want it to do. I just don't know what I actually have at my disposal.

I agree that tinkering with existing scripts is a great way to learn how they work.
I also agree that it's maddening to make something from scratch. Even if I (possibly) get what a state (or event, or function) is/does, I still lack the judgement of how to construct something efficiently.

I've found that I have to work (and save) in very small steps to stay on top of errors.


This would be great!


(emphasis added)
I've noticed this too.
Maybe the wiki should have a "dummies" version or option for us. For example, more detailed explanations that seem redundant to seasond scripters could be added in another typeface or color.

Ah yes, = and ==.
This drove me crazy until I figured it out. Indeed, there is a difference in what is is!

Thanks to everyone who has responded so far.

My biggest problems with trying to learn how to script have already been mentioned... the biggest being that the available documentation assumes too much knowledge. I could definitely use a "for dummies" version. The other thing that most boggled my mind is structure. What Fairge said is exactly how I feel about it. States was the only way I could figure out how to do stuff since it's at least somewhat similar (in my brain at least) to using gosubs (which I vaguely remember from waaaayyyyyy back dabbling with Basic and a class in Pascal in highschool. I figured out just enough to make a talking clock but gave up on it because I couldn't get the sound files to load and play reliably. I did just enough to be able to say "There. I've scripted." and then promptly forgot everything I'd figured out

My biggest problem originally was conceptual. Most of my programming experience is with number crunching (give a bunch of inputs.. do some crazy numerical processing.. spit out the answers). Once I got my head wrapped around the concept of events and states things became much easier.

My two biggest problems these days are rotation vectors (I can do it if I take my time and plan it out) and finding the correct name for a function.

Wiki has allowed me to figure out most everything I need, but it would be great if the search capability was better. The other day i wanted an object to delete itself when it was done. search "delete"... nope. search "unrez"... nope. search "rez"... nope. Commands related to objects? nope. Finally I dug through my inventory for an object that deleted itself (a bullet as it turned out).. AH-HA llDie(). I dont think I would have ever guessed that.

Of course the rush you get when a script finally compiles and runs correctly is great.

I'm not a beginner by any stretch, but I find the C convention for equality versus assignment annoying. My background is Smalltalk, and in Smalltalk, = and == are both comparison operators (= is equality, == is identity). If you want to assign something, you use := (like Pascal).

I have to sit down and check over my scripts when I am done to ensure I haven't made this mistake...

- Jon

I've had trouble with object oriented software.. but these are REAL objects.

I've been confused as to when it is better to have two scripts in two objects... two scripts in one object.. etc.

What would have helped me the most, coming in as a non-programmer/non-math major, would have been a glossary of terms and symbols. Yeah, I've learned how to use the ; and the = and the ==, but I still don't have a good grasp on WTF these are really doing. I still don't really grasp the difference between a state and an event, or whatever. So a good, simple glossary of programming terms and how they are used differently in LSL would have been handy.

Couldn't have said that better myself, Chip. Every time I attempt to read the docs, all I can think is "Darmock and Jalad at Tenagra".

In case anyone doesn't get that reference, I'll explain it (unlike what would happen if this post were a scripting manual). In one of the more interesting episodes of Star Trek TNG, Picard finds himself faced with the daunting task of having to communicate with the Tamarians, a race who frustrate everyone they encounter because they appear to make no sense whatsoever. It turns out their entire language is based on anecdote. They speak not in sentences, but in odd phrases from stories that the listener most already know in order to get the meaning of each phrase. They say things like, "Darmock and Jalad at Tenagra", and "Shaka, when the walls fell," and "Temba, his arms wide," fully expecting that the listener already knows what those things mean, and never even dreaming that someone might not.

The LSL manual seems to be written exactly the same way. It tells you things like "All LSL scripts have a simple implicit state machine with one or more states. All scripts must have a default
state, so iff there is only one state, it will be the ’default’ state. When a script is first started or reset, it will start
out in the default state."

Okay... What the heck is a "state machine", or for that matter a "state"? I have no idea. The word was used no less than six times in this single paragraph (if you can call it a paragraph), but the book has offered no explained what it means (we're only 3 paragraphs past "You're probably wondering what you can do". So, I flip back to the table of contents and find there's a section called "States". I turn to that section only to find it's just as abstruse as the the page I came from. It sas, "All scripts must have a ’default’ state, which is the first state entered when the script starts. States contain event handlers that are triggered by the LSL virtual machine. All states must supply at least one event handler - it’s not
really a state without one."

So now I'm left to wonder not only what is a state (the word has been used 5 more times, but still no definition), but also what is an event handler and a virtual machine. All I'm able to gather so far is that the authors absolutely love the word "state", and that it has no defintion of what it is, only what it sometimes is not, as a state without an event handler is not really a state (which could explain New Jersey I suppose, but doesn't really help me here.)

At that point I gave up, or as the Tamarians might put it, "Chosen Few, his face black, his eyes red."

That was a year and a half ago, and I'm no closer to unlocking the two great mysteries of the scripting world. The first of course is what is a state, and the second is how does one get past page 3 of the LSL manual without having visions of torturing small animals. All I'm able to do is more or less what Azazel said. I grab an existing script, fiddle with it until I figure out what to change so it will do what I want, and hope for the best. Most times, I end up breaking it, and then calling in one of my more feted friends to put it back together.

LOL Chosen. That's pretty much a perfect description of my experience too. I don't hold it against the SL doc and wiki writers though. Having taught 3d animation to absolute beginners for many years it took me a long time to figure out that words and concepts I took for granted (so much that they seemed self evident to me) sounded to my students exactly like "blah blah blah blah flux capacitor blah blah." I also learned that natural aptitude plays a huge role. I'd get some people who would grasp concepts right away after just a simple example while others would just look at me wondering what planet I was from. Obviously when it comes to programming I don't have a natural affinity for it. I still really want to learn it but now it's like deciding when would be a good time to stab myself in the eye repeatedly with a salad fork.

To further complicate things... I still can't tell when I script goes "idle" and when it keeps running. Very base level intro to SL is missing. If anyone is willing to post it, I'm willing to translate it

I posted the general consensus of the responeses I got in this thread. for the scripting experts to see. Jeffery Gomez has already posted some tips...