State Machine?

I'm not sure that I agree with that statement, Strife.

Ignoring the state machine capabilities of LSL can take a script that would be simple and concise, and turn it into an ugly mess of nested if/then/else statements.

Yes, there are other concepts that are just as important, such as basic control structures, variables and typing, and the whole notion of function calls (both builtin functions, and user written ones). But the builtin state machine support of LSL is one of its few elegant features, and I wouldn't avoid trying to teach states.

- Ace

That'll happen a lot until things finally click. Once you get your brain wrapped around it, it'll suddenly seem a lot easier and you'll wonder why it took so long to get. Don't feel bad about it at all - it's really very common.

You can sorta think of scope as like a stack of boxes. Each box can access variables that it declares and variables that boxes below it declare. Each time the code comes across a {, a new box is added on top. Each time the code comes across a }, the top box is removed.

If you declare a variable with the same name twice, the one in the closest box is the one that gets used. If the box that declares a variable gets popped off the stack, that variable is no longer accessable.

This isn't a _totally_ correct analogy but it's not too terrible.

edit: also, if you didn't know, the forum software isn't very good with formatting LSL code any more. If you click the Quote button on Strife's post, you'll get the spacing he used - copy all the text into notepad or something, it will have much better formatting.

The concept of state machine in general computing terms can be very complex and makes for very interesting/painful reading. Luckily, LSL uses only the simpler parts of state machines.


LSL state machines can be though of as akin to the gears of an automobile. Depending on which gear you're in - let's say drive, neutral, or reverse - you get different results from pressing the accelerator. LSL works the same way: only the events associated with the current state that the script is in will react to inputs (the accelerator). If you want some code to be available regardless of the state (the gear), then define it as a global function, and call it from an event in each state.

Yes, it is possible to code your script entirely in the 'default' state, but that means you have to track everything yourself. Sometimes using the states to track what features are available can greatly reduce the complexity of your script.


- Newfie

Or if you are using Firefox you can use the BBCode script I wrote that restores bbcode to the forum. The script can also be run in Opera I'm told.

/327/b2/188445/1.html

---

As to states, they have their quirks and to properly understand them you really need to understand events first. I'm not saying they aren't useful or that they don't have there place, just that they can cause their own amount of hair pulling during debugging.

Or pasting it into MSWord set to Courier New...

Actually with VRML we saved filespace eliminating the indentations. They arent really necessary.

To be honest, no one should even be shown a script until some very basic things are covered. And by basic I dont mean namedropping other program languages (this is for beginners. Let experienced programmers think the obvious for themselves) and suddenly throwing numbers out of the air. Go over things. This is the structure of a command:

---

Explain what a parenthesis does etc on the line. break it down FOR BEGINNERS.

Then make a single line and explain it. In an instuctional guide, it has to be broken down THAT MUCH - for beginners.

For example: I've seen a teleporter script I dont know what the heck it says. The comments arent enough sometimes. Okay I see I put the start coordinates here, but there are numbers I need to put based on the difference between X Y and Z. It isnt clear HOW to enter these and whether it's with +50 for Z higher up for example or -50 for below, and how to rotate the av to face the right way on arrival. A free script is worth just that to someone unfamiliar with how to use it.

Once the syntax of command strings are explained to their fullest, THEN discuss the info you can put in them. In one of the books, right there they dump this chart of integers this variables that yadda... NOT at the beginning!!!

Break it all down (for example the XYZ - and they said S but didnt explain what S was - and HOW do you state a movement or change in position of the start coordinates? It was never explained, although thats what was necessary) and dont veer off course and namedrop something advanced or complex and say "but we'll get to that later" or you've lost BEGINNERS entirely.

Make a string, then make another string that does something else and explain it. Show how to represent each in order in a script - that's when the brackets really show their worth.

Then place the ends at the top and bottom to show how it all comes together. Describe in details the start parameters like touching, saying, proximity (and give an example; and you know it isnt even clear if the notecard and greeting scripts throw you their output because of arrival, or because the launch point IS within proximity. But wouldnt that get annoying if someone walks around your property and is nagged all the time? At any rate, the way something works to the nth degree needs to be explained in a guide).

