Event registration lost on state change

Although the multi script is fixed, and allegedly the events not clearing on state change as well, it now seems that event registrations are lost on state change. I checked this a handful of times with a listen. When declared in the default state, the listen in the next state did not process. Copy and pasting it into the entry of the new state, and it worked.

Argh.

Hah and then my client crashed ;p.

EDIT when I got back in, I simplified the test to make sure.

This code does not run.

default
{
state_entry()
{
llListen(0, "", "", "";
state working;
}

listen(integer chnl, string s, key id, string msg)
{
}
}

state working
{
state_entry()
{
}

listen(integer chnl, string s, key id, string msg)
{
llSay(0, "Registration working";
}
}


Move the listen reg to the working state and it works. Having the empty event handlers/removing them makes no difference.

Cory indicated that having listen events either continue to process in the new state, or queue up in the old state was always a bug. It's now been fixed, though it sure would have been nice for them to have mentioned that in the release notes.

So as of 1.3.0, llListen and the listen event will be constrained to the active state, which was apparently the way it was supposed to work from the beginning.

Pretty annoying, huh?

When?

Catherine, I'm not sure why you posted that response. I register the event in default. The registration should still be active in working. It is not. That is not the intended behavior. I had to move the registration to the working state to get the listen code to execute.

From my numerous posts on the subject, it should be evident that I am abundantly aware that the pre 1.3 behavior was a bug. My post is the one Cory replied to stating so, and is in fact the post you are referring to.

To reiterate...event registrations do not persist through state changes anymore. Run the above code and try it. I did numerous tests on it and know it for a fact. ALL my game scripts, both the Vorago and Terrain, are broken now.

What I did find odd, and what may be causing the misunderstanding, is if there was a second patch today I'm not aware of. The one I downloaded said, "not required but we recommend", which I found sort of funny, since you clearly needed to download it to get the game to work correctly (even though after dowloading it the game was still broken).

Please post a link!

After going through this with somebody last night, it became apparent most people don't get what I'm saying.

There are two parts to using listen.

1. Registration. According to the manual, and as shown by the hundreds of scripts that practice it, you should only have to register a listener ONCE. You don't require an llListen in every state. If you did, what would be the point of llListenRemove (unless in fact the listener was not removing, which compounds the problem, as a multistate script would eventually give you "too many listeners".

2. Event handling. When you leave a state, all incoming info to your event handlers is supposed to clear. THIS was the bug, as the events did not clear...they were waiting for you when you went back to that state.

Now, number two is fixed, and number one is broken, which is a far worse bug. Look at the code I wrote above. When you leave the default state and enter the working state, the listen event should still work, because you registered the event in the prior state.

But it doesn't work anymore. You have to declare an llLIsten in BOTH the default and the working state.

So, unless the use of llListen has changed (event registrations stick but event info clears), llListens are very, very broken.

w00t! We can finally agree on something for once
That's basicly what I was trying to say (unsuccessfully) in the other thread.

New patch.