State Machine?

Hello,

I am unteachable so far in scripting (except for some reason I took to html like nothing back in the 90s and use notepad for it). I have bought books on LSL and I have gone over Wiki. They lose me by about the second paragraph, and the problem is they each say the same thing, so concepts are just never clarified for the layman to absorb wherever I turn. It's like reading man pages in shell.

I am going to ask various questions for a while as I determinedly read and reread paragraphs here and there and try to get a concept and fail.

My first question of the so far unanswerable is what a state machine is.

Is this the status of a prim or object in various stages as it transitions through a script? Like idle, then start, then maneuver 1, maneuver 2, end? Is this what they are trying to tell me it is?

Thanks!

If you really want to learn LSL, do it! Trial and error, get your hands dirty.
The beauty of LSL and SL is that when you fail nobody gets hurt. When you succeed you feel GOOD

I lost a cousin to a bad LSL stack heap collision error.

Poor guy... never really knew him but still, it's a sad way to go.

Hmmm... I'll try to explain a "state machine" in general terms, and then how the concept applies to LSL.

Let me give you a simple example of a "state machine". Do you remember the ads for the "Clapper". They had this little jingle that went, "Clap On, Clap Off" for a device that would allow someone to turn a light on and off just by clapping twice? That is a simple example of a state machine.

In this case, our machine has two states... "On" and "Off". That is to say, either the light is powered on, or the light is powered off. If we are in the "Off" state, and we hear the "Clap", then we'll turn the light on, and move to the "On" state. If we are in the "On" state, and we hear the "Clap", we turn the light off, and move to the "Off" state.

In a state machine, every "input" results in two things... One is an output, and the other is the next state. Furthermore, the output/next_state will be different, depending on which state you are currently in. Our "Clapper" state machine might look like this...

STATE - "Off"
--INPUT - Clap
----OUTPUT - turn on the light
----NEXT STATE - "On"

STATE - "On"
--INPUT - Clap
----OUTPUT - turn off the light
----NEXT STATE - "Off"

Two states, a single input... it works but its kind of boring.

But lets say that I wanted to build a "Super Dooper Clapper with Dimmer" state machine, which is the next version of our Clapper device. The Super Clapper will operate just like our old Clapper, except that we'll have another input. If the user whistles, then we will dim the light. The user can whistle if the light is either on or off, and it will go to this third state we'll call "Dimmed". If we're in the Dimmed state, and the user claps, we'll go to the Off position. And if we're in the Dimmed state, and the user whistles, we'll just ignore it because we're already Dimmed.

So now our state machine has 3 states (On, Off, Dimmed) and 2 inputs (Clap, Whistle), and looks like this.

STATE - "Off"
--INPUT - Clap
----OUTPUT - turn on the light
----NEXT STATE - "On"
--INPUT - Whistle
----OUTPUT - dim the light
----NEXT STATE - "Dimmed"

STATE - "On"
--INPUT - Clap
----OUTPUT - turn off the light
----NEXT STATE - "Off"
--INPUT - Whistle
----OUTPUT - dim the light
----NEXT STATE - "Dimmed"

STATE - "Dimmed"
--INPUT - Clap
----OUTPUT - turn off the light
----NEXT STATE - "Off"
--INPUT - Whistle
----OUTPUT - <do nothing>
----NEXT STATE - "Dimmed"

You can do a lot with state machines, and I use them regularly with my work as a software engineer in real life. They can often be quite complex with dozens of states and inputs, and different transitions/outputs for each state/input pair.

How does this all apply to LSL, you ask... Second Life scripts have a built-in capability to be in different states. Furthermore, you can change what happens in response to various events, depending on what the current state is. Think of LSL events as Inputs in the example I provided above.

For example, you might want to have an object do one thing when it is touched while it is attached to someone, but do something completely different when not attached. In that case, you could have two LSL states... one called "attached", and one called "not_attached". Each would have a "touch_start()" event, and the events would do something different, depending on which state it was in.

I have seen On/Off scripts that allow a user to Touch a lamp, and it turns on and off a prim in response. In this case, it would look a lot like our first Clapper state machine, with two states, and the single input would be a Touch event. The "output" would be changing the properties of a prim to look like a light going on or off.

I suppose this is as clear as mud by now, but perhaps it might help educate some people on what states can do, and how they can be used in LSL.

- Ace

Wow Ace that made sense! That was awesome. I wish I'd seen such an example before.

A question about the last part:

If the state is off, how can it react to a command which it would only be scripted to acknowledge while on?

Are you saying even if an object is in a state not set to react to certain input during that state is given those inputs, it still responds and changes its state, even if there is no output or we dont see one? Doesnt it have to pass into the state where that input is recognized first? Wouldnt the state still be off because the script did not react?


(Cant do it without knowing what to do enough to try it. Once I know the basics then I can get familiar with the range of parameters I can work with. I have specific things in mind to achieve at this stage but I need a beginning I can understand)

Wikipedia can be your friend here, Holocluck, if you don't mind lots of reading. A number of the terms you'll see when reading about LSL aren't unique to LSL but are standard programming terms.

http://en.wikipedia.org/wiki/State_machine

I tried LSL Wiki. They didnt help. I've visited sites and bought books. Ace's post was the first time that concept made any sense.

If anyone making a so-called beginner's guide did away with the namedropping of other program languages and just explained things in human terms, then I could actually say "hey this is REALLY for beginners and not existing scripters and programmers migrating over to LSL."

But that isnt the case. So here I am.

These guides always work this way: ok here's how you make a cube, and here the stuff is in brackets, and blahblah terminology blah blah blah like c++ but isnt c++ blah blah funny string and term blah blah.

We who have not scripted in a programming language before cannot learn from that.

Yep, the various SL-specific wikis are more of a reference than a guide.

My point, if you're responding to me, was that wikipedia (which is not at all SL-specific) is sometimes a good source of info when you run across a generic programming term you're not familiar with.

LSL is a programming language. And as any other programming language you need to know the basics. There are whole carreers dedicated to study computers programming...so that's why is hard to learn.

Yes, it was easier to learn html because it is based on observation. A movie director's queue sheet. Once you know the basics (the tags just say put this here, make this orange, center this), you can dive in.

The thing is when I tried to look up terms in wiki I got the "jumble" and not any analogy to help me comprehend.

So has anyone the answer to my question regarding an off state and a command used for on state and why it would change the off state. Wouldnt it still be off and the command rejected? The example suggested although there's no output, the script is acknowledging it to change its state instead of reject it covertly.

The "OFF" state is really a "LIGHT OFF" state - it's not a "PROCESSOR OFF" state or it would have the problem you describe. So in a functioning device, the OFF state would be scripted the light turns off, but the controller listening for command inputs keeps running.

States in LSL are similar; you can have a dormant state in which the script is doing nothing except listening for commands that will put it in a more active state.

That's very interesting! Thanks... this was all great info. There may be hope for me yet.

And I thought I was the only one. Thank you Holocluck for pushing on when I just threw up my hands. Mind if I jump on the train again..lol. Ace's expaination of states is the first one I have read that I actually got. If anybody else would care to explain anything the way THAT was explained I will be listening. Unfortunaly I am so lost I don't even know what to ask...more questions maybe Holocluck??
Shayla

The main difference between HTML and a programming language is that HTML is descriptive (how is it structured and what does it look like?), whereas a programming language is behavioral (what should it DO?). Just about any computer program is going to be a kind of state machine in that it remembers what has happened and bases its decision both upon the past (memory) and on current inputs (events).

