I cannot "get" states

exits... entrys... im so confused

Bring back the days of 10 CLS, 20 PRINT "HELLO", 30 GOTO 20!!

Anyway, maybe it's because it's so late, maybe it's because I'm old... I just can't "get" states.

I am going to rattle off my questions... Could someone just rattle off some answers so I can get my mind around this seemingly simple concept?

Are states used as flow control?

Do I have to use a state to stop the script and wait for an llList event from a user?

Are variables carried over between states?

What is a "callback setting?"

Would I use states to "bounce around" my script, based on actions of the user (i.e., if they win, goto the "win" state and if they lose, go to the "lose" state)?

Those are the ones that are really bugging me right now, cause I have read the Wiki page on this like 20 times and I'm still as lost as I was when I first read it.

Sure




Sometimes. States are used when you need to focus on certain event handles only, or want to immediately assume that your script is going to do something when some event X happens.



This depends on what the script is being used for. For example, I recently posted a script that used states "unnecessarily" here. With that script, I purely used states as an organizational tool, the first state (default) was used for initilization, stuff that needed to be done once per script reset, and the second state (sensing) was the "running" state, where the work was done.

I could have easily had all events in the default state and simply started the sensor upon recieving my data from the dataserver event.

I dont think that way though.



Global variables are, but that's obvious (isnt it?) Local variables are confined to individual event code blocks and functions... so Im not sure how you got this idea about "carrying over".



Actually... Im not sure. Where did you hear this? Given some more context, I can probably answer this.



Well, when the user wins or looses doesn't the game end no matter what? As I said before, states are used mainly as an organizational tool, and to "focus" your script on a set of events, and those events only.

==Chris

Not to refute anything that Christopher has said (as he has probably done 100x as much scripting as I), I tend to read the line

state foo {

as "define a new set of handlers". I think this is closer to the meaning of the code than "state" may lead you to believe. Variables (booleans and scalars) that track state in the conventional sense of the word are often better at tracking script state than states are.

Was that confusing enough?

There is an example "Sim Stats Display" that I use in a Scripting Class covering States that I teach. It shows a simple use of three states...

Default: for initialization, the first state that is run when script is reset.
Idle: a state for when I want my script to sit there and do nothing, waiting for user input.
Running: a state for when I want my script to be constantly displaying statistics for the sim

Simple Example

default
{
    state_entry()
    {
        state running;
    }
}

state running
{
    touch_start(integer total_number)
    {
        state idle;
    }
}

state idle
{
    touch_start(integer total_number)
    {
        state running;
    }
}

Each state is like a "mini-script" within your script. Each state can have it's own event handlers, like a unique timer event handler in two states, and no timer event in another state. They all share, however, any global variables you might use and any custom functions you declare.

States are used for organization, so you can break your script up into logical parts. You name these states or parts as you see fit, whatever makes sense to you. Remember there must always be a default state, so the script has something to run when it is reset.

Another example would be maybe a gambling machine with the following states: default, waiting, playing, winner, loser.

default: the first state that is run, for inititalization
waiting: state that sits there and has a money event, waiting for somebody to pay your gambling machine.
playing: state that is actively waiting to do some gambling stuff, like showing cards or rolling dice. There is no money event here, because we've already been paid and the machine is now "running". We don't want to accidentally be paid twice, so a separate state makes this easy. (i.e. since there is no money event in this state and the other non-waiting states, it's impossible to pay the machine until we get back to the waiting state).
winner: this state will flash some lights in its state_entry event, and pay out some money.
loser: this state will play some bad sounds in it's state_entry event, and NOT pay out money. Having it separate from the payout in the winner state, makes it easy to make sure you don't lose money!

So you sit there in the waiting state for somebody to pay you L$. Once you are paid, you switch to the playing state by calling "state playing". Once the gambling part is done, you decide whether or not they are a winner or a loser. Then switch to the appropriate state. Once the winner or loser state are done with declaring them a winner (by paying/flashing lights) or a loser (by playing a bad sound/no money), those two state would switch back to the "waiting" state for more money.

Another Example, Long

//Gambling Machine
//State Example
//by Hank Ramos
key playerID;
integer amountPaid;
integer winningAmount;

default
{
    state_entry()
    {
        //Do some initialization here
        llRequestPermissions(llGetOwner(), PERMISSION_DEBIT);
    }
    run_time_permissions(integer permissions)
    {
        //Only wait for payment if the owner agreed to pay out money
        if (permissions)
        {
            llSay(0, "Initialized Successfully...");
            state waiting;
        }
    }
}

state waiting
{
    state_entry()
    {
        llSay(0, "Idle...");
    }
    money(key id, integer amount)
    {
        playerID = id;
        amountPaid = amount;
        state playing;        
    }
}

state playing
{
    state_entry()
    {
        //Do the gambling bit in this state
        
        //Determine if they are a winner or a loser
        //Half the time pay twice the bet
        //The other half, pay nothing.
        if (llFrand(1) >= 0.5)
        {
            winningAmount = amountPaid * 2;
            state winner;
        }
        else
        {
            state loser;
        }
    }
}

state winner
{
    state_entry()
    {
        
        llSay(0, "You won L$" + (string)winningAmount + "!");
        llGiveMoney(playerID, winningAmount);
        state waiting;
    }
}

state loser
{
    state_entry()
    {
        llSay(0, "Sorry, you lose.");
        state waiting;
    }
}

Goto the University of SL library, and get a copy of the objects and scripts mentioned here so you can see the scripts and how they work. That might hopefully help

Edit: typos

I remember those days!
I remember my dad proudly unveiling his new TRS 80 IV and how excited we were... the thing had the resolution of a LiteBrite and no colors. To 'draw' something I believe we had to plot out which cordinates to light up.


pardon the hijack

edited to add details

I dont think multiple states for winner and loser are necessesary. The reason for this, is simple, your only using state_entry. This *begs* to be refactored not into seperate states, but into seperate functions.

handleWinner(key winner) {}
handleLoser(key loser) {}
==Chris

You're right!

Sort of...

But, having them as global functions makes it possible that you could mistakingly call handleWinner and pay somebody, somewhere else in your script. States allow you to section off code into logical groupings.

It was only meant to be a "simple example" of how to use states. Most simple examples are somewhat absurd, and could probably be reduced to a few terse statements. The point was to provide an example that educates people about what states are, and how they could be used. A complete example, with complex amounts of code would only serve to confuse people.

I would assume that the winner and loser states would have much more in them, like maybe a timer event for controlling some cool siren, lights, and other effects to display winning and losing, or other code. It was only a "shell" of an example to get somebody going.

edit: clarity, typos