Jump to content

I'm bored, lets debate something, STATES!


Ichi Rexen
 Share

You are about to reply to a thread that has been inactive for 1922 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

So, lets have a random debate or conversation, whatever you want to call it. The title is "States and are they REALLY worth using". My personal stance on this is that while some may feel that states have their place I do not see any point in using a state when there are other methods to achieve the same ends and usually end up coming in at a lower script memory cost. And I have yet to find a problem to solve that can't be fixed by say using booleans to manage the different operations of your script as opposed to constantly switching back and forth between 2, 3, 4 different states. I also find the use of states to be cluttered and usually resulting in much unnecessary code. Let's start with a very basic example, a script that outputs text telling us if a door is open or closed.

Using states we have

default{
    state_entry(){
        llOwnerSay("States : "+(string)llGetFreeMemory());
    }
    touch_start(integer x){
        llOwnerSay("The door is now open");
        state open;
    }
}
state open{
    touch_start(integer x){
        llOwnerSay("The door is now closed");
        state default;
    }
} 

This has a free memory count of : 61148

 

Using bools we have

integer dSwitch=FALSE;
default{
    state_entry(){
        llOwnerSay("Bools : "+(string)llGetFreeMemory());
    }
    touch_start(integer x){
        if(dSwitch){
            llOwnerSay("The door is now closed");
        }else{
            llOwnerSay("The door is now open");
        }
        dSwitch=!dSwitch;
    }
}

This has a free memory count of : 61652

 

We can see here that there is a saving of roughly 500b by using bools instead of using states. Now, before you jump on it, I am more than aware that memory count in a script is subject to many different things that are going on in the script and can change frequently depending on what the script is actually doing. However in this example I feel it gives a good indication of the potential difference in script memory cost between the two methods. I am also aware that this is a very basic example and I specifically chose a basic example to start the conversation with the intention that I or others may want to add more advanced examples as the conversation progresses, if it progresses at all, no one might comment in which case boo to you all (I am just joking :) ) 

But what are you thoughts?. Are states worth it?, are there situations where states are truly useful or are you better off using other methods to achieve the same ends?. I am rather curious to hear your thoughts on this subject.

 

---Sub note---

I am not directly accusing anyone but I have noticed over the last week there does seem to have been discourse between some of the users of this forum. I am seeking nothing more than an interesting discussion on the subject of states and the practicality of their uses. Purely from a point of interest and also boredom ^_^.  All opinions are valid and welcome :).

Edited by Ichi Rexen
Meant to write b but wrote kb
Link to comment
Share on other sites

States have a specific usage. Would be more interesting if it was about the common usage of functions with less than five lines taking up 1/2KB for no reasons what so ever. Or the utter wastage of fifty lines of garbage defining globals that are local variables.

Edited by steph Arnott
typo
Link to comment
Share on other sites

7 minutes ago, steph Arnott said:

States have a specific usage. Would be more interesting if it was about the common usage of functions with less than five lines taking up 1/2KB for no reasons what so ever. Or the utter wastage of fifty lines of garbage defining globals that are local variables.

What in your opinion is their specific usage. Can you give an example of where a state is superior to other methods?.

3 minutes ago, steph Arnott said:

And BTW that is not saving 500kb. A script only has 64kb max.

Thats a typo, I corrected it. I know how much memory a script has. Thank you for pointing it out though

Link to comment
Share on other sites

Just now, steph Arnott said:

Sorry, you need to count the bytes used because it is no where neare what you now claim. States are used for containment. Logic in a script is too rigid to be without states.

61652 - 61148 = 504 bytes

I ask again, for the purposes of an interesting discussion. Can you provide examples of where states are more useful than other methods to achieve the same ends?. You say containment, okay can you give an example. What in your opinion is a use for states that cant better be achieved by other methods?. 

 

Link to comment
Share on other sites

I have, They are for containment. A 'state' is a lockout of the main. Your claim that a you have save 500bytes is arrant nonsense. The next state is only an off branch of the main. A function on the other hand is alocated 512bytes no matter what is in it. No it is not interesting because you clearly have no idea what a state is.

Link to comment
Share on other sites

I almost never use states except to control the set of events the script should be handling. Most typical is when touch-related events need to be processed sequentially -- no more clicks until I know what I'm going to do with this one -- during which processing I want the viewer not to show the little "touchable" paw mouse cursor.

