Jump to content
LissomePrey

Dialog Box stops functioning after teleport

Recommended Posts

I have a dialog box that works perfectly whilst staying on the same sim (for most options it redisplays after processing).

If I teleport to a new sim with the dialog box displayed it appears to have been disabled, i.e. doesn't respond to an option choice and doesn't redisplay. Is this expected behaviour or am I doing something stupid?

Edit: I just checked that it still fails on a sim that i know allows scripting, in fact the sim where it worked perfectly before.

Edited by LissomePrey
further investigation

Share this post


Link to post
Share on other sites

That's a hard one to answer without knowing more about the script.  One of the first things to check, however, is to be sure that you are teleporting into an area where scripts are enabled.  If not, your script may simply be non-functioning until you go somewhere else.  Did you write the script yourself, or is it in something that you bought?

edit:  heh.  What innula asked ^^ 

Edited by Rolig Loon

Share this post


Link to post
Share on other sites

The llDialog buttons work by actually making your avatar speak on the dialog's channel. If you are beyond 20 meters from the object that gave you the menu, clicking the buttons DOES make your avatar say the button text, but the object that gave the menu is too far away to receive it.

Try using llDialog on channel 0 to clearly see what I mean.

Edited by Wulfie Reanimator

Share this post


Link to post
Share on other sites

Basic excerpts from script:

        llDialog(avatarId,level2Message,level2Buttons,dialogChannel);


