Limit to Number of States in a Script?

Is there an effective limit to the number of states that a script can have?

I'm scripting an application that requires a specific process of user interaction. It branches out at multiple points depending on user feedback.

I've found that breaking each step of the user interaction up into it's own state makes writing the script much easier, but it quickly escalates into potentially dozens of states.

So, is there a limit I should be worried about hitting? Is there a performance issue if the number of states gets too large?

Thanks!

Scripts have a very limited memory - search this forum for past discussions on the topic (short story: there isn't a reliable way of determining how much memory your script has left). Scripts that run out of memory simply crash with the infamous stack heap collision error, with no chance of recovery.

There are some types, like lists, that use a relatively large amount of memory, so you should not only use those types only when necessary, but use them very carefully too. Strings (string literals - like fixed messages that objects say to users ) take up a lot of memory - I learned that the hard way recently .

As for the a limit on the number of states in an obect - I don't think there is a limit.

You can get around memory limitations since script memory is limited per script - so you can have multiple scripts in a prim which essentially expands your memory quite a bit. The tradeoff is that you need to manage communications between scripts - which adds extra processing and likely more memory since support for inter-script communication is...umm....basic Look into llMessageLinked for more details.

The key question is, of course, when do you know that you need to start using another script? One proven method is trial and error, but beyond that it depends on what your script is doing.

Hope this helps!

-2fast

Hey 2fast,

Thanks for the response (to this and my other question!) I've already used llMessageLinked for a bit of inter-script communication in a different way, but now that you've said this, I can see how using it to split a script in half at certain points may work for me as well! Thanks!

One thing I was hoping you could expand on - where can I find more info on the memory limits of a script. I never really thought that my scripts would take up too much memory, but they do use some lists and a fair number of longer strings for commuication. Any chance you might be able to point me to an example of a script that is just on the borderline of too much memory to crash, so that I could get an idea and compare what I'm doing?

It takes some trial and error - perhaps even some paranoia - to get it right. There is also a cool thread (/54/c1/88658/1.html on optimization in the scripting tips library - Strife Onizuka goes into a lot of detail about memory, speed, etc.

I would not worry too much about it since SL, as a platform, can have a steep learning curve on its own without having to worry about memory issues.

You could use an approach where you, for example, keep most of your strings (and llSay, llInstantMessage,llEmail, etc) in one script and the core functionality in another script. That approach is likely to address a very large percentage of the stack heap collision errors that occur as a result of insufficient memory.

It may be too much in some cases, and could become tedious at other times, but it is a good approach since it mitigates the risk of having to deal with memory issues as your script grows (assuming you design and code at the same time - which is *really* bad, but that is another conversation ).

-2fast