Jump to content

Dialog Box stops functioning after teleport


LissomePrey
 Share

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

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

Recommended Posts

3 hours ago, Rider Linden said:

When you transfer from region to region any objects and their scripts are packaged up into a big gooey ball of bits and thrown to(at?) the new region. The new region will then unpack the objects and their scripts and start them running again.  This process does not restore any listens that were previously established in the old region using llListen(). 

If you have a script that needs to maintain a listen event across region changes you should monitor for the CHANGED_REGION event and recreate your listens there. 

I genuinely love to see Lindens join in on the technical conversations (and I hope to see it happen more often!) but..

I have created a prim and put this script inside it: (P.S. your script wouldn't compile because you used "what" and "change" in the changed event, I fixed that)

integer MY_CHANNEL = 42;

integer establishListens()
{
    return llListen(MY_CHANNEL, "", NULL_KEY, "");
}

default
{
    state_entry()
    {
        establishListens();
    }

    // changed(integer what)
    // {
    //     if (what & CHANGED_REGION)
    //     {
    //         establishListens();
    //     }
    // }

    listen(integer channel, string name, key id, string message)
    {
        llOwnerSay(message);
    }
}

Notice how the changed event is commented out, so it will never be reset during this test.

Then I attach the object to my self and type "/42 first message!" into chat. Works fine, as expected. (Sim: Mill Cove)
Then I walk over a sim border to a neighboring sim and say "/42 second message!" Works fine. (Sim: Falling Rose)
Then I teleport to an island sim with no neighbors and say "/42 third message!" Still working. (Sim: Fluffy)

The reason why this works, I believe, is because llListen is a "property" of the script. llListen essentially "subscribes" the script itself to a specific channel, the handle is stored under-the-hood and llListen returns an index for the handler so that it can later llListenRemove or "unsubscribe." (Fun fact, you don't need to store the listen handle to remove the listen. The first handle is integer 1, the next handle will be integer 2, and so on.)

When a script's state is prepared for transfer to another sim, its subscriptions are kept. llDialog does not use a handle, it simply tells the avatar's viewer to open a user interface, and the viewer is the one giving a response when the local user clicks a button on the local dialog.

Part 2: Actually restarting the listen

Let's uncomment that changed event and add a dialog menu on touch_start:

integer MY_CHANNEL = 42;

integer establishListens()
{
    return llListen(MY_CHANNEL, "", NULL_KEY, "");
}

default
{
    state_entry()
    {
        establishListens();
    }

    changed(integer what)
    {
        if (what & CHANGED_REGION)
        {
            establishListens();
        }
    }

    listen(integer channel, string name, key id, string message)
    {
        llOwnerSay(message);
    }

    touch_start(integer n)
    {
        llDialog(llGetOwner(), "dialog", ["test"], MY_CHANNEL);
    }
}

When I click the attachment, I get a menu and click the "test" button. It works as expected. (Sim: Fluffy)
Then I click the attachment again before teleporting to another sim while the dialog is open. Then I click the dialog button. Nothing happens. (Sim: Falling Rose)
If I click the attachment again and click the dialog button while staying in the same sim, it works as expected. (Sim: Falling Rose)
Then I click the attachment again before walking over a sim border. Then I click the dialog button. Nothing happens. (Sim: Mill Cove)

This, again, proves that there is nothing wrong with llListen or the sim not receiving sent messages. The problem is that no message is being sent in the first place.

Edited by Wulfie Reanimator
Link to comment
Share on other sites

building out what @Rider Linden said, then to incorporate functioning menu dialogs after a region crossing, the script goes something like:

integer MY_CHANNEL = 42;

integer establishListens()
{
  return llListen(MY_CHANNEL, "", llGetOwner(), "");
}

showMenu()
{
   llDialog(llGetOwner(), "test", ["Ok"], MY_CHANNEL); 
}


default
{
  state_entry()
  {
    establishListens();
    showMenu();
  }

  changed(integer change)
  {
    if (change & CHANGED_REGION)
    {
      establishListens();
      showMenu();
    }
  }
  
  listen(integer channel, string name, key id, string text)
  {
      llOwnerSay(text);
      showMenu();
  }
}

 

explain:  showing the menu dialog again after re-establishing the listen on region change, will destroy any dead menu dialog

 

 

Edited by ellestones
explain
  • Like 1
Link to comment
Share on other sites

5 hours ago, KT Kingsley said:

Should one remove a listen that's been clobbered by a region change? Does an unremoved one still count against the script's allocation of 64?

good question.  I dunno what the answer is

could move back and forward between regions and see if the listen fails on the 65th time. I leave that for some one else to do :D

  • Like 1
Link to comment
Share on other sites

I very rarely have to worry about hitting that 64 cap myself.  If I were writing a script that was likely to come close to the limit, though, I think I would find an excuse to do a state change, this forcing all open listens to close.  Something generic like this ...
 

integer iLsn1;
integer iLsn2;
integer iLsn3;

default
{
    state_entry()
    {
        iLsn1 = llListen(-123,"","","");
        iLsn2 = llListen(-456,"","","");
        iLsn3 = llListen(-789,"","","");
        // and so on ...
    }

    changed (integer change)
    {
        if (change & CHANGED_REGION)
        {
            state Reset_Listens;
        }
    }

}

state Reset_Listens
{
    state_entry()
    {
        state default;
    }
}

 

Link to comment
Share on other sites

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

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

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...