Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Using multiple States for switching - Newbie question

Rob Figtree
Registered User
Join date: 13 Jun 2006
Posts: 14
08-04-2008 21:51
As a scripting newbie, I was looking for a good way to build a switch. Simple on/off or stepping (such as Off, Low, Medium & High). I was looking at If-Else statements which seemed the most popular choice in the little bit of code that I have analyzed. Then I found a tutorial using states in a way that amounted to on and off. (it was at http://www.instructables.com/id/Getting-started-in-LSL-scripting-in-Second-Life/ ).

Here is the script I ended up using for my on/off switch:

default
{

state_entry()
{
llSetColor(<0,0,0>, ALL_SIDES);
}

touch_start(integer not_used)
{
state on;
}

}

state on
{

state_entry()
{
llSetColor(<1,1,1>, ALL_SIDES);
}

on_rez(integer not_used)
{
state default;
}

touch_start(integer not_used)
{
state default;
}

}

I don't see any reason why this can't be extended for however many steps I need in any switch. Although I did add a step to reset to off if the object was rezzed in the "on" state.

My question is: would it be more efficient from a programming point of view to use the If-Else option to do the switching? Or maybe I should say from a system point of view. Which would run better in the system?

It may be one of those things that doesn't really matter or more depends on the particular functions that might be contained at each point in the script.

A couple ancillary questions: is state persistent? That is, if on object is taken into inventory, will it always be the state it was in at the time it was taken into inventory whenever it is rezzed in-world again? Or is that not a function of state, but the way any script would work.

A second question: Did I just get lucky with the code (since it does in fact work) or is it correct to have two events set together and let the program branch based on which event occurs?

As noted in the title, these are newbie questions. I might as well try to learn the best way if I am going to try to learn this stuff.
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
08-04-2008 22:01
it can be extended to a point, your gonna run out of memory quicker than using a counter and else if's

in my point of view state switching is clunky confusing and in more difficult scripting tasks where sync is important mostly useless, is it officially more efficient?...

if you do else if's it checks the first clause then every clause after that until the statement returns true

lets say you have 1 thing at script start that ask's a question and never asks that question again untill another script start then 2 states is more effecient, cause your not always testing for the question thats being asked only once

yes a state is persistent

and yes using mutiple states, if you want to script to reset or default you need an on rez event for every state, thats more code, more memory and more typing, but again if the benefits of multiple states is valid then its worth it

in your example code its not

CODE


integer switch = 0

default
{
on_rez(integer nu) {llResetScript();}
state_entry(){llSetColor(<0,0,0>, ALL_SIDES);}
touch_start(integer nu)
{
if (switch)
{
llSetColor(<1,1,1>, ALL_SIDES);
switch = 0;
}
else
{
llSetColor(<0,0,0>, ALL_SIDES);
switch = 1;
}
}
}
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
08-04-2008 23:44
I suggest using different states when your script logic gets large and cumbersome and can obviously be divided into a couple of major...well, states. If in doubt, look for large differences in what SL events your script is going to respond to.

For example, both of your states basically do about the same thing for the 'touch_start' event and nothing (aside from the logic made necessary by using multiple states) for any other events. So this is probably NOT a good candidate to do with multiple states.

Examples of situations that would be better suited to state switching would be where you must do some configuration (like reading a notecard or querying a database) before you start responding to user input, or you are going to ignore chat messages for a period of computation, or something along those general lines.
Johan Laurasia
Fully Rezzed
Join date: 31 Oct 2006
Posts: 1,394
08-05-2008 00:13
I agree with Osgeld, you're better off not using states unless you're going to have different functions for the same event type. For example, in one 'mode' touching the object does one thing, in mode 2, it does another. That's the best time to use states rather than a simple switch. Osgeld's example would be the most efficient method, easier to read as well since there's less code and only the default state.

http://www.secondscripter.com
_____________________
My tutes
http://www.youtube.com/johanlaurasia
Very Keynes
LSL is a Virus
Join date: 6 May 2006
Posts: 484
08-05-2008 01:32
and if you dont want to use states or If/Else tests try

CODE

integer mode;
default
{
on_rez(integer nu) {llResetScript();}
state_entry(){llSetColor(<0,0,0>, ALL_SIDES);}
touch_start(integer nu)
{
llSetColor(<1,1,1> * (mode=!mode)), ALL_SIDES);
}
}


if you are not concerned with the inital state then its almost a 1 liner

CODE

integer mode;
default
{
touch_start(integer nu){llSetColor(<1,1,1> * (mode=!mode)), ALL_SIDES);}
}