PLZ official response required to llListen break

Another need to know for a fact...this is a major game breaking issue. I am effectively at a complete standstill in all my dev efforts until I get a definite response, and I had to shut down The Vorago.

- Registering a listen in one state no longer carries over to another state, you have to register the listen again.

If this is the new model that's fine (other than the fact it will require extensive recoding of numerous scripts which is painful), but please indicate if llListens are removed automatically on state exit or if you still have to explicitly do it (to prevent to many listens). NOTE: this is not the same issue as the appearance of "queued" events (though I can see how it may be related) for anybody reading this.

- If the story is that they are broken and that this is not a new model, PLEASE plz plz let us know when it will be fixed!!!! All my game scripts and so forth are entirely broken, nothing works anymore simply because when I switch states, listen registrations seem to disappear.

If a patch has already been issued, sorry for the post, I'm running a class and can't check, but at least I know if I can go home and get a couple of hours in on the game or whether I should go try to up my GF faction. This patch would be in addition to the one that was issued yesterday. I didn't see any mention of it in the forums, and considering the severity, really need a status on this.

As a representative of another Game Dev team, I would appreciate a detailed response to Tcoz's post as well. We're all working on a tight dealine as it is, and issues such as this cost us valuable development time.

Try to remember, we're all doing this AFTER a day of RL work, so silence on important issues like this are a huge setback.

Thanks
-Bone

To any Lindens:

(EDIT: Ignore this post, it's information was incorrect.)

Actually Mol, your point is sort of moot/splitting hairs, because every time you enter the state, it will hit the llListen again (unless you are creating the listener in another event). I also indicated in my post that clarifying whether or not the listens are actually disappearing, or need to be explicitly removed, is required.

And insofar as the second state is concerned, the registration has in fact never existed and/or is discarded from the first state, as I showed you last night when explaining the bug. So it does in fact disappear or is blocked (or just never available at all). It may reappear when you enter the old state....but that's part of the bug. I'm willing to bet that registrations carrying over was what caused the "queue" bug. The side effect of making sure that events clear on state exit is apparently the fact that the registration info does not pass to the new state.

We could bandy words all day. The core issue is, listen registrations do not carry over to other states anymore, and they are supposed to. Anyway I'm pretty sure the Lindens get the idea.

The point WAS to split hairs, so as to make it easier for the Lindens to track down precisely what was going wrong in their code.

However, my information was incorrect, so I have to split hairs the other way now:

To all Lindens working on this problem:

All states now contain an invisible state_exit() that contains automatic llListenRemoves for every llListen in existence within the state. This is not how things behaved previously.

This may or may not be a bug in your estimation, but to all coders within SL this is undesireable behaviour, and should be changed unless OVERWHELMING reasons to not do so deem otherwise (like the previous method was causing a memory leak that would have eventually quadrupled the size of your database, or something equally world-ending).

integer i;
default
{
    state_entry()
    {
        for(i = 0;i <= 64; i+=1)
        {
            llListen(i,"",NULL_KEY,"Test");
        }
        llWhisper(0,"Done Foring.");
    }
    listen(integer channel,string name,key id, string message)
    {
        llWhisper(0,"I hear you.");
    }
    touch_end(integer num_detected)
    {
        state test;
    }
}

state test
{
    state_entry()
    {
        llListen(65,"",NULL_KEY,"Test");
    }
    touch_end(integer num_detected)
    {
        state default;
    }
}

My previous post stated that code scripted like this would throw a run-time error claiming too many listens after a single click. That was incorrect. The above script now runs without run-time errors. (This is bad.)

This is the new model. Listens are now removed at state transitions, which has the advantages of a) removing the need to clean up listens on state transitions, b) correctly separates behavior between states, c) eliminates the bugs around chats showing up in the wrong state, and d) actually doing what was supposed to do.

Unfortunately, this does break some scripts in the world that were relying on having listens stick around. Mea culpa on not doing a better job of broadcasting the impact of the change.

Ow. I mean Ow. OW.

Ho. Ly. Crap.

So one of the Linden's own Top Picks is broken by the patch that revealed the Top Picks for the first time ever. And we were given no warning. Congrats, Lindens. Your documentation abilities suck.

Yipes. This didnt belong here, sorry!