All listeners in an object listen from the root prim?

So a friend of mine builds houses and a while back she asked me to write her a menu driven window tinting system. You know the type, click a switch prim, get a menu of tinting options, click one, the script inside the switch hears it and sends a link message out to the window scripts. Easy enough. But today she was working on a new house and wanted a switch on the 1st and 2nd floor. No problem, I thought, as long as they're all linked which they were. Only, the 2nd floor switch didn't work. You'd click it, get a menu, click a button then nothing. So I added debug code to make sure it was all working the way I thought it should. Turns out, no, for some reason it wasn't hearing the response from llDialog. Was it listening to the right channel? Yeah. Was it identical in all respects to the working switch on the 1st floor? Yeah.

So after about a half hour of pulling my hair out trying this and that, knowing damn well that the script should work based on everything I knew, I asked her to move it closer to the root prim. She did and what do you know, suddenly "it" was hearing the llDialog responses. Now, I have never read anything about listeners in an object all listening from the root prim's position and had obviously assumed that the switch's prim, which contained the menu and listener code would naturally be in range of itself but such is not the case. So my question is, is this intended behavior and if so, given the new link limit max which obviously now allows one to create linksets in which this is an obvious issue, shouldn't someone have mentioned this at some point? Or is it mentioned somewhere and I just didn't happen to come across it? It's certainly not mentioned on the lslwiki.

It's phrased a little differently, but I think this JIRA is about the same problem you are seeing.

http://jira.secondlife.com/browse/SVC-2133

It does have an internal number and hasn't been closed, so perhaps a Linden or two would be interested in more input there.

But yeah, it doesn't look like this is clearly documented anywhere. The only real hint is that the old LSL wiki page for llListen always mentions objects but not prims.

OK, we've found an interesting bug that might help explain what you're seeing (and will hit up jira after).

Take your basic cube and stretch it to 10 meters tall. Copy-select twice so that you have a 30 meter stack, then link the three prims so that the bottom one is the root.

In the root (bottom) prim, drop in this:

default
{
    state_entry()
    {
        llListen(5, "", "", "");
    }

    listen(integer channel, string name, key id, string message) {
        llOwnerSay("root prim heard " + message);
    }
}

In the topmost prim, drop in:

default
{
    state_entry()
    {
        llListen(5, "", "", "");
    }

    listen(integer channel, string name, key id, string message) {
        llOwnerSay("child prim heard " + message);
    }
}

Stand at the bottom of the pole, say /5hello , and see that both scripts answer. Fly up gradually and notice that indeed, all listens are heard from the root prim and the listens go unheard by the time you are at the top.

Now the fun part: take the pole into your inventory, and rez it back from inventory. Try the same experiment, but now the root prim's script only replies when you are at the bottom, and the child prim's script only hears when you are near the top. Strange but fun!


ETA: http://jira.secondlife.com/browse/VWR-2923 seems to be this issue.

There was a comment added to SVC-2133 tonight. In a future server release, dialogs will always speak from the root prim. Presumably the wandering listen point bug would be fixed at the same time.