States vs. user defined functions.

I have another basic question trying to get my head around things conceptually. In studying example scripts and the lslwiki, I am not really grasping the use of differents states as opposed to user defined functions. States seem to transfer control of the program from one part of it to another, much the same way a function call transfers control from the main program to the function and then back when function completes. What is the advantage of using one over the other?

Someone with a more sophisticated understanding will give you a more rigorous answer, but I tend to think of functions as globally defined actions that may be accessed from any state, where states are sets of events that define environmental conditions. I don't know why my mind drifts to thoughts of food (except that it's lunchtime)....... I might conceive of three "states"-- satisfied, hungry, and ravenous --that define different conditions of my body at various times of the day. In each state, I respond to environmental impulses in different ways. In ALL of them, however, I may need a user-defined function called "eating" that I call when I want to do something in response to those impulses. "Eating" is global.

OK... so that's goofy. In my own relaxed way of thinking about scripts, it helps me decide how to compartmentalize the various actions. Now you need the voice of a master scripter to give you a good technical answer.

States do not replace functions and functions not states. You can not return from a state, you need an active change of state. You cannot pass variables and return variables like you do with functions.
I like to see states as a row of 'main programs' you can switch between

States are really a way to separate very distinct behaviors that are used at different points in time. Consider code that looks like this (nevermind that there are more optimizations that could be done and such, just pay attention to the organization of the code):

integer WALKING = 1;
integer RUNNING = 2;
integer SITTING = 3;
integer SLEEPING = 4;
integer MEDITATING = 5;

integer myState;

default
{
   state_entry()
   {
      llSetTimerEvent(10.0);
      myState = WALKING;
   }

   timer()
   {
      if (myState == WALKING)
      {
         llOwnerSay("I am currently walking");
         myState = RUNNING;
      } else if (myState == RUNNING)
      {
         llOwnerSay("I am currently running");
         myState = SITTING;
      } else if (myState == SITTING)
      {
         llOwnerSay("I am currently sitting");
         myState = SLEEPING;
      } else if (myState == SLEEPING)
      {
         llOwnerSay("I am currently sleeping");
         myState = METITATING;
      } else if (myState == MEDITATING)
      {
         llOwnerSay("I am currently meditating");
         myState = WALKING;
      }
   }
}

And now see what it looks like when done using states:

default
{
   state_entry()
   {
      llSetTimerEvent(10.0);
      state walking;
   }
}

state walking
{
   timer()
   {
      llOwnerSay("I am currently walking");
      state running;
   }
}

state running
{
   timer()
   {
      llOwnerSay("I am currently running");
      state sitting;
   }
}

state sitting
{
   timer()
   {
      llOwnerSay("I am currently sitting");
      state sleeping;
   }
}

state sleeping
{
   timer()
   {
      llOwnerSay("I am currently sleeping");
      state meditating;
   }
}

state meditating
{
   timer()
   {
      llOwnerSay("I am currently meditating");
      state walking;
   }
}

Now the logic can be a lot more complex than that, with many different event handlers (not just a timer) that all behave differently depending on what logical state the script is in (perhaps touching a sleeping or meditating robot makes it stand up and start walking, but touching a walking or running robot makes it jump). Would you rather repeat the if-else conditionals in each event handler like in the first example, or repeat the event handler declarations like in the second example? There are cases when dividing things up between states can make your code a LOT simpler and better organized.

There are other aspects to consider also though. One is the fact that there is some non-trivial behind-the-scenes work the server does when you switch states (removing all listens, probably registering a potentially different set of events the script is interested in, etc.). So it is generally best not to be switching states very rapidly, both for script time (server lag) and the performance of your own application. Another is that sometimes switching states is the ONLY way to accomplish something, such as only accepting money payments when a vendor is properly configured (a resident doesn't get the "pay" option for a prim/object unless one of its script is in a state that has a "money" event handler).

States are best used when you are modeling or interacting with a system where there are well known and distinctive states to the system. For example, you might use a state for reading a notecard because while you're reading that notecard you're not doing anything else, and you don't want to have to handle and ignore events that are not related to that operation.

If the state of the system you're interacting with or modeling is complex, or where you have a lot of behavior in common across multiple states, then you would use state variables instead of states. for example, most AOs don't use different states to represent different animation states because there's so much common event handling between animation states.

Thanks everyone. Gives me more to think about.

a simplified version of what argent said:

states control what input you want to allow right now

+ my addendum:

changing states cancels listens, sensor repeats, and a few other things, but not timers, target omega, or constant force physics settings (fun attributes to abuse)

Anybody got a full list of these, for reference?

It's both more and less than that. Some problems are best modeled by states, others are best modeled by explicitly canceling and reasserting listeners and the like and adding tests on state variables in the beginning of the event handlers.

You're right, I was less than adequately specific about the effect of states on events.

honestly, no. I think the only ones it cancels are listens, sensor repeats, and possibly the target, look at and and incomplete one time physical functions (move to and rot to, target.)... those last few I've never tested, just an educated guess)

state changes will also toss out a new start for repeat style events (like touch and collision start), for things that would still be triggering the simpler (touch and collision) events

oh and there was (still is?) a bug when moving from a state without certain event handlers (like touch) where they'd refuse to trigger in the new state under certain circumstances. pretty sure that got fixed though

Thanks to everyone for the answers to my rather basic questions that I tend to start threads about. I try to ask them in such a way that I can learn out how to do things rather just letting you guys write quick scripts for specific applications.

I think you've captured the essence of what this forum is about then; IMO more than many who come here with requests. Obviously we're happy to help with specific questions as well, but--helping people learn HOW so they can go out there and practice better scripting--THIS is the good stuff!

Is it this one you have on your mind?
Reference: http://wiki.secondlife.com/wiki/Touch_start
I'm not sure it is a bug, rather a 'specification by design'

no, it was actually a jira, where moving from a state w/o the handler caused the next state not to be able to receive those events, but the one after it was fine... I do believe it's been fixed though. very hurtful to scripts that used dead states to handle listen kills. there was some additional thing involved, I think possibly the default state, but it's been awhile.