When we use "state machine" in a programming context, it generally means we are going to define a few conditions under which the program behaves very differently. Here is an example. You go to the gas station and use your credit card to buy some gas at the pump. The pump is going to have a few states which we could call, say, "idle", "waiting for card" (after you've chosen debit/credit payment), "authorizing payment" (where it talks to credit/bank to verify your payment), "pumping", and "printing receipt". Which state the pump goes to next is going to depend on the current state (what's happened before; memory) and the inputs (you swipe your card; a payment authorization response is received behind the scenes). An example of different behavior based on the current state would be that swiping your card would have different or no effect when you are currently "pumping" than in the "waiting for card" state. An example of different behavior based on different inputs might be that from the "authorizing payment" state, the pump might go back to "idle" or "pumping" depending on whether your payment is accepted or rejected.

As someone who tutored a lot of students in Math and Computer Science when I was in college, I can assure you that this statement is not correct. For some people, learning computer programming is like a second nature, and it all comes quite easily.

There are really two types of people when it comes to learning programming, those who get it right away, and those that struggle. When I was tutoring, I was dealing mostly with the latter.

What I found is that I would generally have to think of about 10 different ways to explain any given concept, and if I went through my internal list, I would eventually hit the one that let the student go, "Aha!!!! I get it now."

I should add, however, that the ease with which someone picks up computer programming is in no way reflective of overall intelligence. I have met some pretty stupid people who are whizzes with code, and I have met some pretty intelligent people who never seem to understand programming at all, no matter how hard they try.

- Ace

Those who use binary, and those who do not.

this is probuly a bit offtopic but BEWARE OF MULTIOBJECT STACKHEAPS it will litterly crash you every time you get into sl if you are wearing the objects

This thread has gone sooo OT, I can add my 2 cents here as well, I guess

In Reply to Kahiro and Ace:

Programming is NOT hard to learn. It's a matter of being able to break down a problem into small steps. This doesn't imply, how well written the code will be. There's are always more than one possibility to solve a problem.

I usually describe programming as explaining something to a person who has never done it before - making a coffee, for example. Break down this - pretty simple task - into small pieces of language, don't leave anything out and you have - technically speaking - written a program. Now - assume that you'd have to explain this task to a foreigner. Then you have to translate the code you just made into another language (with all its shortcomings, lack of descriptions and so on). This is like writing a script in LSL and in PHP (where LSL is Kisuaheli and PHP ... well... you get the point)...

Depending on how many «words» a language has, you need less words to describe a task which makes it easier. In other languages, you might have to make a whole sentence where you need a simple word in another language (one of my favourites is «to pretend» which translates to «so tun als ob» in german)...

So - to make the point: learning to script is about as hard as it is to learn a foreign language. All you need is the grammar and the words... but knowing these doesn't necessarily mean, that you can write a novel

What books are there to buy on LSL?

It seems a bit odd to me to start trying to learn LSL and get stymied by not understanding what a state machine is.

I'd start out with something more like

"Here's a small sample script that makes an object go up 1 meter when you say UP and down one meter when you say Down. Can you change the script to make it go up 2 meters and down 2 meters instead of up and down 1 meter?"

Here's a sample script that make a texture switch from one image to another when you touch it. Here's another sample script that makes an object toggle between two rotations when you say CHANGE. Can you change the first script to make the texture switch when you say CHANGE and make the other script make the object toggle between two rotations when you touch the object?

I have a bunch of short sample scripts if you want them. Be advised some are so old they don't work properly anymore due to changes in LSL. Most of them do, though. Making changes to little scripts like these seems to be a good way for some folks to learn.

Also, if you haven't read the introductory material at lslwiki.net, that would be a good place to start.

Also, would you like to join the Scripters of Second Life group, if you aren't already in it?

Ever heard of Google?

Anyways, Ace's explanation of states was a very good one, pehaps Ace should be writing books.

My personal opinion on programming is that there's something more to just understanding functions and states. One also needs to understand variable types, casting, and also how binary works. Most of the time it's not particularly needed, but there's times when understanding it is helpful. LSL makes life easier with constant definitions, but just understanding what's going on when you type if (change & CHANGED_INVENTORY) is important. Even when you get to the point when you know the functions and events, understanding how languages work is pretty important to being an effective and
efficient programmer. Someone earlier mentioned how they took to HTML quite easily, that's because even though the world Language is in the name, it's NOT a programming language, it's a markup language, which means it's a way of depicting the logical structure or semantics of a document and providing instructions to computers on how to handle or display the contents of the file. You don't run into the sorts of logical constructs you do in programming, it's simply 'lay out this data this way', that's it.

