Common code used used in events, but can't call STATE changes from functions?

Hi,

Wonder what a good design approach would be for the following:

I have common functionality I'll like to trigger from both TOUCH and COLLISION events. The code does have places where STATE may be changed. If I extract this out to a common function I get a "can't make a state change from a global function" error (i.e. an LSL constraint it seems).

[1] What's a good design approach here?

[2] Is there a way perhaps to trigger one event from another, e.g. put all code in COLLISION event, but then trigger this from the TOUCH event?

[3] If no, then the functions will have to pass back return values with the STATE change occuring within each event I guess. I don't suppose there is a way to pass back from a function a STATE VARIABLE, so in the event I can change state directly using this return result, e.g. "state (getNextState());"

Tks

nm my solution doesnt address the issue

I think I'm in the minority of LSL coders, but I always read "state" as "particular collection of event handlers" and consider the script state to be a combination of globals and LSL state. This then divides the CompSci concept of state as to combinations of data and location. You then get constuctions like:

integer gMode = READING;

state fly {
    ...
    if(gMode == READING) 
         state land;
    else
         state swim;
    ...
}

otherwise you can use the idiom:

integer commonCode() {
    ...
    return ChangeToFlyUponReturn;
    ...
    return ChangeToLandUponReturn;
    ...
    return ChangeNoneUponReturn;
}

With the relevant if ... else chain in the caller of commonCode().

Hope that helps.

if you want you put a state change in a global function - not an event use the following


if ( 1 == 1 ) { state new_state ;}

Not pretty but it works.

eg

init()
{
    if ( 1==1 ) {state ready;}
}
default
{
    state_entry()
    {
     init();
    }

.
.
.
.

bools are integers so instead of 1==1 all you need is 1 so if(1) will work, actualy the number can be any non zero or NAN integer or float.

I've heard bad things about this. The only reason this works is because the compiler only "notices" a state change in a function if it's not inside an if or else or loop. I'm sure there's a REASON they tried to avoid allowing state changes in a function, but apparently this construct slips through the cracks. I've heard of people blowing up their stacks, returning from a function into an event handler in the wrong state, etc... don't do this.

In a large project I did, I had the need for many different states, and for "dynamic" state-changes depending on function returns and such. What I really wanted was to be able to store a state name in a variable, then change state based on the contents of that variable. Not possible, but what I could do was to have a global string variable called "nextState" and store state names in that. Then I'd switch state to a "stateChange" state, which would look at the value of nextState and immediately switch to the appropriate state. The stateChange state was switched to from all over my code, essentially treating it as a subroutine in its own right. A bit messy, but not going to blow my stack up!

Wow - I just knew it was going to be worth asking this forum Thanks for this gem, a hack? feature? exploit? or whatever it is

This also sounds like a good idea, specially if the trick above isn't part of the LSL spec and as such it could stop working in future versions. The variable could be set to "" or "currentState" after a change of state, then at the end of each event you just call checkNPerformStateChange().

agreed - remember that the ability to change state within a function is an LSL bug. One which may be repaired at any time - which would break any scripts exploiting it.

...which would pretty much go entirely against LL's policy of not breaking existing content (save the really problematic cases, such as llRemoteLoadScript). And I have a feeling this would break a lot of content.

That said, I agree that it's best to avoid changing states within a function, both out of error avoidance and out of good program design.