Better to use states or not?

For a moving window is it better to use different states or is the following ok for best practice?

integer switch = 1;

touch_start(integer n) 
{
        if (switch)
            open() ;
        else
            close();
        switch = !switch;
}

For such simple logic I'd say that way is perfect. When you have complex logic, especially where different event handlers are required for different cases, I think states are a good tool. I don't think there's any magic criterion for when and when not to use them.

states are faster and clearer you need less "if" and less variables.

But you have more states and more state changes..

For something like the OP posted, I can't imagine you get any real savings by using states.

Since I started using LSL I read "state" as "establish a different set of event handlers". I think that is closer to the meaning of an LSL state than in the general computing sense of "state".

I agree with Malachi, for simple on/off stuff, like a light switch, it's silly to use states that way. States are for exactly what Malachi said, establishing another set of event handlers. Even the wiki states (no pun intended)

"After the default state definition can follow additional state definitions which the script may use to change how and which events are handled."

Note how it mentions how and which events are handled. The underlying implication is that it is there for setting up new event handlers.

It is and it isn't. In typical SL fashion certain events are persistant across states i.e. timers.

"States vs. Global Variables
A state and a set of global variables can serve the same purpose, and each can be expressed in terms of the other. In general, using states over global variables allows immediate script state assumption without making comparisons--and the fewer comparisons a script makes, the more regular code statements it can run."

http://lslwiki.net/lslwiki/wakka.php?wakka=state

Check example 1 and 2.

Yes, branching is teh evil, especially in interpreted languages. But those wiki examples are clearly there only to demonstrate the point being made, not as examples of real-world best practices. How fast does a touch_start handler need to be, is it realistic to think that one additional compare-and-branch will be noticeable to a user at all?

For extremely simple tasks like that given in the original post, you should simply do whatever you are more comfortable with. Maintenance and readability are far more valuable goals than any theoretical gains in efficiency for any script of that kind of trivial complexity.


.

I agree but my response to Kahiro above was more based on size than speed.

For example, this...

integer switch = 1;

default
{
    state_entry()
    {
        llOwnerSay ((string)llGetFreeMemory());
    }
    
    touch_start(integer n) 
    {
        if (switch)
        {
        }
        else
        {
        }
    
        switch = !switch;
    }
}

Produces: "Object: 16119"

And this...

default
{
    state_entry()
    {
        llOwnerSay ((string)llGetFreeMemory());
    }
    
    touch_start(integer n) 
    {
        state closed;
    }
}

state closed
{
    state_entry()
    {
    }

    touch_start (integer n)
    {
        state default;
    }
}
CODE

Produces: "Object: 16099"

Which leads me to stand by my original point that the "less variables" doesn't mean much in this context since it actually uses more memory in code.

For speed, I don't know what the execution speed is of testing an int vs 0, and I don't argue that it's as fast as it could (should?) be but I don't think a state change is free.

From: RobbyRacoon Olmstead
For extremely simple tasks like that given in the original post, you should simply do whatever you are more comfortable with.  Maintenance and readability are far more valuable goals than any theoretical gains in efficiency for any script of that kind of trivial complexity.

Absolutely.

edit: er.. I guess the closed state doesn't need a state_entry() but my in-world time has run out for now and can't retest it. Still, I'd be surprised if it ended up less than the stateless version.

not sure how states are handled under mono, but the behavior of slowed state changes (in mono) suggests that they exclude all but the current state (I think strife suggested possible JIT compiling on states was happening)... the above example probably wouldn't matter much either way, complex logic might work better as states, unless you want to do a lot of rapid state changes. (there's a post around here about jesse testing the speed of various funtions/state changes that deserves credit).

when it comes down to it though you should go with watever gives you the simplest logic, and if you feel like it try the alternate for speed... but the simplest logic usually wins for speed

I use states for readability, _if the state behavior gets non trivial_.

If I find myself with awhole buncha global integers like "SLEEPING' 'DRIVING' 'DANCING' 'ANIMATING' or what have you, and a bagillion other variables all of which mean something but only when one of the above is turned on.. I start to look at whether the script could be broken up to either

1. jump from state to state as it runs like a typical state machine might, really only doing one set of things at a time depending on what state its in

2. or to use the states as callbacks to break up related bits of functionality, like menu handlers and short lived user interaction/requests for input etc.

I also seem to use them a lot to deal with initialization, jumping from state to state as I parse and deal with individual notecards so each state can be doing very obvious parsing and not trying to handle the world in each event.

Honestly, though.. I think a script has to evolve beyond 'door open, door closed' before it really starts to be an obvious win for maintainability.

Agree with everything posted above, including that the example script is perfect the way it is and is not a good candidate for state changes. I don't use state changes unless I have to. That being said, I find that I do HAVE to use state changes all of the time. Those last two sentences really aren't at odds with each other as they may seem at first glance.

State changes make the simulator do more work, and as pointed out in Void's post, MONO really doesn't treat them nicely and is actually slower doing a state change then the old LSO. Took liberty of tweaking Sindy's script to show that even if you don't declare a state_entry or state_exit, the simulator still has to process each during a state change:

default {
    state_entry() {
        llOwnerSay((string) llGetFreeMemory());
    }
    touch_start(integer n) {
        state closed;
    }
}

state closed {
    touch_start(integer n) {
        state default;
    }
}

The simulator is actually doing all of this:
"*** state_entry()
GetFreeMemory()
*** touch_start(1)
state->closed
*** state_exit()
*** state_entry()
*** touch_start(1)
state->default
*** state_exit()
*** state_entry()
GetFreeMemory()"