Listener

    listen(integer channel, string name, key id, string message)
    {
        if (channel == dialogChannel)
        {
            if (message == "TALK")
            {
                llTextBox(avatarId, "Type a private message to your sub", dialogChannel2);
            }
            else if (message == "RELEASE")
            {
                llRegionSayTo(subId,myDomChannel,message);
                state default;
            }
            else
            {
                llDialog(avatarId,level2Message,level2Buttons,dialogChannel);
                llRegionSayTo(subId,myDomChannel,message);
            }

        }

 

Share this post


Link to post
Share on other sites
8 minutes ago, LissomePrey said:

Thanks Wulfie, I'm wearing the object so that shouldn't be the problem

Okay, in that case (and this is purely a guess) I think the problem is caused by the way listeners work.

When you use llDialog, the sim you're currently in registers a listener for a response. If you move to a different sim though, that new sim won't be told about any listeners registered by the previous sim, because the listener is not directly related to you or the object/script. (llDialog doesn't give a listen handler, for example.)

  • Like 1

Share this post


Link to post
Share on other sites
8 minutes ago, LissomePrey said:

That was vaguely what I was thinking might happen, so I should detect a sim change and restore the listener?

I just did a test to see if it was the listener that was disconnected or if nothing was said in the first place.

Using llDialog on channel 0 so my avatar would speak in local chat, clicking a dialog button wouldn't cause anything to be said in chat after walking over a sim border or teleporting to another sim. You would have to give the menu again entirely, because just restarting the listener wouldn't make the expired dialog menu work. It seems like it's the viewer that discards the old dialog when connecting to a new sim.

Edited by Wulfie Reanimator
  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites

Thanks, saves me a test. Unfortunately of course the dialog box is still displayed. I guess I need to recreate the dialog box and the listener, that should work but is a bit ugly as the identical old box remains.

Thanks for the input

Share this post


Link to post
Share on other sites

It is because the other sim does not have that type com activated. Comms of that type are sim server only.

 

Edited by steph Arnott
TYPO

Share this post


Link to post
Share on other sites
8 minutes ago, LissomePrey said:

Thanks, saves me a test. Unfortunately of course the dialog box is still displayed. I guess I need to recreate the dialog box and the listener, that should work but is a bit ugly as the identical old box remains.

Thanks for the input

I think the LL viewer only allows one dialog per object these days, so redelivering a new dialog should remove the old one. Firestorm does allow the option for an object to open several dialogs simultaneously, so if that's what's happening you could turn that off.

  • Like 1

Share this post


Link to post
Share on other sites
16 minutes ago, steph Arnott said:

It is because the other sim does not have a com activated. Comms are sim server only.

Communication is handled server-side only, yes, but dialog menus are client-side in that it is the viewer that sends a message when a button is clicked, not the sim. Evidently it is the local viewer that discards the menu on sim change. We can't make a definitive conclusion on whether the sim would relay the message properly if the viewer did keep the menu, unless we can do the same test with a viewer that does not discard the menu.

Edited by Wulfie Reanimator

Share this post


Link to post
Share on other sites

Wolfie the open com is on the sim server. The client side is only an input the same as the mouse. Once the comm is severed it is dead.

Share this post


Link to post
Share on other sites
5 minutes ago, steph Arnott said:

Wolfie the open com is on the sim server. The client side is only an input the same as the mouse. Once the comm is severed it is dead.

I understand very well. Can you prove (and objectively demonstrate) that the listener itself stops working? I thought it did, at first, but I have demonstrated that the dialog stops working because the viewer will not give any input in the first place.

Share this post


Link to post
Share on other sites

Wolfie, when an av leaves a sim a clean up code is activated. One shuts down listeners. This is resource managment. A sim server would go down with in a few hours or a day if the server did not.

Share this post


Link to post
Share on other sites
13 hours ago, steph Arnott said:

Wolfie, when an av leaves a sim a clean up code is activated. One shuts down listeners. This is resource managment. A sim server would go down with in a few hours or a day if the server did not.

The point he's making is that he tested it in channel 0 and after crossing from one sim to another there was no output into channel 0 after clicking the dialog button. A dialog outputs the message as if the avatar has said the message onto the specified channel. What we take from this is that its the dialog that is discarded. Listens enabled in a script do not just automatically stop...per say...when you leave a region. An script in an object that has a listen activated on channel xxx will continue to pick up messages regardless of how many region changes you do. If that wasn't the case then half of the products on SL would flat out just break and never work again. So the logical deduction that Wulfie has made, given that we can't further test this due to the viewer discarding the dialog, is that the issue is with the dialog itself because if the dialog was still active when entering another region....the object that "is set" to listen would still be listening and would still pick up a message sent to its channel.

Share this post


Link to post
Share on other sites

Chibiusa, this is the second time that you have failed to read and understand what i have written. The listeners in scripts with dialog boxes are closed on sim exit. PUBLIC_CHANNEL is not the 0 channel on dialog communication. They are two seperate things.

Share this post


Link to post
Share on other sites

I think there is a disconnected listener on the forum somewhere but I don't know if it's local or server-side..

Edit: Upon further inspection, it is evidently the latter.

Edited by Wulfie Reanimator

Share this post


Link to post
Share on other sites

I don't know any of the technical stuff about coms but adding a new listen and recreating the dialog on detecting a sim change works perfectly.

On Catznip, the old dialog box is also tidied up properly.

Thanks for the help in solving it. Now onto the next problem ...

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, LissomePrey said:

I don't know any of the technical stuff about coms but adding a new listen and recreating the dialog on detecting a sim change works perfectly.

On Catznip, the old dialog box is also tidied up properly.

Thanks for the help in solving it. Now onto the next problem ...

Just to say that when you create a new listener, remember to remove the old one.

Share this post


Link to post
Share on other sites

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. 

integer MY_CHANNEL = 42;

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

default
{
  state_entry()
  {
    establishListens();
  }

  changed(integer what)
  {
    if (change & CHANGED_REGION)
    {
      establishListens();
    }
  }
}
 
  • Like 1
  • Thanks 4

Share this post


Link to post
Share on other sites
47 minutes 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. 

The first bit I get, I knew the region itself had something to do with the hosting of the listen,  but the last part however im experiencing the total opposite. I created a script, placed a listen in state_entry, added the listen event and left out everything else. No CHANGED_REGION, no re initialisation of the listen and yet the listen happily maintains itself between the regions I am teleporting to. I know you say that to maintain it you should monitor for CHANGED_REGION but could the "big gooey ball" that is unpacked not be re establishing previously called listens from the object the script is in?. Because it seems like thats whats happening for me.

[10:08] Object: Got the message : test in region Infinity Gate

[10:08] Object: Got the message : test in region W Real Estate

[10:08] Object: Got the message : test in region Skidz Isle

Edited by chibiusa Ling

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×