Another case of this is when the script finds itself in an unrecoverable condition. For example, at startup a script may scan the linkset for critical components (identified by name or description or whatever), and if it doesn't find them it needs to stop processing any other events at all while waiting for the user to fix stuff, so it's handy to transition to an error state that exits back to the default state_entry upon CHANGED_LINK. 

State change is also handy (or confusing) for tacitly flushing the event buffer, removing all listens, and halting sensor repeats. I have to look up which events are and aren't removed pretty much every time I use states.

  • Like 1
Link to comment
Share on other sites

3 minutes ago, steph Arnott said:

I have, They are for containment. A 'state' is a lockout of the main. Your claim that a you have save 500bytes is arrant nonsense. The next state is only an off branch of the main. A function on the other hand is alocated 512bytes no matter what is in it. No it is not interesting because you clearly have no idea what a state is.

1. I stated that memory counts are not always reliable because of different things the script might be doing / have in it etc etc. 

2. Given that one script is using a state and the other a bool and yet there is a clear difference between the two in memory usage, if we use the values given then surely the free memory function must be taking more than just its default state into account because otherwise the use count in the bool script would be higher than in the state script as there is more going on in the default state in the bool script than in the state script. There for it seems logical to deduce that the bool script is taking up less memory than the state script.

3. I am more than aware that a states are their own individual separate contained, lets call them "sections of code", that have their own separate contained events etc etc. But, if you feel that I do not understand states in the way that you do then perhaps add to the discussion and explain them. Theres no need to come across so hostile at the end.

Link to comment
Share on other sites

14 minutes ago, Qie Niangao said:

I almost never use states except to control the set of events the script should be handling. Most typical is when touch-related events need to be processed sequentially -- no more clicks until I know what I'm going to do with this one -- during which processing I want the viewer not to show the little "touchable" paw mouse cursor.

Another case of this is when the script finds itself in an unrecoverable condition. For example, at startup a script may scan the linkset for critical components (identified by name or description or whatever), and if it doesn't find them it needs to stop processing any other events at all while waiting for the user to fix stuff, so it's handy to transition to an error state that exits back to the default state_entry upon CHANGED_LINK. 

State change is also handy (or confusing) for tacitly flushing the event buffer, removing all listens, and halting sensor repeats. I have to look up which events are and aren't removed pretty much every time I use states.

Interesting response. Iv never actually used them to flush the event buffer although thats a pretty neat way to do it thinking about it.It would save in having to write out multiple listen removes to clear out listeners, I will happily accept that as one valid use for states. I do feel there might be another way to do your link set example. Your other examples are interesting though. I had a similar problem a long time ago where I had an object scanning a link set and linking up names with link numbers. Mainly so I didn't have to continuously link things in a specific order. The way I got around the issue of it not finding specific links that it should was to set a bool to FALSE and then return on any further processes with an error message and await a touch user input that could only be activated after this bool was set to FALSE to reset and try again. Your method is interesting though and I will also take that as a valid use of states in this situation.

Edited by Ichi Rexen
Moved a sentence around
Link to comment
Share on other sites

3 minutes ago, Ichi Rexen said:

Interesting response. Iv never actually used them to flush the event buffer although thats a pretty neat way to do it thinking about it.It would save in having to write out multiple listen removes to clear out listeners, I will happily accept that as one valid use for states. I do feel there might be another way to do your link set example. Your other examples are interesting though. I had a similar problem a long time ago where I had an object scanning a link set and linking up names with link numbers. Mainly so I didn't have to continuously link things in a specific order. The way I got around the issue of it not finding specific links that it should was to set a bool to FALSE and then return on any further processes with an error message and await a touch user input that could only be activated after this bool was set to FALSE to reset and try again. Your method is interesting though and I will also take that as a valid use of states in this situation.

You are aware that the server can be running code on objects inworld while your main script has exited that state? There is a reason why lockout code is used. Simply dropping a basic 'yes no' few byte code as the reason not to use states is plain silly. I used to think state changing was a failure in good coding, well no it is not. It is a failure to understand how the code is running.

Link to comment
Share on other sites

8 minutes ago, Love Zhaoying said:

I have written a bunch of scripts, and generally have little use for different states; main concept is each state can have totally different events. 