I tried all the wiki's. I dont mind joining a group as long as I dont get pummeled with a chat window each time I log in and if I could really ask the questions like this I need to and get an answer NOT in those books or Wikis. We'd be wasting both our times otherwise re the latter.

I love creating and sharing my work but it's a different ballgame here. My 3D stuff is useless without adding some "life" to them. I can understand the need for function here. It's been two months and I've been spinning my wheels and I still havent put anything out because of this lack of scripting guidance for the layman.

Personally if someone went over something I wanted to achieve, and we stopped and discussed each new addition to the script and why it is what it is, I think I would absorb its significance. Whether I could apply it to other types of scripts I dont know; I guess it depends on what I understand from it. The purpose of such a pursuit would be to understand it, so who knows?

Holocluck Henly, what books did you buy on LSL?

Introduction to Linden Scripting Language
Scripting Recipes for Second Life
Creating Your World: The Official Guide to Advanced Content for Second Life (touched on scripting but was an all around guide)

States are confusing, of all the things in LSL, I really wish people would save learning them until last. Of all the things you need to learn in LSL, you can do without learning about states.

LSL is a C style language. Just getting that out of the way.

I'll take a crack at explaining scopes, which should help you decipher the jumble. In C style languages a scope is started with an open curly bracket ("{" and ends with a close curly bracket ("}". Now you are still wondering "What the hell is a scope?" In HTML a scope would be the area between the start of a tag and it's end, the innerHTML if you like. Such as: <span>text</span>, "text" is in the span tags scope. <span> indicates the start of a scope of type span, and </span> indicates the end of that scope. Like HTML, C style languages can embed scopes, each scope having different possible effects. In HTML you have conditional scopes, the <noscript> tag for example only gets it's innert html included if the browser doesn't support java script. In LSL there are 6 types of scopes. Global, Function, State, Event, Conditional, Non-conditional.

In HTML you wrap the tag name in angle brackets, in C style languages you don't and you wrap the scope in curly brackets.

The Global scope can contain Function scopes and State scopes, along with global variables.
The State scope can only contain Event scopes. Function and Event scopes can contain conditional and non-conditional scopes. Variables can be declared in the global scope, function scope, event scope, conditional scope and non-conditional scope. Those variables will only be visible in child scopes.

Anything after a // is a comment.

So:

//Global Scope

default //we have indicated a state
{//we are now inside a state scope
    
    state_entry() //we have indicated an event
    {//we are now inside the event scope
        integer int = 5;
        {//non-conditional scope, notice that there is no preceding word after the ";"
            float f = 1.0;
            int = 3;
        }//we are outside the non-conditional scope, "f" is no longer accessible,
        //since int was declared in the event scope we can still access it and it will have the value 3
        
        if(int >= 3)
        {//a conditional scope of type "if", it's not a loop so it only runs once
            int = 4;
        }// end of the conditional scope

        if(int == 4)//a programing shortcut, if you don't include the "{" and "}" only the next expression is considered a scope.
            int = 5;

        if(int == 5) ; //this is valid and is the bane of all scripters. Learn this well!!!
        //the ";" activates the above shortcut and if you follow it with a "{" "}" scope it will be non-conditional! 

    }//end of the event scope "state_entry"

}//end of the state scope "default"

*eyes cross*

I'll have to give that a longer look and blink some more after work (or maybe I'll print it out for the commute home).

The scopes part is easy (didnt know it was called that though). Just about any kind of script has a range where specific variables and parameters are declared. The curly brackets were in IRC scripts too (something I mastered back in the day and forgot since). And although I never coded VRML from scratch, I was good at editing existing code. They had the brackets. And lest we forget CSS.

Thats the thing they all start with along with making copying and linking shapes. Then they jump into - well stuff very different from the scopes.