But in most cases the end user is never going to notice a difference in speed using either method and as also pointed out, it is sometimes much more readable breaking a script up into different states and can be more efficient. I have also started to go one step further when I am doing state changes now. In a case where in state_entry I have multiple global variables that have to be declared such as setting a random listen channel, building a menu etc & you don't really need to keep defining them then just add one more state:

default{
state_entry{//globals are declared
state run;
}

state run{
//blah, blah, blah
state next;
}

state next{
//do other stuff
state run;

Now the simulator isn't constantly defining a bunch of vairiables and using llFrand etc when it doesn't really need to.

I LOVE how the post above undemines every claim it makes, proving how useless states are in most cases. Only reason left is readability, because its put in nice blocks. but that doesnt make its logic clearer, its actually obfuscating complex state interactions.

Do you have ANY idea how many bytes each state is wasting in compuiled code, compared to some smart if-conditioning? I dont, because even testing it is a waste of time.

Id rather use ONE 32bit integer as a bitfield to store 2^32 states.
Or 32 states that can run parallel, FUCKING PARALLEL, and 2 small procedures to change states bitwise.
Or a mix of both.
SOME event handlers may check SOME bits of that integer, FLEXIBLE and small.

state changes just mess up mah event queue, but if you want fun timey with events, like someone buying something and waiting to get delivery, being dropped by a state change, have fun with complaints.

kthxbye!

There are valid uses for state changes, but I dont use them a whole bunch really. I have a swing, which sits there and waits for someone to get on it, then it switches to the swing state, where the swing is swung, and checks to see if they got off, if they get off, it reverts back to the default state. It made coding it alot easier. As far as efficiency goes, I guess it all depends on the script. If it's overly complex, states may make things easier, but if it's a simple script, states are more a waste of time. Ollj Oh seems to want to cram 32 flags into an integer, which is pretty silly considering it would make readability difficult even for Ollj down the road. Ollj, if you want to get THAT crazy, why not just code in LSL2 or mono bytecode so you can be even more efficient. There's a line between readability, efficiency, and the necessity of each. I imagine it depends on each particular situation to determine the levels of readability and execution efficiency. When it comes to a simple light switch, even though using states is kind of overkill, it's not going to break the server's back to execute a few extra cycles at most, a couple of times a day. The scripts we write are executed on the server, along with all the other scripts, so we do need to be as efficient as possible, but at the same time, take into account how often this script is going to be executed. Any script, no matter how efficient, is still taking up 16k of memory, and if no events are queued, (it's just sitting there waiting), efficiency doesn't really mean much because nothing is being executed.

For people who learned to code using languages like C and C++, this is pretty much second nature and, once you get used to it, not a very hard thing. It's also, for certain kinds of code, a lot more efficient and far less complicated.

edit: not talking about lsl 'states' above - just talking about using bit flags..

Simple challenge. Script an AO or a flight assist script and post it here with no state changes.

Yes, state changes suck, I stated they suck and why, but they are still necessary sometimes.

It really boils down to what the individual scripter/programmer is happiest with.
Bit packing is second nature (for me at least) and I use it when ever I need too, but as Jesse pointed out states also have their uses.

You could go the whole hog and write each state as a seperate (single state) script, switching state by linked Message. It works and its quite useful in certain applications. It keeps the code modularised and is generally more readable than a multistate script, or smart if's, but does require far more careful handling of data.

*** I'd respectfully request that people moderate their language, it was uncalled for. ***
Newgy has sensitive ears

Welcome back!!

I just write everythjing as a TECO macro...

Wow.. Newgy and Lee posting again. Saw Strife recently, too. And that bozo Jumpman.

You 4 are all alts of each other, aren't you?!?1

I think the example you appear to have been bittin by (changing states while actively dealing with critical requests, and losing those requests) is an example of _bad coding_, not an example of the uselessness of state machines as a code-organization technique.

I think you have to wrap your head around the fact that states (in LSL) are designed to not take events with them. From what I can grok, this is so that you don't have to always be running all of your possible events and switching behavior depending what bits are set before many calls and have your handlers open despite their purpose having been fulfilled. At the end of the day, this serves to improve system load at the cost of memory (although by how much with all the state testing code in a 1-state approach, I can't say), and also to reduce the in-code switching you have to do while handing all of your events. In LSL you can do almost anything you can do with states in some other way, its a cosmetic choice really. Lets face it, some people like ugly just fine.

My experience is that the code bloat caused by not using states and instead manually starting and stopping listeners, testing integers around big chunks of handling inside listen and link message, data server, changed, and permissions events, and trying to clearly depict what the code is doing at the same time leads me naturally to take the 'like chunks' surrounded by the same bit tests and group them all together in a state, wherever possible.

Also Do you mean 1 2^32 integer to store 32 states in one small int like this (if so your code must be... interesting):
integer MYINT;

if(MYINT ^ 1)
else if(MYINT ^2)
.
.
x32

or do you mean 33 2^32 integers to store 32 states in one small int like this:
integer MYINT;
integer STATE1 = 1;
integer STATE2 = 2;
integer STATE3 = 4;
.
.
x32
if(MYINT ^ STATE1)

Er.. I think he meant keeping 32 values in an int..

integer NEWBIE = 0x00000000;
integer FOUND_MAGIC_LAMP = 0x00000001;
integer KILLED_TROLL = 0x00000002;
integer HELPED_OLD_LADY_CROSS_STREET = 0x00000004;
integer TOOK_MEDS = 0x00000008;
integer gStuffDone = NEWBIE;

.
.
.

if (gStuffDone & FOUND_MAGIC_LAMP)
{
llSetGlow (llGetGlow() * 100000);
}

if (!(gStuffDone & TOOK_MEDS))
{
llSetHealth (PARANOID);
}
.
.

I know, my point is its a lot more memory than 1 int to manage that.

...but possibly less than using 32 separate ints.