Try a system where logic switches conflict due to complexity. Your simple one state will fail. States are used for specific purposes but even a basic script does not add to the memory usage as was claimed. In fact even basic state switch can clean up traps.

  • Confused 1
Link to comment
Share on other sites

9 minutes ago, steph Arnott said:

Try a system where logic switches conflict due to complexity. Your simple one state will fail. States are used for specific purposes but even a basic script does not add to the memory usage as was claimed. In fact even basic state switch can clean up traps.

I suppose you’re right, I’ve just never needed to. 

Link to comment
Share on other sites

Just now, Love Zhaoying said:

I think the point of my comments earlier are: maybe someday I will use states. I construct my scripts in such a way that they work just fine with a single default state.

We all want them in a single state but not allways possible. The issue with the OP also forgets learners. A learner has no idea what this even means. And LSL is ment for none coders to have fun and learn basics.

dSwitch=!dSwitch

 

Link to comment
Share on other sites

8 minutes ago, steph Arnott said:

We all want them in a single state but not allways possible. The issue with the OP also forgets learners. A learner has no idea what this even means. And LSL is ment for none coders to have fun and learn basics.


dSwitch=!dSwitch

 

This conversation wasn't specifically aimed at beginners, although they are welcome to join it. It was more for those with more experience to discuss the pros, cons, usefulness of states. But, in terms of how I switched the variable in the code example there is nothing to stop a learner posting in this chat and asking "Hey what does that mean, I have never seen it before" and then someone else responding "In programming the ! symbol is called Logical NOT and you use it like that to switch a variable between 1 and 0, to learn more -insert wiki link here-". Part of learning to code is asking questions, seeing and learning new things from what you have seen that you might not otherwise have known about and then playing with those things to see what results may emerge. 

Edited by Ichi Rexen
  • Thanks 1
Link to comment
Share on other sites

Just now, Ichi Rexen said:

This conversation wasn't specifically aimed at beginners, although they are welcome to join it. It was more for those with more experience to discuss the pros, cons, usefulness of states. But, in terms of how I switched the variable in the code example there is nothing to stop a learner posting in this chat and asking "Hey what does that mean, I have never seen it before" and then someone else responding "In programming the ! symbol is called Logical NOT and you use it like that to switch a variable between 1 and 0, to learn more -insert wiki link here-". Part of learning to code is asking questions, seeing and learning new things from what you have seen that you might not otherwise have known about. 

Well you got your fundimental facts wrong. A state change does not change memory allocation. Also '!' does not mean 'NOT'. So you have no clue as to what you are posting. '=!" is an 0 or 1 comparison. Each side in LSL is compared and a result produced.

  • Sad 1
Link to comment
Share on other sites

States can be handy as a way to isolate one set of operations from others.  While that may not make a script more compact, it can make it easier to manage conceptually.  It can also give you functional modules that can be lifted out and plugged almost verbatim into other scripts -- a timesaver if you do a lot of scripting.

I will often use the default state as a place for assigning initial values, building internal lists of important links, reading configuration data from notecards or KVP, and whatnot.  Those sorts of things need only be done once, so it's handy to put them in a state that will only be executed when the script resets.

If I am creating a vendor system, I will often use one state to handle the way a user browses through products and then put functions related to money in a second state.  The two sets of operations are best kept separate anyway, so that there's no confusion about what the buyer is paying for.  Although I could easily code everything in a single state, a modular approach forces me to be sure that product selection (with any options about size, color, delivery method, etc) is complete before a money event is available for the buyer.

I could come up with plenty of other examples.  The bottom line for me is making a script clean and easy for me to follow when I come back to it months later or when I am trying to debug some strange behavior.  I don't want to have to chase all over a long script to remind myself of the flow of logic.  If I can isolate my later questions to a single modular state, I am much happier.

  • Like 4
Link to comment
Share on other sites

33 minutes ago, steph Arnott said:

We all want them in a single state but not allways possible.

Can you give an example of some kind of logic that cannot be done without multiple states?

 

14 minutes ago, steph Arnott said:

NOTICE THE STATEMENT '=!' just because you used a gap it is stil '=!".

"=!" is not an operator. It is two operators; "=" (assignment) and "!" (logical not).
"!=" is an operator. It means "not equal".

  • Like 3
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1922 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...