state transition in on_rez event

I am working on a script that needs to go into a certain state whenever it's rezzed. I can get it to call functions just fine in on_rez, but it will not do a state transition. The script is compiling propperly - just when I test it by rezzing the object it appears that nothing happens.

I did notice if I call a function first and then transition to the new state it works just fine.

Is it expected behavior that state transitions don't work when they are the first thing in the on_rez event or is this some kind of weirdo bug?

Thanks!

have you tried this inside your onRez?

if (TRUE) state XYZ;

it does work

it's better than callin an unneeded function lol thanks

BTW - from memory LSL doesn't (shouldn't) support state transistion calls from within functions BUT you can get this working by a trick such as the one above, but in which case the safe recommendation would not be to utilise such an approach if LSL doesn't specifically support it......may have not have been quite the scenario here but thought I'd mention this (hopefully I'm recalling things correctly)

I've had a problem like this, but it was a little more subtle. Maybe it's what's really going on here, so I'm going to post about it anyway.

I have an object that wants to be in state "B" if it's being worn, with occasional excursions into state "C", and then when it's taken off or dropped into the world, it wants to be in state "A". If it rezzes in state "A", it figures out whether it's attached, and if so, it goes to state "B". On detach in state B or C, it goes to A.

So far so good. The thing is, sometimes when it's worn, it never makes it out of state A. I guess it might be the state transition failing, but in my case, the state command is under an if statement.

Here's what I think is happening. Sometime before 1.7 or 1.8, Andrew Linden posted about how they were going to fix a bug, and in the process, they would be limiting the amount of time a script could do anything in the detach() event before it was forcefully frozen, whether or not it had finished what it was doing. I think that time is way too short. From what I can tell, here's the sequence of events:

1. Script is idling in state B.
2. User detaches it to inventory.
3. Script tries to go to state A in the detach event.
4. Script gets stopped right before the state transition.
5. User attaches script.
6. Script is still in state B running detach event, so on_rez gets called in state B (which doesn't have any on_rez handler).
7. Script belatedly switches to state A.
8. Script sits in state A, twiddling its thumbs, never to receive an on_rez that'll let it finish up.

I'm not sure this is what's going on, though. It's just the best guess I have. It may simply be that state transitions in attach() events are failing randomly... I'll put in some debug code to figure out just when state transitions are happening.

Anyway, does it sound like what I've described here might be what's going on?

Sorry, turns out mine's a completely separate issue. Detach events aren't called on scripts in child prims until after the next attach. Cute.

correct... if you put a state transition in a global function it will return an error (basically saying you can't do that lol)

I was calling a function (llSay and having it say something dumb or a 1 second llSleep) and then on the next line calling the state transition and it would work. So as long as the state transition wasn't the first the the event handler did, it would work.

::nod:: yes, it's bad to call state changes from functions IF that function could
A) logically be calledbefore some other events in the calling state could finish (think event handlers)
B) if the function returns a value (to the state that no longer is in effect)
C) (not 100% on this one) before the function finishes other processing

otherwise, all good =)

(the thing with the on_Rez was abnormal, so I threw it out as a suggestion)


that's a pain.

for anyone that cares I got a reply from Torley that this is apparently a bug

*rushes off to fill out a bug report*