Don't click here unless you want to be banned.

LSL Wiki : llDialog

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are crawl801.us.archive.org
llDialog(key id, string message, list buttons, integer chat_channel)

Shows the user specified by id a popup dialog box (in the upper right corner of their SecondLife window) containing message and buttons (and an "Ignore" button). Selecting any of the buttons will cause the avatar to say the text of that button on channel chat_channel.

Even though the chat will originate with the user's name and key, the chat position will be centered at the object calling llDialog. This ensures the object will be always within listening range of the answer.

Using DEBUG_CHANNEL as the chat_channel will cause avatar to say the button name on the public channel, rather than on the debug channel as one might expect.
Actually, it does go on the debug channel, it's just that when agents chat on the debug channel, clients see it as though it was public chat. LSL objects see it on DEBUG_CHANNEL

Limits to message:

Limits to buttons:

If the user selects "Ignore", the script will not receive an answer, so implement a timeout (recommended) or allow the dialog to be restartable from anywhere.

Notes


Example

// when touched, present a dialog with four color choices

integer CHANNEL = 42; // dialog channel
list MENU_MAIN = ["Sit", "Stand", "Fly", "Cheat", "Options..."]; // the main menu
list MENU_OPTIONS = ["Cherry", "Blueberry", "Vinegar", "Slime", "Chips", "Salad", "...Back"]; // a submenu

default {
    state_entry() {
        llListen(CHANNEL, "", NULL_KEY, ""); // listen for dialog answers (from multiple users)
    }
    
    touch_start(integer total_number) 
    {
        llDialog(llDetectedKey(0), "What do you want to do?", MENU_MAIN, CHANNEL); // present dialog on click
    }
    
    listen(integer channel, string name, key id, string message) 
    {
        if (llListFindList(MENU_MAIN + MENU_OPTIONS, [message]) != -1)  // verify dialog choice
        {
            llSay(0, name + " picked the option '" + message + "'."); // output the answer
            if (message == "Options...") 
                llDialog(id, "Pick an option!", MENU_OPTIONS, CHANNEL); // present submenu on request
            else if (message == "...Back") 
                llDialog(id, "What do you want to do?", MENU_MAIN, CHANNEL); // present main menu on request to go back
            // here you have the name and key of the user and can easily verify if they have the permission to use that option or not
            else if (message == "Sit") 
                llSay(0, "This is where stuff would happen if this wasn't just an example");
        } else 
            llSay(0, name + " picked invalid option '" + llToLower(message) + "'."); // not a valid dialog choice
    }
}

//Compact function to put buttons in "correct" human-readable order ~ Redux
list order_buttons(list buttons)
{
    return llList2List(buttons, -3, -1) + llList2List(buttons, -6, -4) + llList2List(buttons, -9, -7) + llList2List(buttons, -12, -10);
}

//Function that puts buttons in "correct" human-readable order without relying on intelligent higher order list functions ~ Redux
//my bad; fixed 11/25/07
list order_buttons(list buttons)
{
        integer offset;
        list fixt;
        while((offset = llGetListLength(buttons)))
        {
            fixt += llList2List(buttons, offset = -3 * (offset > 3), -1);
            buttons = llDeleteSubList(buttons, offset, -1);
        }
        return fixt;
}

// Loop that puts buttons in "correct" human-readable order, no matter the length of the list.
// Designed to work with "<<" and ">>" buttons, allowing easy browsing of 'virtual' dialog pages. ~ Trullo Oh
for (i=0;i<llGetListLength(BUTTON);i+=3) { BUTTON = llListInsertList(llDeleteSubList(BUTTON, -3, -1), llList2List(BUTTON, -3, -1), i); }
default //Paste this script into an object
{
touch_start(integer x) //Touch the object
{
llDialog(llDetectedKey(0) , "Text" , ["1" , "2" , "3"] , 0); //Select a number, chats it over channel zero.
}
}


Q & A
Q: What is the equivelant range of llDialog (whisper, say, shout, regionsay)?
A: The range seems very long, as i once used a dialog from one sim, to another, where there was a complete sim between it, and yet it still responded perfectly, the answer below is not correct, it seems further then shout, and not limited to the region, more like connected to the sim, is the range.(might require more test, if this still applies)"
Actually, the below answer is correct. It says that the "object were to say llSay", not the avatar; therefore, no matter where your avatar is, the dialog response originates from the object's centre. -- EH
A:
Responding to the dialog will work as if the object were to use llSay(channel,message), where 'channel' is the channel specified by llDialog and 'message' is the text that was on the button choosen. This means the range is a 20-meter radius centered on the object.

Q: Is there a way to extend (or narrow) the range?
A:
Not directly. You could use the listen event trigger a llShout or llRegionSay when it hears a dialog choice, but it doesn't appear to be possible to narrow the range unless you do something equivalent to an if/else and llVecDist.

Q: Do objects recieveing messages from the dialog require a certain command or event specific to dialogs, or is it just the standard llListen command and listen event?
A:
The button text is said on the channel specified, and can be heard through a standard listen event set to that specific channel. In other words, no, nothing fancy has to be done. It's just a normal listen event.


This article wasn't helpful for you? Maybe the related article at the LSL Portal is able to bring enlightenment.

Functions | Agent/Avatar | Chat | Communications | User-Interface
Comments [Hide comments/form]
So it seems that there is a 24 character limit on the text that can be saved in each button (not the display since it gets truncated for the button, but the actual text that gets 'said'). Any workarounds?
-- DriftwoodNomad (2004-10-22 19:24:53)
Annoyingly, it seems that the order of buttons in dialogs is screwey. Looks like they reverse the order of rows for some weird reason. Very odd if there's a button on a row by itself, because it appears at the top in a row by itself... so it's not possible to jus tfix this by rearranging the order of the buttons in the list.
-- LexNeva (2005-02-19 15:37:58)
I don't understand why the states code in this example is good scripting practice and why a timeout is not recommended. I'm modifying a script to use dialogs instead of continuous listening. The example given here leaves the listen in place whenever the last button clicked is "ignore". It seems to me that a timer is needed to get rid of the listen, so using states with duplicate touch_start code has no advantage. The timeout with llListenRemove of course has the disadvantage that the user could leave the dialog up for half an hour then press a button which would do nothing, but that seems a smaller weakness than leaving an unnecessary listen.
-- MeghanMagpie (2005-06-27 05:42:17)
Hey folks,

There's an eay bug that can happen with llDialog from the examples: from the SL Forums nand Nerd wrote: In the listen event you'll want to use the key id instead of llDetectedKey(0), as the llDetected* functions do not work with listen and are only applicable to touch, sensor and possible a few other events.

Your example actually shows this nicely, but without an explanation it is easy to miss.
-- MartinMommsen (2006-06-07 23:06:24)
You have that forum post on the teen forums as well?
-- Flarn2006 (2006-08-08 12:51:18)
I assume the return value of the function order_buttons() (2nd script example) should be fixt and not buttons ???
-- HeusDens (2007-07-10 15:26:48)
One thing that can happen with dialogue boxes is one dialogue's box may trigger someone else's menu when a person presses a button, if they are using the same application. The way to get around this is having the listen test for the dialogue's channel, and then test the key to see if it is the owner of the object that originated the dialogue box. This is especially useful for HUDs, where the owner of the object will be the only one pressing the buttons.
-- ip68-105-91-192.sd.sd.cox.net (2007-10-11 22:21:07)
Attach a comment to this page: