Better to use states or not?

and purple is a color.

Yes possibly less than 32 integers to store and deal with 32 states, if you consider mixtures of states to be states themselves. For example I might be moving && flying, and you might suggest that this means I am capable of uniquely handling another state that we will call flying_but_not_stationary without any additional information.

I yield!

But the OP was talking about storing and presumeably dealing with 2^32 states, so I think my example was understated. Thats a lot of states to manage in 32 integers, but you're right to note that my response was flawed in that I was only addressing 32 states, and not the 2^32 being discussed.

Lets back up a bit.

I was getting at the difference between writing an LSL script and storing unique numbers in an integer. In fact my intention was to suggest that the former comes with non-trivial overhead (in terms of code, maintainence, and certainly if/else bloat) above and beyond the number of bits used to store the unique current state of the system. So while 2^32 unique combinations of bit information might be possible, doing 2^32, or even 32 unique things in a non-trivial LSL script based upon that one integer is highly unlikely at best, and in all probability, downright foolish.

(patiently waiting for Meade's response)

Sorry - I've lost track of what everybody's trying to say, including myself, and have moved on.

Though I will say that "purple" isn't really a color per-se. It's more of a range of color combinations, usually mostly red and blue.

LMAO, I was refering to the discussion with Shadow. Kind of interested in how people were doing it with the packed integer. Understood half of your example pertaining to if tests but still lost as to how someone is doing this with states/or parallel states.

In other words, I too don't see any value added and was hoping I misunderstood something and could learn something new. Love to learn new stuff!

EDIT: BTW, I already washed my mouth out with soap this morning Newgy!

I think the argument has reached the point of absurdity. No one is going to try to replace all the possible bit-states of global variables with an enumerated list of states. No one is seriously going to recommend hundreds of states, and probably won't even go so far as 32. States are clearly not useful when you have more than a small handful of well distinguished behaviors. The question is whether they are useful in that case. The consensus SEEMS to be that they are, but either way that's a situation in which I know I will continue to use them. When I really want to optimize performance for some reason I might consider changing my normal style regarding states, but even in LSL I find that human optimization is rarely a very high priority (I didn't say "never".

I think some of the confusion comes from page 1...

On the first line, he talks about an int having 2^32 values which sounds (to me anyway) more like an enumeration than a bitmask.

There's also (non-PG) talk of running stuff in parallel. If you want to do this and you're _not_ going to split the script up into several smaller scripts, having some bitmask of what states are currently valid makes sense. Using an enumation makes less sense (again, to me) as it sorta implies a single value instead of multiple values implied by a bitmask.

Thanks Ms Hedgehog!

Yep that was the line. Still don't really understand how it is possible to run multiple states in the same script at the same time. But then again kind of defeats the purpose of the way I am using states anyways. So I guess I'll just move along now

You can't be in multiple LSL states in the same script at the same time. It just can't be done.

What Meade is probably talking about is something where you have a single LSL state in a script but have a global bitmask variable and some constants that represent different states. When the script does stuff, it could do something like this:

integer     gStates = 0;
integer     STATE_A = 0x00000001;
integer     STATE_B = 0x00000002;
integer     STATE_C = 0x00000004;
integer     STATE_D = 0x00000008;
integer     STATE_E = 0x00000010;
integer     STATE_F = 0x00000020;
.
.
.
    if (gStates & STATE_A) { DoStateA();}
    if (gStates & STATE_B) { DoStateB();}
    if (gStates & STATE_C) { DoStateC();}
    if (gStates & STATE_D) { DoStateD();}
    if (gStates & STATE_E) { DoStateE();}
    if (gStates & STATE_F) { DoStateF();}
CODE

Maybe in a timer or something. 

I don't think she was suggesting that this should be done, just that it could be done. With the LSL memory limit, each pseudo-state wouldn't have a lot of room to work with..

sure you can load bit flags in a single integer, effectively replacing multiple states with a single global and tests in your event handlers (assuming the events are 'state' specific)

the bonus of having states are the same as modular programing, break up code into manageable chunks groups based on what they do/respond to. a state doesn't need to check before it fires event code, if it exists it fires, no test needed.

the other benefit is that you can auto cancel some actions (clean up listens, stop sensor repeats) and have clearly defined blocks that may have their own initializations or clean up (state entry and exit).

on the downside if you have a situation where the same code needs to be handled in multiple states, you end up either repeating code or making it a function which can add complexity if it uses many variables. bitflag globals would fix that, but add the complexity of a test (or more) to each handler that doesn't behave the same in all states.

in mono as I mentioned above, it may be that only the current state is actually in active memory, so state programming would reduce memory load on the sim even further... but that's a lot of assumptions that are nigh impossible to test...

::notices lots of old faces showing up... waves:: =)

I kinda skimmed over this, but my basic take on LSL states is that they are best used for when the overall behavior of the script changes significantly to radically. IE, one use of states I have is when a vendor goes from a config mode to an operate mode. I don't want people paying my vendor until it is fully configured and ready to accept money, so the config mode doesn't have a money() event, but the operate mode does.

Things as simple as flipping a boolean, and the behavior associated with that, I don't think are good uses of LSL states. Basically it comes down to a "micro" vs "macro" behavioral difference.

State changes do come with a bit of execution overhead, as measured by others. (gads, I hope mono doesn't do JIT for state changes O.o )

Just a quick clarification on something else said, *events* are not persistent across states, though *event triggers* may be. IE, in the case of timers, a timer event in one state will not be triggered in another state (that does not have a timer() event), even though the trigger is still active. As soon as you enter another state with a timer() event, the timer will start firing again, without having to call llSetTimerEvent() in that state.

good thing you guys got that one about the integer bitfield states.
now learn how to use binary operators to save some more memory (maybe or not) and have more flexibility (definitely), here some more basic bitfield masking:



integer states=0xABCDEF01;//I am hexadecimal and many states at once.
integer maskl (integer l){return 0x7FFFFFFF>>30-l);} //mask from 0 to l[0..30] (indexing starts at "0" and ends at "31"
integer maskr (integer r){return 0x80000000>>31-r);} //mask from r[0..31] to 31 //I dont use this one. and i know that the "-" operation could be avoided by thinking more in machine code than in 4th class math.
integer marklr (integer l, integer r){return maskl(l)&maskl(r);}// mask from r[0..30] to l[0..31] (wich one is wich should not matter as long as only maskl is used in it.
integer marklr2 (integer l, integer r){return maskl(l)&maskr(r);}// mask from r[0..30] to l[0..32] //again i never needed this one.
integer masks (integer s){return maskl(s)&maskl(s);}//mask of the single bit s[0..30] //this saves one integer in every call and saves bytes if its going to be called often.
integer masks2 (integer s){return maskr(s)&maskr(s);}//mask of the single bit s[0..31] //alternative if you really need the leftmost byte like all others and not thread it as "special" as itwants to be.