I looked at a script this morning that had one set of brackets - I think it was hover text - it actually almost made sense. It lookd simpler than the default script, which makes no sense. Pity there was no free script to hover an object, which was what I needed, but I probably wouldnt have made heads or tales of it anyway.

So here I have broken down what someone - who is not dumb but unfamiliar with programming - needs in order to learn. I saw on Amazon that LL is putting out an official LSL book. If it's anything like the Wikis or what's been put out already, they might as well save everyone the grief of history repeating itself. It wont be for anyone who NEEDS a book to learn it. We need something to actually teach us.

hmph

States in LSL took me a bit to understand. What helped me have my epiphany was drawing circles within circles. Mapping, so to speak.

Grab a piece of paper and a pencil. Draw a really big circle on the paper. The piece of paper is the prim and the big circle is the script. When the script is running, you are somewhere in the really big circle. Give this circle a name, like MyLSLmap or whatever you want to name your script-circle.

In MyLSLmap, draw two more circles with in it. These two circles are not to be touching, intersecting, or be concentric. Two entirely seperate circles within MyLSLmap. These two smaller circles are circle-states. One will be StateOn and the other will be StateOff. You can be in either of these circles, but not both at the same time - and you must be within one state-circle at all times.

Within each of those state-circles, you draw in your event-circles in the same manner. Each one gets a EventTouch circle with the code to change states. Each one gets a EventExit circle with llPwnerSay "Is leaving StateOn/Off". And so on.

Thinking in circles in this manner is what got me going. Now that I have a way of thinking in how LSL flows in an abstract manner, it's just a manner of syntax and functions. I can map a script in no time at all and get busy.

Tada.

For more info see:

http://en.wikipedia.org/wiki/State_diagram
http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm

Thanks! I understood state machines from Ace's description on the first page. If I read anything more I'll unlearn and if I read anything from wiki about lsl again my brain will melt (it left such a great impression on me).

However there are probably people in my situation whose perception will probably click with your circle analogy, so it's great you posted it.

Sorry I'm just extremely frustrated about scripting in general.

Thanks Ace for your help on the first dilemma. Tonight I'll ask a new question.

Holocluck: The indents aren't necessary, they just make reading code easier. In LSL (and other C style languages) whitespace is only rarely required, and when it is required it's no more than a space. You will find with time that consistent whitespace makes code easier to maintain (debug and improve).

So..just curious.. could you technically right any script on a single line? (Without word wrapping of course)


Cause that would both be cool and suck.

In my opinion.

Yes you can and yes it is kinda cool until you have to work with it. I feed such code to Tidy (a C++ code beautifier that has no problem parsing LSL)

I have been struggling to learn scripting since 2005, and am still a relative novice. But I have found it helpful to focus on learning how to do one simple thing at a time. That has over time grown into a useful kit of parts that I am now learning how to combine into more complex scripts. I have intentionally posted examples of simple scripts in the libraries here specifically in hopes that they will help other beginners learn scripting in simple steps.

Interestingly, one of the first useful things I learned was to use states, triggered by either touch or chat events.

Here are a few that I think will be helpful to beginners:

Touch on and off for Light and Phantom
/15/44/82003/1.html

Phantom Alpha Door or Wall
/15/99/137152/1.html

Touch texture change using states - window example
/15/79/137912/1.html

MessageLinked and linked_message example
/15/4c/138878/1.html

collision_start switch to RezObject
/15/1f/164265/1.html

Look up Finite State Automata, or FSA, or Finite State Machine, and you will find good descriptions of this theoretical computer science concept. For each pair of states, and "input", there is only one possible transition from one state to the next. You can easily visualize this as a directed graph, where "blocks" (circles, whatever) represent states and "connectors" (arrows, etc.) represent individual transitions. The "input" that triggers a state transition can be arbitrarily complex, just so long as there is exactly one possible next state given that input. (This is a deterministic finite state automata). If you want to have multiple possibilities, include a coin flip / random number as part of the "input".

http://www.google.com/search?client=safari&rls=en-us&q=finite+state+automata&ie=UTF-8&oe=UTF-8