Dialog Box stops functioning after teleport

[LissomePrey]

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 December 13, 2018 by LissomePrey
further investigation

[Innula Zenovka]

Are you allowed to run scripts in the new region?    

 

[Rolig Loon]

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 December 13, 2018 by Rolig Loon

[Wulfie Reanimator]

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 December 13, 2018 by Wulfie Reanimator

[LissomePrey]

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);
            }

        }

 

[LissomePrey]

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

 

[Wulfie Reanimator]

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.)

[LissomePrey]

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

[Wulfie Reanimator]

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 December 13, 2018 by Wulfie Reanimator

[LissomePrey]

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

[steph Arnott]

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

 

Edited December 13, 2018 by steph Arnott
TYPO

[KT Kingsley]

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.

[LissomePrey]

Excellent, thanks to all for the help.

Will do some more testing tomorrow.

[Wulfie Reanimator]

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 December 13, 2018 by Wulfie Reanimator

[steph Arnott]

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.

[Wulfie Reanimator]

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.

[steph Arnott]

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.

[chibiusa Ling]

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.

[steph Arnott]

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.

[Wulfie Reanimator]

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 December 14, 2018 by Wulfie Reanimator

[LissomePrey]

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 ...

[KT Kingsley]

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.

[Rider Linden]

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(); } } }

[chibiusa Ling]

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 December 14, 2018 by chibiusa Ling

[steph Arnott]

Rider, that will only reinstate the listeners which does not connect to the client input field. That field is dead.