State change weirdness

Here's a simple code snippet

default
{
    state_entry()
    {
        llSay(0, "Hello, Avatar!");
    }

    touch_start(integer total_number)
    {
        llSay(0, "touched");
        state foo;
    }
    
    state_exit()
    {
        state bar;
    }
}

state foo
{
    state_entry()
    {
        llSay(0, "in foo");
        state default;
    }
}

state bar
{
    state_entry()
    {
        llSay(0, "in bar");
        state default;
    }
}

The "touched" msg is output once, and then the script seems to go into never-never land. Neither foo's nor bar's state_entry msg are output, and no more touch events are registered.

The wiki is down, so I can't look this up, so perhaps somebody else knows... Is this proper behavior? Is re-directing a state change from inside of "state_exit()" taboo?

- Ace

Huh, the wiki doesn't seem to mention anything at all about this particular situation. Weiiiiird stuff. I guess the poor thing is getting confused where it's supposed to be going.

Oh, you can still get the wiki here, btw.

Is this what's called "pathological code"? I don't see what you are trying to achieve, if anything.
Or was it just for testing LSL behavior to weird code?

The example is pathological, but solely because I tried to simplify the issue for my original post.

My motivation is that I have a rather complex set of logic that I need to evaluate to determine which of 2 states I need to go to, and I need to initiate this state change from quite a few points within my code.

Since you can't do a state change from within a function, I thought I'd do it this way. By default, I go to state foo, but in my state_exit code, I wanted to execute my logic and determine whether I really want to go to state bar.

If you or anyone else can suggest another approach, other than the obvious of putting my logic everyplace I need to make this decision, then I'll be a happy camper.

- Ace

It's called a minimal test case, and it's what you should reduce your program to when encountering unexpected behavior, so that the bug hunters may be able to track down the bug more easily.

create a 4th state ("redirect" and a global variable of type int:

integer STATE_FOO = 1;
integer STATE_BAR = 2;

integer target_state;

default
{
    state_entry()
    {
        target_state = STATE_FOO;  // set default next state
        llSay(0, "Hello, Avatar!");
    }

    touch_start(integer total_number)
    {
        llSay(0, "touched");
        state redirect;
    }
    
    state_exit()
    {
        target_state = STATE_BAR;  // change next state on-the-fly
    }
}

state redirect
{
    state_entry()
    {
        if (target_state == STATE_FOO)
            state foo;
        if (target_state == STATE_BAR)
            state bar;
    }
}

state foo
{
    state_entry()
    {
        llSay(0, "in foo");
        state default;
    }
}

state bar
{
    state_entry()
    {
        llSay(0, "in bar");
        state default;
    }
}

*smacks self upside head*

I don't know why I didn't think of this at first. The solution is rather simple. I just need to create a function that does all the logic, and then returns a value indicating which way to go.

integer   NEXT_STATE_FOO = 0;
integer   NEXT_STATE_BAR = 1;

integer complexStateChangeCode()
{
    // code to figger out which way to go
    if ( logicSaysFoo )
        return NEXT_STATE_FOO;
    else
        return NEXT_STATE_BAR;
}

...

//  inside my algorithm, wherever I need to make the state change, I just change
//  what was simply 'state foo;' to :

if ( complextStateChangeCode() == NEXT_STATE_FOO )
    state foo;
else
    state bar;

I still have to have a single conditional at every state change, but that's a whole lot simpler than having my "complexStateChangeCode()" all over the place.

Anyway...

I'll report my simple case as a bug, and let the forum know what response I get from the Lindens. I may be told that this is expected behavior... or at least told that redirecting a state change inside of 'state_exit()' is a no-no.

- Ace

It's probably not a capital B-Bug, consider, what would you expect to happen here:

default{
touch_start(integer n) {state bar;}
state_exit() {llSay(0, "hi"); state foo}
}

state foo{...}
state bar {...}

I would expect that it hits the state_exit event, says "Hi", starts to change to state foo, which triggers a state_exit event, so the state_exit handler is called, says "Hi", starts to change to state foo, which triggers a state_exit event, so the state_exit handler is called, says "Hi", starts to change to state foo, which triggers a state_exit event, so the state_exit handler is called, says "Hi", starts to change to state foo, which triggers a state_exit event, so the state_exit handler is called, says "Hi", starts to change to state foo, which triggers a state_exit event, so the state_exit handler is called, says "Hi", starts to change to state foo, which triggers a state_exit event, so the state_exit handler is called, says "Hi", starts to change to state foo, which triggers a state_exit event, so the state_exit handler is called, says "Hi", starts to change to state foo, which triggers a state_exit event, so the state_exit handler is called, says "Hi", starts to change to state foo, which triggers a state_exit event, so the state_exit handler is called, says "Hi"...

I saw some code that suggested that a "state" could have a return. Is that possible?

default
{
    state_entry()
    {
		//first time initialization only such as after insert/delete save
    }
	on_rez(integer start_param)
	{
		//do things in here that you need when initializing from a rez
	}
	//do things here to control activities
	if (integer bla)
	{
		state one;
		//do something else here after the return
	}
	else if (bla == 2)
	{
		state two;
		//do something else here after the return
	}
}
state one
{
	//something happens here
	//when done... return?
	return;
}
state two
{
	//next sequence happens here
	return;
}

yeah I know that looks crazy... but is something like that possible?

Yes.

Can you say "infinite recursion"?

I knew you could.