if(states&maskl(5)){llOwnerSay("im in one of the first 6 states (idexing still starts at 0) ";
if (states&maskl(3)) llOwnerSay("im in state 3 to be more exact";
else llOwnerSay("im in state 0,1,2,4, or 5 to be more exact";
}else if (states&masklr(30,31)) llOwnerSay("im in state 30 or state 31";
if (states^maskls(10,9))llOwnerSay("i am NOT in state 10 and not in state 9, but I am in any of the other 30 states (this also checks for the leftmost bit)";



And just as the "states" integer can be changed bitwise or with other math, the numbers in the procedure calls can be changed procedurally, and this is where the fun begins, especially in loops and recursive functions...

also, an ascii character can store 6 bits/states and a 16 bit character stores 15 bits/states, this may save a little memory if you want to store over 64 independent states AND already store bitfields that are over 2000 bytes long (like long tables or lists of keys) with some kind of base64 encoding, which WILL be an option when MONO increases the script size.



???Now, why could we possibly need over 64 independent states on one script???
For example, an NDS Pokemon (or anything with a battle hud) can be influenced by many different "conditions" (and by multiple combinations of them at once) that are basically "states" with special effects such as:
imprison,Torment,Confused,Substitute,Razor Wind/solar beam/skull bash/charge,Fly,Bounce,Dive,Shadow Force,Hyper Beam,Future Sight,Doom Desire,stockpile,rollout,Freeze,Paralysed,Burned,Poisoned,Attracted,Leech Seed,Curse,Flinch,Foresight,Nightmare,Mean look,Stealth Rock,Embargo,Worry Seed,Mud Sport,Gastro Acid,Water Sport,Flash Fire,Defense Curl,Focus energy,Minimize,Mist,Ingrain,Pursuit,Healing Wish,Lunar Dance,Spikes,Toxic Spikes,Baton Pass,Outrage,Badly Poisoned,Disable,taunt,Magma Storm,bind,clamp,fire spin,wrap,whirlpool,sandtomb,uproar,encore,Gravity,Sleep,bide,Mind Reader,Perish song,Wish,Counter,follow me,magic coat,helpinghand,Snatch,Grudge,Destiny Bond,Endure,Protect/detect,yawn,rest,Tailwind,Magnet Rise,Heal Block,Lucky Chant,Light Screen,Reflect,saveguard,Trick Room,weather

And many of them store a small value for a timer from 0 to 3, therefore they are more than 1 bit in size, so the "state" of a pokemon in battle actually eats 165 bit just to store what it is affected by at the moment, not counting its hitpoints, skills, IV, type, item....

/me mumbles something about call overhead and wanders off again.

Hmm. Well yes, we "got it." Do you "get" that we are talking about the LSL language mechanism that aids in implementing the equivalent of a UML state diagram? It is a useful tool, and one that is not designed to replace all of a program's memory state. Please kindly spend some time actually reading the responses to your post rather than talking down to the competent and experienced programmers on this forum.

OP says: I got my answer many posts back.
You people just carry on, it's interesting anyway.

/me moves hand palm down over head towards back and makes jumbo jet noise.

But It's way over my head!

LMAO. Don't ever expect just a couple of responses when you use the terms "better" of "best" in the thread subject in the Scripting Forums. Three ongoing, related threads right now all dealing with optimization. This subject is always a powderkeg waiting for a match. But even thou tempers may flare every now and then, it is still an incredibly important topic and helps all in the end.

LOL! yeah, all the egos have come out to play now.

/my ego beats up Chaz' ego and takes his lunch money.