dialog not opening for some people

The script I have works fine for me (the creator) and works fine for most people. But some people are having problems. The dialog will not open for them. They are in a script enabled area too. Does anyone know what the problem could be?

Accidentally muting object?

I don't think that's the problem... the dialog is a menu and it opens the first menu but won't open the next menu.

if you dont mind post the code maybe there is a script error

The code is over 400 lines. The script should be fine since it works for me and for most people, just for some it doesn't.

in the last few weeks, I've noticed that sometimes, I'm having to click things 2-3 times to get menus.. Of course, that can be lag, or "generic SL problems" or some sort of failure to notice that I did the "touch" or perhaps the touch not triggering the "touch" event..

You might want to check though, that your device's listen is set to "NULL_KEY" and not "llGetOwner()"

To be more helpful, we're really going to need to SEE your code, to be able to help diagnose the issue.

That surely is not much to go on if you want someone in this forum to help you make the code work

In my home sim I've had dialogs not show up for half an hour, but only get the horrible delay on group-owned objects (security sphre, TP system), whereas stuff I'm still the owner of works perfectly.

llGetOwner() checks don't work if something is deeded to group, BTW. llSameGroup() will, though.

That's an asset server problem along the lines of when you edit an object and open a script and the script never loads.

I spend a lot of time in beta which doesn't have the most dynamic asset system. Edit an object and open the script and it never loads loads happen a lot, touchs don't open menus some and every now and then I'll have an object with a couple of scripts in it and I'll get the message that there are no scripts there, also have it happen sometimes so that when you click "save" it times out before saving.

I found the problem.

It was because of the llGetOwner in llListen.

I didn't know that the script needs to be reset before the llGetOwner key is updated.

So I was able to keep llGetOwner in the llListen function, but just added a llResetScript into the change changed_owner.

Hope this helps anyone else that experiences this.

Are you 100% sure of that statement? It would be a huge change in LSL functionality and casue no end of scripts to break.
(OK I have been away for a while but surely even LL wouldn't have been that mad...)
You should just need to call llGetOwner() again inside the changed event rather than resetting the script. In simple scripts calling llResetScript will be ok but any script that uses any amount of stored data will suffer a time penalty as it rereads the data.

It does not matter if Mr.Dagger is sure or not as long as this forum is kept in the dark about what he is sure about... up til now not one line of code has been re veiled

I suspect he may have defined his listen in "state entry" as "llGetOwner"... since the state entry was never retriggered on new owners, the old listen remained in place.

That makes the most sense out of what he posted.

To add to what Newgate posted (and welcome back Mr Ludd; I hope your pixels are well), I did a little piece on llResetScript a while back that I never did post. And here it is...


Tip: on_rez, to llResetScript or not to llResetScript


I see this code a lot, and it works... up to a point.

It's a bit like turning your computer off and on to close the DVD draw. It works but it can require a little patience.

I think people use it as a belt-and-braces approach but as your scripts get more sophisticated it can become an ever more flawed approach.

Here's a more economical method:


...when the object changes Owner the script is reset. This is much better... up to a point.

The real problems occur when your script has irreplaceable, persistent data (and yes, this can come with its own risks), or if it has any state that you want to preserve between use, and change of ownership. In this final example you will need to define your own initialisation function:


...init() needs carry any set up steps. A good example might be:


...but there could be many others.

One thing that isn't necessary is to preserve the value of llGetOwner(). This is a snippet out of an ancient freebie script:


The comment is misleading as it doesn't tell the whole story.

llGetOwner() will correctly return the Owner key whenever, and wherever, it is used. There is no need to reset a script simply to re-establish a Global variable that carries the Owner key. In fact, there is no need to keep the Owner key in a Global variable at all.

However, considerations do apply when llGetOwner() is being used to initialise another function like llListen, or llRequestPermissions. In these cases a change of owner will require some action.

So, it's not necessarily wrong to reset a script on_rez, but I think it is worth understanding that there are alternatives, and that sometimes those alternatives are important.

I often make a "firstrun()" function, and an "init()" function. The firstRun is ususally triggered on new owner, or on state entry (in a single state script, which 95% of my scripts are).. then init is triggered on every rez, attach, etc. FirstRun triggers init as it's final command.

this allows me to do a "full reset" without losing any user defined variables, or important numbers (like the current scale factor?).. while a full "reboot" command can sometimes be useful, it does seem tedious to do it on every rez or wear.. particularly on items you'd like to "set up once" and always have set up that way.

I've also found this little tidbit to be useful...

When dynamically defining things like lists of buttons for dialogs, once you've delivered the dialog, you should blank the button list. It's an easy way to reclaim script memory when things are getting tight.

While that may be true.. consider this script:

default
{

state_entry()
{
llListen(0, "", llGetOwner(), "");
}

listen(integer channel, string name, key id, string message)
{
llSay(0, "I heard " + name + " say: \"" + message + "\".");
}
}

IN this example, the script creator's version will work fine for him. He can speak on 0, and the script will repeat everything he says on 0. Now, if he were to sell/give/transfer the object containing this script, to a friend.. something interesting happens.

State_entry is never triggered. So the llListen is still open, listening for the scripter's speech. This example of llListen generation is widely suggested in the wiki's, but it creates a problem for anyone selling their first scripted works.

Passing the listen into a init function would save some stress on this, as follows.

integer handle;

init()
{
llListenRemove(handle); // keeps listens from piling up.. otherwise every owner since the first will be listened for.
handle = llListen(0, "", llGetOwner(), "");
}

default
{

state_entry()
{
init(); // resets the listen after saving the script
}

on_rez(integer startparam)
{
init(); // resets the listen to the current owner, whenever it's rezzed.
}

changed(integer change)
{
if (change & CHANGED_OWNER)
{
init(); // resets the listen to the new owner, if "bought in place"
}
}

listen(integer channel, string name, key id, string message)
{
llSay(0, "I heard " + name + " say: \"" + message + "\".");
}
}

I really think resetting a script all the time is kind of a kludge. Especially when the script is supposed to retain it's state and variables for the long term. The solution I use is, I define a global variable, and populate it on state_entry() and on_rez(). That way it's always set to the actual owner, and plus it saves a *lot* of potential llGetOwner() calls. Just use the object_owner variable everywhere you would normally use llGetOwner().

If your item is something used in world, adding this to the changed() event would be prudent. However since what I sell are attachments, it's not needed. The item has to be rezzed to be worn, so on_rez() will catch it every time.

key object_owner;

default
{

state_entry()
{
object_owner=llGetOwner();
}

on_rez(integer startparam)
{
object_owner=llGetOwner();
}


}

That won't refresh the listens already in play, however.