Why do dialogs NOT appear?

I have a set of scripts for texture control. Some inside the master control prim and one in a slave prim using link messages between.

Another control script in another non-linked object listens and relays messages and access lists.

When using the dialog to jump between "pages" of the dialog, going back and forward, sometimes the next page doesn't come up. I have to start again at the main instance.

Sometimes when making a selection it takes two goes to make it work.

When I reset the scripts and then make a selection, to change a texture, it never works on the first attempt but always works on the second.

Nothing I have done changes the way this happens.
I know that sometimes the dialog page will come up several seconds later, but not always.

Is there a general reason that could be causing this.
The access lists? Or just bad coding? (I know I'm a bad coder)

Do dialogs just not appear because it's the way it is?
Do we just live with it?

Anyway...just hunting for ideas as to why and how to fix.
Have a pleasant day.

It's quite a hard problem to diagnose without knowing exactly what the scripts are doing. However, one thing that used to catch me out a lot is script delays. Lots of LSL function will delay your script for a period of time, and that can cause dialogs not to appear for a while, making it seem like they have broken. The only way round it is to check the documentation to see which functions could be causing the problem, and either re-order your script a little to minimize the problem, or make some other script call the problematic functions in response to a link message.

heyas;

if you're killing off the listener with a timer, make sure you dont kill it too soon, or your menu buttons will go dead.

dont mute your object or be in busy mode. ;) (hey! it happens! stop laughing!)

remember to put in a lot of llownersay debug notes to yourself to make sure the script is where you THINK it is.

Those suggestions above are good things to look for.

I generally have the timers at 30 seconds. Like... I set the timer to 30 secs after invoking the dialog.

If I make a selection from the dialog, open it again, do something else. Do another...
Are these timers piling up?
Should the listen be closed after the dialog button is clicked? i.e. the command run?

Any more gottchas or things to NOT do in relation to dialogs that could slow or stop them working?

Timers keep on running until you call another timer (use llSetTimerEvent(0.0) to just stop it) but remember the first timer will need to finish counting down one last time before it restarts with a new interval - so things can get weird if you call a new timer on top of an old one that's in an unknown state of "countdown-ness". And timers survive state changes too, so watch for starting timers in multiple states that might interact in some unexpected way. If a script with one-shot timers is complex at all, I usually kill timers dead before starting one just to be sure:

llSetTimerEvent(0.0); // kill any stray timers
llSetTimerEvent(some_interval); // start my intended timer

and of course

timer()
{
llSetTimerEvent(0.0);
do(my_stuff);
}


Likewise listens keep listening. (Listens do expire if you change states, but cleaning them up is probably a good habit to get into regardless.) So do assign an integer variable to your listens when you start them up, and kill them when you don't need them any more:

touch_start(integer num_detected) // someone clicked for a menu
{
integer my_dialog_handle = llListen(integer channel, string name, key id, string msg);
llDialog(etc etc);
}

Then in the dialog listen handler:

listen(integer channel, string name, key id, string message)
{
llListenRemove(my_dialog_handle);
do(menu-selected_stuff);
}


Hope some of that helps a bit

I disagree - did you get confused with multiple scripts running timers when making this statement? As I had thought (before you tried to confuse us ), the timer in a script appears to behave in an entirely predictable manner! Try the script below if you don't believe me!

/esc

integer time;

integer DELAY = 10; // specified as an integer only to pretty print

default
{
    state_entry()
    {
        time = llGetUnixTime();
        llOwnerSay("Timer set to " + (string)DELAY + " seconds");
        llSetTimerEvent(DELAY);
    }

    touch_start(integer total_number)
    {
        time = llGetUnixTime();
        DELAY = (integer)llFrand(30);
        llOwnerSay("Timer now  " + (string)DELAY + " seconds");
        llSetTimerEvent(DELAY);
    }
    
    timer() 
    {
        llOwnerSay("Event triggered at " + (string)(llGetUnixTime() - time) + " seconds");
        time = llGetUnixTime();
    }
}

Not confused - I've been using timers as if they behave as documented in the old wiki here:

http://www.lslwiki.net/lslwiki/wakka.php?wakka=llSetTimerEvent


You're saying this is no longer true then? Thanks for providing the script, but I can't get in-world to try it out right now.

Hmmm see what you mean -- I think that's just plain wrong...

/esc

Yep, new timer overwrites the old timer.

It must have been true at some point since the wiki has more than one person discussing/confirming it.

Oh well, it just means I can stop adding that one extra line to kill the old timer before starting a new one. If I can break the habit that is :/

Thanks Escort and Jesse.

I've certainly encountered odd situations with timers fairly recently, which still make it necessary to reset them with a 0.0 value before setting a new value. It seems to happen across state changes: if there's a timer event set to happen at about the same time as the state change, but in the "state_entry" event of the new state the timer gets set to a new (non-negligible) value, the "timer" event of the second state was still called almost instantly upon entry to the state.

Of course, it's good practice to reset timers on exit from states anyway, unless there's a particular reason to keep them, so that's usually a good alternative solution.

Bingo, good advice. Rarely do I do want a "global" timer shared among states. So normally, whenever I find myself calling llSetTimerEvent(), I immediately go to the state exit handler and put in a llSetTimerEvent(0.) call. Saves me a lot of headaches!