Jump to content

Recalling state_entry/state recursion


Tommy Rampal
 Share

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

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

Recommended Posts

To my understanding and experience, calling a state within the same state does not call state_entry; I've tried using jumps and targets but they seem to cannot break the event barrier; and finally I cannot reset the scripts, as I lose precious memory saved in global variables.

What other (practical/optimal) alternatives can I take to get the result I want without adding unnecessary lines of code?

E.G.

default
{
    state_entry()
    {
        //CODE GOES HERE
    }
    touch_start(integer num)
    {
        state default; // To save future errors and unnecessary code
    }
}

 

Link to comment
Share on other sites

And be sure that you use touch_end to get to that new state, not touch_start

default{     state_entry()     {          // Saved stuff     }     touch_end(integer num)     {          state running;     }}state running{     state_entry()     {          state default;     }}

 If you're worried about preserving values of key variables in case of a script reset, you can also store them in the name or description fields of prims in the linkset, as well as in various prim properties (color, alpha, etc.).

Link to comment
Share on other sites

If you want to do all the initialisation that normally happens in state_entry somewhere else in the state as well (the attach event, perhaps),  one popular way to do it is write a simple user function, init(), and open listeners, give initial values to global variables and so on in that.    Then you can call it in state_entry and anywhere else you want.

Link to comment
Share on other sites

I do not recommend doing this, the other methods and advice are better, but there may be a use for this structure somewhere....

kickBack(){    if (TRUE) state default;}default{    state_entry(){        llOwnerSay( "Hi" );    }        touch_end( integer vIntTch ){        kickback();    }}

 

Link to comment
Share on other sites

Rolig, am I correct to assume that it's wrong to use touch_start when calling states because not only will it trigger the state change, it will also trigger touch_end (if used) in the new state?

Also, I am also skeptical on memory and performance; would having a slave state to substitute a recursive state drink memory and response times? How is that compared to having an init function? Forgive me I haven't really studied the memory side of LSL.

Link to comment
Share on other sites

If you change states in a touch_start event, there is a possibility that touch_end may be triggered in the new state instead of the old one.  It's cleaner to consider the entire touch action in one state.  You can get buggy behavior otherwise.

As for the speed/memory implications of a state change rather than a user-defined function, I'm not the expert.  Void is.  From my purely empirical perspecive, though, I can't believe that it makes much difference which option you choose.

Link to comment
Share on other sites

touch end woun't be triggered off the same touch (any event in the chain not already fired will be discarded by state change). in the receiving state, the NEXT event chain of that type will not trigger because the chain was broken before, but that will reset the chaining and the one after that will work.

if there is no event chain of that type and another state change is called, the new state will lock out that event chain from firing at all, even if those events are provided.... the lsl portal is a bit misleading on how that all works, but the linked jira makes it more clear.

 

the reasoning for using a function to recall the same state is that it doesn't work from the event code IIRC, and only works from within an external function, and then only when embedded in an if statement. speed wise you are not gaining anything as state changes are comparatively slow, and you'll be dumping any other pending events in the queue.

as a good habit to avoid these subtle and weird bugs it's always better to use *_end events where possible in preference to to the other two, and only call state changes from *_end. if more than one chaining event is used it's better to avoid using state changes at all (a slight exception exists for state exit loops using state change exists, but it's also not a recommended method)

and just to note, state changes will always be iterative, rather than recursive. the previous state (even if it was the same state) will be fully exited before the new state takes effect.

Link to comment
Share on other sites

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

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...