Help! Dialog menu not appearing?

I have had two different people report that clicking on a product of mine no longer pops up the dialog menu. After an hour or so of frustrating debugging, I crafted an entirely new object, a sphere, that simply sits in the owner's hand. Here is the code inside:

default
{
    state_entry()
    {
    }

    touch_start(integer total_number)
    {
        list testList = {"This","Is","A","Test"];
        llDialog(llDetectedKey(0), "Test Menu", testList, 1);
    }
}

When I wear it and click on it, I get the dialog menu just fine. The two people who reported this issue do not. In one case, his product has been working fine for a month or more and then apparently just stopped delivering the dialog menu.

Has anyone else run into this issue? Am I doing something wrong? At this point, I've got to believe this is a problem with SL, or maybe a setting in the client I'm missing. Is there anything that can suppress a dialog like that?

Thanks for any help with this, I'm baffled.

- Javy

You might check to see if total_number is in fact just 1 -- perhaps somehow the object is detecting more than one thing.

I had one customer complain that he had to click an object (a door) I had sold him twice before bringing up the dialog box. I have sold hundreds of these doors, with no such a trouble ever reported before. When I went to see this wonder, I noticed that the response to scripted events was v e r y s l o w. My doors usually open almost immediately, while my customer's door took several seconds. FPS was above 40, but the sim had over 1900 active scripts, although how many of them were actually doing anything I don't know.

Perhaps LL's decision to sacrifice script response in order to maintain high FPS is causing these kinds of problems.

I have to agree with Lee...though all of us scripters can try to help slow-script situations by avoiding public channel listens, sensors, and dataserver events whenever possible...

I've noticed that sometimes (even pre- 1.7) touch events that specify llDetectedKey(0) or similar would not always work, so I do the following in all my touch events:

default
{
    touch_start(integer total_number)
    {
        integer t;
        for(t = 0; t < total_number; ++t)
        {
            list testList = {"This","Is","A","Test"];
            llDialog(llDetectedKey(t), "Test Menu", testList, 1);
        }
    }
}

This makes sure it triggers for every touch event. I haven't had any touches missed since I started doing this.

BTW, not sure if you just did this for the post, but try not to use channel 1. It's better than channel 0, however alot of items use it. If the listen is only for the script and not for commands from someone, try using a 3 or 4 digit channel; it's not very likely to be used, which would both reduce possible conflict with another script, and help lower lag just a tad more since only your script would hear it .

Thanks for all the advice. I will try the advised solution and see if it fixes the problem.

As an aside, my items don't really listen on channel 1, they choose random high numbered channels by default, that was just for the test.

- Javy

What I sometimes do for llDialog is to generate a random channel number and listen on that only until the dialog is answered.

integer dialog_handle;
integer dialog_channel;
...
post_dialog(key agent, string message, list options)
{
  if(dialog_handle) // Do I have an unanswered dialog up?
    llListenRemove(dialog_handle); // Yep, fuggedaboudid.
  dialog_channel = llFloor(llFrand(2000000000)+1000000);
  dialog_handle = llListen(dialog_channel, "", agent, "");
  llDialog(agent, message, options, dialog_channel);
}

integer check_dialog(integer channel, string response)
{
  if(channel != dialog_channel) return 0; // Not for us, return 0 to keep checking
  if(dialog_handle == 0) return 1; // Old request, ignore, return 1 to stop further checks
  llListenRemove(dialog_handle);
  dialog_handle = 0;
  so_something_with(response);
  return 1; // Handled request, return 1, no need for further checks
}
...

default
{
...
  listen(integer chan, string name, key id, string message)
  {
    if(check_dialog(chan, message)) return; // handled in the dialog code, no work for me...
    ... // other listens handled here
  }
}

Ask these people if they are using alts at the same time. I've noticed very strange behavior on certain scripted objects using llDialog when an alt of mine is in the room at the same time - and it doesn't make sense at all. One of my alts can touch a certain object NOT attached to me (a dance machine) and it works just fine, even when my main is using it also - however, with another alt, the machine will not function correctly at all (it acts as if it suddenly cannot sense any avatars). It's not just a name issue either - there have been many other objects that I've noticed this same behavior with. It's bizarre. LSL should be getting the avatar by key...

they are. I suspect you may be having problems with UPD port conflicts - have you ever taken explicit steps to allow multiple copies of SL to run on your computer/network?

Not particularly, I haven't needed to - SL seems to handle NAT just fine, for the most part. I can't recall having any other problems besides this - no mixed up inventory, no other strange problems. In fact, this problem can occur with one alt, yet not another. It seems to be a per avatar issue, that may or may not have anything to do with being on the same network via connection sharing. It's one of those hard to pin-point issues.