lldialog must change

Hi,
i try lldialog and i think you must change this function to return a specific value when ignore is clicked. Explain below :

1> LSL is a state language
2> i use two states, the default that opens the dialog and go to state waitforclick (state2)tforclick that listen the clicked button, make some work and call the default state (state 1)

if an avatar click "ignore" on the dialog, the script is blocked in state 2 (waitforclick). You recommand to implement a timeout event to bypass the "ignore click" (lsl wiki), in this case i can use the timer event to return in state 1 (default) but the dialog box is already opened, and there is no reaction with a click on a action button.

the only way to correct this behavior is to use only one state for script not be blocked in state 2. When i click ignore, i am allready in state 1. But i lost the state functionnality of the lsls language.

In state 1, i use a notecard and dataserver to read it. If i use one state i couldn't be sure that i read the whole notecard before to open lldialog except if my lldialog is in the dataserver with a test on EOF for the notecard. The script will become complex and i have a strange behavior of the script.

SO, lldialog in the actual form is not designed be used in a state language. So you must just change the return value for the "ignore" button to make this function usable in custom state without timer.

Thanks for your reply.

Why was this post moved to Scripting tips? this is a complaint about the achitecture BEHIND LSL.. not a question regarding the use of LSL. Something about the Ignore buttoon in llDialog is broken,m according to the OP.. and wants someone on the programming-support side of LSL's backend to look at a possible change to the behhaviour of the "ignore" button.

It helps if you think of 'llDialog()' as more of a drop-down interface or something. There has to be something that triggers its appearing, yes, but otherwise just think of it as a static menu interface. IOW, don't change your script's behavior much WHEN YOU BRING THE DIALOG UP. Focus more on when you actually GET A REPLY.

In fact, I usually have a persistent listener on the dialog channel(s), not a timed out one like people seem to be fond of. If you use large non-zero channels, listeners aren't that costly, and it can really simplify the implementation.

There are some applications that are exceptions, but I find this tends to be the better design.

(I didn't move this thread and it does belong in script tips)

You must understand it is not a problem with llDialog.
The problem is you are opening your listen before transitioning to state 2. Listens are released on state changes. To make everything work, (re)open your listen in the new state. Or better yet migrate the entire dialog control to the second state.

The reason for not having "ignore" return a value to the script is so that the script doesn't know its been ignored. It's a feature. It allows a user to escape a possible infinite loop of dialog boxes. You would still need a time out, what if the user logged off? Or the user left the sim? Both these situation would result in the same behavior as if "ignore" had been pressed.

Changing llDialog would result in incompatibilities with older scripts unable to handle the change to LSL. LL has stated they do not plan to make major changes to LSL until after Mono. Everyone else is coping just fine with this limitation.

If you want a script module that is easy to use and handles this sort of thing checkout:
http://lslwiki.com/lslwiki/wakka.php?wakka=LibraryDialogModule

key user;

default
{
    touch_start(integer a)
    {
        user = llDetectedKey(0);
        state dialog;
    }
}

state dialog
{
    state_entry()
    {
        llListen(10,"", user, "");
        llDialog(user, "Press a button", ["1", "2", "3"], 10);
        llSetTimerEvent(30.0);
    }
    listen(integer a, string b, key c, string d)
    {
        llSay(0, "Woot! You pressed a button, it was: " + d);
        state default;
    }
    timer()
    {
        llSay(0, "I pitty da fool who is too slow to push a button");
        state default;
    }
}

Purely from a ergomonic/cosmetic point of view it would be nice if we could remove Dialogs via LSL, or even specify a timeout in the call so it deleted automatically if it hadnt been pressed.

Yeah, i wish there were a way to remove them.

While on the wish list how about a more configurable dialog, multiple data entry types : drop down list, direct text entry.....

i will look at the librarydialog.