Second Life Wiki - User contributions [en]

LlDialog

2021-06-11T20:27:02Z

Darling Brody:

{{LSL_Function
|func=llDialog
|sort=Dialog
|func_id=247|func_sleep=1.0|func_energy=10.0
|inject-2=
{{Issues/VWR-17064}}
{{Issues/VWR-14537}}
{{Issues/SVC-1815}}
{{Issues/SCR-43}}
{{Issues/STORM-1718}}
{{LSL_Function/avatar|avatar|sim=*}}
{{LSL_Function/chat|channel|message|dialog=dialog box}}
|p1_type=key|p1_name=avatar|p1_desc
|p2_type=string|p2_name=message|p2_desc
|p3_type=list|p3_name=buttons|p3_desc=button labels
|p4_type=integer|p4_name=channel|p4_desc
|func_desc=Shows a dialog box in the lower right corner of the {{LSLP|avatar}}'s screen (upper right in Viewer 1.x) with a {{LSLP|message}} and choice {{LSLP|buttons}}, as well as an ignore button. This has many uses ranging from simple message delivery to complex menu systems.
|func_footnote=When a button is pressed, the {{LSLP|avatar}} says the text of the button label on {{LSLP|channel}}.<br/>The position where the chat is generated is where the root prim of the dialog generating object was when the dialog button was pressed.
|spec
|caveats=
*This function '''only''' opens a dialog box. The script must then also register a listener on the same ''channel'' using [[llListen]] and have a [[listen]] event handler to receive the response.
*There is no way by script to kill a dialog box.
*There is no way for the script to detect if the user clicked the small <code>["Ignore"]</code> button (no chat is generated as a result of pressing this button).
*There is no way to distinguish the input from a dialog box and regular chat made by the same user.
**It is important to expect that the response may not be one of the buttons.
*In most cases, the listener will be in the same script as the llDialog, however if not, the distance between the root prim of the [[listen]]ing object and the dialog generating prim becomes a factor. If this distance is greater than 20 meters when a button is pressed, the response will not be heard. See [[#Limits]].
**This limitation affects attachments too if the wearer moves more than 20 meters from where the listener is located. See [[#Limits]].
**If the [[listen]]er resides in the same script that created the dialog, then the dialog button is heard sim-wide.
*By default, only one dialog can be displayed per object in the Second Life Viewer. This can be overridden by the [[Debug_Settings|ScriptDialogLimitations debug setting]] in the Viewer.
----
*The '''dialog response''' (the generated chat) has its in world location at the '''root prim's global position'''.
: It can generate a listen event within 20 meters from that position.
*The listening location for a child prim in the object is either at the child prim's location or at the root prim's location
: see bugtrace JIRA [https://jira.secondlife.com/browse/SCR-43 SCR-43]

===<tt>message</tt> limits===
*{{LSLP|message}} must be fewer than 512 bytes in length and be not empty. If it is empty, [[llDialog]] will shout <code>"[[llDialog]]: must supply a message"</code> on the [[DEBUG_CHANNEL]]. If you want to create an empty message, however, you can do it legally by using a line feed as your message, as in <source lang="lsl2">llDialog(avatar_key," \n",button_list,dialog_channel);</source> If the message length is greater than or equal to 512 bytes, it shouts (again on the [[DEBUG_CHANNEL|debug channel]]): <code>"[[llDialog]]: message too long, must be less than 512 characters"</code>; in both instances, the dialog box will not be created for {{LSLP|avatar}}.
*The client only displays 20 lines of {{LSLP|message}} at a time, not counting the top line containing the owner and name of the object. If there are more than 20 lines the dialog displays a scroll bar. See [[#Appearance]].

===<tt>buttons</tt> limits===
*If {{LSLP|buttons}} is an empty list, it will default to as if it were <code>["OK"]</code>
*Buttons named "Client_Side_Mute" or "Client_Side_Ignore" will be interpreted by the viewer as if the user click the special "Mute" or "Ignore" buttons, respectively.
**Prior to [[Release_Notes/Second_Life_Release/3.3.1|SL viewer 3.3.1]] (released in 2012) the viewer treated the buttons with values of "Mute" and "Ignore" as being equivalent to the dialogs special buttons "Mute" and "Ignore". This was changed as a result of {{JIRA|STORM-1718}}. Some very old versions of some viewer, especially those with a V1-style interface, could still have this old behavior and should be tested.
**If you need a button in your menu that will collide with one of these special values, please consider adding spaces in the button name (e.g. <code>[" Ignore "]</code>).
*An error will be shouted on [[DEBUG_CHANNEL]], if...
**there are more than 12 buttons.
**any list item is not a string.
**any list item string length (measured in bytes, using UTF-8 encoding) is zero or greater than 24.
***In other words, a button's text when encoded as UTF-8 cannot be longer than 24 bytes or a empty string.
***This snippet can be used to truncate the string without giving an error: <code>[[llBase64ToString]]([[llGetSubString]]([[llStringToBase64]](theString), 0, 31))</code>
*The client will not display all the characters of a button if the text is wider than the text space of the button. See [[#Appearance]].
*If the script generates button labels from outside sources like inventory or object names, take care to avoid the special string <code>"!!llTextBox!!"</code>. This text, used as any button label, will cause [[llDialog]] to behave as [[llTextBox]] instead.
|examples=
<source lang="lsl2">
// When the prim is touched, give the toucher the option of killing the prim.

integer gListener; // Identity of the listener associated with the dialog, so we can clean up when not needed

default
{
touch_start(integer total_number)
{
// Kill off any outstanding listener, to avoid any chance of multiple listeners being active
llListenRemove(gListener);
// get the UUID of the person touching this prim
key user = llDetectedKey(0);
// Listen to any reply from that user only, and only on the same channel to be used by llDialog
// It's best to set up the listener before issuing the dialog
gListener = llListen(-99, "", user, "");
// Send a dialog to that person. We'll use a fixed negative channel number for simplicity
llDialog(user, "\nDo you wish this prim to die?", ["Yes", "No" ] , -99);
// Start a one-minute timer, after which we will stop listening for responses
llSetTimerEvent(60.0);
}
listen(integer chan, string name, key id, string msg)
{
// If the user clicked the "Yes" button, kill this prim.
if (msg == "Yes")
llDie();
// The user did not click "Yes" ...
// Make the timer fire immediately, to do clean-up actions
llSetTimerEvent(0.1);
}
timer()
{
// Stop listening. It's wise to do this to reduce lag
llListenRemove(gListener);
// Stop the timer now that its job is done
llSetTimerEvent(0.0);// you can use 0 as well to save memory
}
}
</source>
{{LSL Tip|Please make sure that you close open listeners where possible. You'll make the Second Life experience so much better when paying attention to details here.}}
{{LSL Tip|There are no built-in submenus nor pagination (like in a list with "previous" and "next") when using [[llDialog]]. You simply get one page with a max of 12 buttons, that's it. If you want a different dialog menu layout (other info and/or other buttons), you'll have to build that functionality into your script as the example below demonstrates. }}
<source lang="lsl2">
string mainMenuDialog = "\nWhich settings would you like to access?\nClick \"Close\" to close the menu.\n\nYou are here:\nMainmenu";
list mainMenuButtons = ["sub 01", "sub 02", "Close"];

string subMenu_01_Dialog = "\nClick \"Close\" to close the menu.\nClick \"-Main-\" to return to the main menu.\n\nYou are here:\nMainmenu > sub 01";
list subMenu_01_Buttons = ["action 01a", "action 01b", "Close", "-Main-"];

string subMenu_02_Dialog = "\nClick \"Close\" to close the menu.\nClick \"-Main-\" to return to the main menu.\n\nYou are here:\nMainmenu > sub 02";

list subMenu_02_Buttons = ["action 02a", "action 02b", "Close", "-Main-"];

integer dialogChannel;
integer dialogHandle;

open_menu(key inputKey, string inputString, list inputList)
{
dialogChannel = (integer)llFrand(DEBUG_CHANNEL)*-1;
dialogHandle = llListen(dialogChannel, "", inputKey, "");
llDialog(inputKey, inputString, inputList, dialogChannel);
llSetTimerEvent(30.0);
}

close_menu()
{
llSetTimerEvent(0.0);// you can use 0 as well to save memory
llListenRemove(dialogHandle);
}

default
{
on_rez(integer start_param)
{
llResetScript();
}

touch_start(integer total_number)
{
key id = llDetectedKey(0);
// Ensure any outstanding listener is removed before creating a new one
close_menu();
open_menu(id, mainMenuDialog, mainMenuButtons);
}

listen(integer channel, string name, key id, string message)
{
if(channel != dialogChannel)
return;

close_menu();

if(message == "-Main-")
open_menu(id, mainMenuDialog, mainMenuButtons);

else if(message == "sub 01")
open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);

else if(message == "sub 02")
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);

else if (message == "action 01a")
{
//do something
open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);
}
else if (message == "action 01b")
{
//do something else

//maybe not re-open the menu for this option?
//open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);
}
else if (message == "action 02a")
{
//do something
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);
}
else if (message == "action 02b")
{
//do something else
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);
}
}

timer()
{
close_menu();
}
}
</source>
|helpers=<source lang="lsl2">//Compact function to put buttons in "correct" human-readable order
integer channel;

list order_buttons(list buttons)
{
return llList2List(buttons, -3, -1) + llList2List(buttons, -6, -4)
+ llList2List(buttons, -9, -7) + llList2List(buttons, -12, -10);
}

default
{
state_entry()
{ // Create random channel within range [-1000000000,-2000000000]
channel = (integer)(llFrand(-1000000000.0) - 1000000000.0);

llListen(channel,"", "","");
}

touch_start(integer total_number)
{
llDialog(llDetectedKey(0),"\nPlease choose an option:\n",
order_buttons(["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"]),channel);
}

listen(integer _chan, string _name, key _id, string _option)
{
llSay(0, _name + " selected option " + _option);
}
}</source>
<source lang="lsl2">
list make_ordered_buttons(integer input)
{
string output;

if (input == 12) output = "10, 11, 12, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 11) output = "10, 11, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 10) output = "10, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 9) output = "7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 8) output = "7, 8, 4, 5, 6, 1, 2, 3";
else if (input == 7) output = "7, 4, 5, 6, 1, 2, 3";
else if (input == 6) output = "4, 5, 6, 1, 2, 3";
else if (input == 5) output = "4, 5, 1, 2, 3";
else if (input == 4) output = "4, 1, 2, 3";
else if (input == 3) output = "1, 2, 3";
else if (input == 2) output = "1, 2";
else if (input == 1) output = "1";

// when we want to return [] avoid returning [""] here

if (output == "") return [];
/* else convert output */ return llCSV2List(output);
}

// Usage:

llDialog(id, "dialog message", make_ordered_buttons(5), -37812);

// Output:

// - - -
// - - -
// - [ 4 ] [ 5 ]
// [ 1 ] [ 2 ] [ 3 ]
</source>
=== Helper Functions ===
{{{!}}
{{LSL DefineRow||[[User:Void_Singer/Functions#uDlgBtnPagList|uDlgBtnPagList]]|Compact Pagination for [[llDialog]] lists, remenu, and multi-user support}}
{{!}}}
|constants={{#vardefine:constants_nb}}
{{{!}}
{{!}}- valign="top"
{{!}}
{{{!}}{{Prettytable|style=margin-top:0;}}
{{!}}-{{Hl2}}
! colspan="4" {{!}} Button Order
{{!}}-
{{!}}9  
{{!}}10
{{!}}11
{{!}}-
{{!}}6
{{!}}7
{{!}}8  
{{!}}-
{{!}}3
{{!}}4
{{!}}5
{{!}}-
{{!}}0
{{!}}1
{{!}}2
{{!}}}
{{!}}
{{!}}}
|related
|notes=
To use dialog boxes to make menu systems, see [[Dialog Menus|Dialog Menus: A step by step guide]] (aimed at learners).

===Tips===
It is a good idea to use a very negative channel (if never more negative than the most negative 32-bit integer that is -2,147,483,648), ''e.g.'',
<source lang="lsl2">// Create random channel within range [-1000000000,-2000000000]
integer channel = (integer)(llFrand(-1000000000.0) - 1000000000.0);

llDialog(llDetectedKey(0), "Please choose one of the below options:",
["Yes", "No", "0", "1"], channel);</source>
Negative channels are popular for script communications because for years the standard SL client was unable to chat directly on those channels. However, since late 2016 both third party and the Linden Lab viewer can use negative channels from the chat bar. Previously, the only way for viewers to use negative channels prior to [[llTextBox]] was to use [[llDialog]], which was limited to 24 bytes.

You can be reasonably confident that all of your scripted objects have a unique chat channel with this small function:

<source lang="lsl2">integer dialog_channel; // top of script in variables

integer channel() { // top of script in functions
return (integer)("0x"+llGetSubString((string)llGetKey(),-8,-1));
}

dialog_channel = channel(); // somewhere in actual script execution, such as state_entry()</source>

'''Note:''' Since this function uses public information to generate the channel number it should by no means considered secret.

The preceding code can produce both positive and negative channels, depending on the 8th to last character of the key.
The following examples will always produce negative channels:-
<source lang="lsl2">
gChannel = 0x80000000 | (integer)("0x"+(string)llGetKey());
gChannel = 0x80000000 | (integer)("0x"+(string)llGetOwner());
</source>

This next version returns a channel number between -1073741823 (0xBFFFFFFF) and -2147483648 (0x80000000). It is also only one line of code.
<source lang="lsl2">privchan = ((integer)("0x"+llGetSubString((string)llGetKey(),-8,-1)) & 0x3FFFFFFF) ^ 0xBFFFFFFF;</source>

===Appearance===

If {{LSLP|message}} requires more than 8 lines, a vertical scroll bar will appear in the dialog.
: In viewer 3 there is no scroll bar, only the 512 chars message limit is effective, so you may show more than 40 short lines in the message
: Too many lines will hide some of the buttons or all of them outside the window though

The message text can be formatted somewhat using "\n" (for newline) and "\t" (for tab). If URLs are in the text, they will appear as clickable links, and some [[Viewer URI Name Space|viewer application URLs]] will receive special formatting. (Clickable links were not available before Viewer 2.) You can do nothing though to influence the font face, size or weight.

There is no way to change the actual size of the dialog, nor change its color.

The average number of characters that can be displayed on a dialog line is about 35 characters per line in ASCII7 characters. It depends upon the width of the characters, the viewer version, and font settings.

The number of characters that can be displayed in a button depends upon the width of the characters. You should expect around 10 chars, give or take, not the full 24 in the button definition. The full button definition IS said, up to 24 chars, into the chat channel even though fewer characters may be displayed in the button itself.

===Limits===

My testing shows the a Dialog box now works anywhere in the same Region as the object OR any region it hands you off to (e.g. the region you teleport to). It will not work for any subsequent hand offs. I have tested this with teleport only, I haven't tested it walking between regions.

I've tested from the next SIM with an Alt, and from 2 SIMs away myself. Both worked without restriction apart from some lag on the messages. (OQ).

|also_events=
{{LSL DefineRow||[[listen]]|}}
|also_functions=
{{LSL DefineRow||[[llListen]]|}}
{{LSL DefineRow||[[llTextBox]]|}}
{{LSL DefineRow||[[llRegionSay]]|}}
{{LSL DefineRow||[[llWhisper]]|Sends chat limited to 10 meters}}
{{LSL DefineRow||[[llSay]]|Sends chat limited to 20 meters}}
{{LSL DefineRow||[[llShout]]|Sends chat limited to 100 meters}}
{{LSL DefineRow||[[llInstantMessage]]|Sends chat to the specified user}}
{{LSL DefineRow||[[llOwnerSay]]|Sends chat to the owner only}}
|also_tests
|also_articles=
{{LSL DefineRow||[[Dialog Menus|Dialog Menus: A step by step guide]]|A walk through of the entire dialog menu process (aimed at learners).}}
|cat1=Chat
|cat2=Communications
|cat3=Dialog
|cat4
|haiku={{Haiku|click here click there. But,|read the options carefully|you might get a shock.}}
}}

LlDialog

2021-06-11T20:21:33Z

Darling Brody: Undo revision 1210092 by Darling Brody (talk)

{{LSL_Function
|func=llDialog
|sort=Dialog
|func_id=247|func_sleep=1.0|func_energy=10.0
|inject-2=
{{Issues/VWR-17064}}
{{Issues/VWR-14537}}
{{Issues/SVC-1815}}
{{Issues/SCR-43}}
{{Issues/STORM-1718}}
{{LSL_Function/avatar|avatar|sim=*}}
{{LSL_Function/chat|channel|message|dialog=dialog box}}
|p1_type=key|p1_name=avatar|p1_desc
|p2_type=string|p2_name=message|p2_desc
|p3_type=list|p3_name=buttons|p3_desc=button labels
|p4_type=integer|p4_name=channel|p4_desc
|func_desc=Shows a dialog box in the lower right corner of the {{LSLP|avatar}}'s screen (upper right in Viewer 1.x) with a {{LSLP|message}} and choice {{LSLP|buttons}}, as well as an ignore button. This has many uses ranging from simple message delivery to complex menu systems.
|func_footnote=When a button is pressed, the {{LSLP|avatar}} says the text of the button label on {{LSLP|channel}}.<br/>The position where the chat is generated is where the root prim of the dialog generating object was when the dialog button was pressed.
|spec
|caveats=
*This function '''only''' opens a dialog box. The script must then also register a listener on the same ''channel'' using [[llListen]] and have a [[listen]] event handler to receive the response.
*There is no way by script to kill a dialog box.
*There is no way for the script to detect if the user clicked the small <code>["Ignore"]</code> button (no chat is generated as a result of pressing this button).
*There is no way to distinguish the input from a dialog box and regular chat made by the same user.
**It is important to expect that the response may not be one of the buttons.
*In most cases, the listener will be in the same script as the llDialog, however if not, the distance between the root prim of the [[listen]]ing object and the dialog generating prim becomes a factor. If this distance is greater than 20 meters when a button is pressed, the response will not be heard. See [[#Limits]].
**This limitation affects attachments too if the wearer moves more than 20 meters from where the listener is located. See [[#Limits]].
**If the [[listen]]er resides in the same script that created the dialog, then the dialog button is heard sim-wide.
*By default, only one dialog can be displayed per object in the Second Life Viewer. This can be overridden by the [[Debug_Settings|ScriptDialogLimitations debug setting]] in the Viewer.
----
*The '''dialog response''' (the generated chat) has its in world location at the '''root prim's global position'''.
: It can generate a listen event within 20 meters from that position.
*The listening location for a child prim in the object is either at the child prim's location or at the root prim's location
: see bugtrace JIRA [https://jira.secondlife.com/browse/SCR-43 SCR-43]

===<tt>message</tt> limits===
*{{LSLP|message}} must be fewer than 512 bytes in length and be not empty. If it is empty, [[llDialog]] will shout <code>"[[llDialog]]: must supply a message"</code> on the [[DEBUG_CHANNEL]]. If you want to create an empty message, however, you can do it legally by using a line feed as your message, as in <source lang="lsl2">llDialog(avatar_key," \n",button_list,dialog_channel);</source> If the message length is greater than or equal to 512 bytes, it shouts (again on the [[DEBUG_CHANNEL|debug channel]]): <code>"[[llDialog]]: message too long, must be less than 512 characters"</code>; in both instances, the dialog box will not be created for {{LSLP|avatar}}.
*The client only displays 8 lines of {{LSLP|message}}. If it is longer, the dialog has a scroll bar. See [[#Appearance]].
Note: This should be 14 lines of message, not counting the extra (15th) line used for the owner and name of the object. The scroll bar does not appear beyond 14 lines in the official viewer. (tested June 2021)

===<tt>buttons</tt> limits===
*If {{LSLP|buttons}} is an empty list, it will default to as if it were <code>["OK"]</code>
*Buttons named "Client_Side_Mute" or "Client_Side_Ignore" will be interpreted by the viewer as if the user click the special "Mute" or "Ignore" buttons, respectively.
**Prior to [[Release_Notes/Second_Life_Release/3.3.1|SL viewer 3.3.1]] (released in 2012) the viewer treated the buttons with values of "Mute" and "Ignore" as being equivalent to the dialogs special buttons "Mute" and "Ignore". This was changed as a result of {{JIRA|STORM-1718}}. Some very old versions of some viewer, especially those with a V1-style interface, could still have this old behavior and should be tested.
**If you need a button in your menu that will collide with one of these special values, please consider adding spaces in the button name (e.g. <code>[" Ignore "]</code>).
*An error will be shouted on [[DEBUG_CHANNEL]], if...
**there are more than 12 buttons.
**any list item is not a string.
**any list item string length (measured in bytes, using UTF-8 encoding) is zero or greater than 24.
***In other words, a button's text when encoded as UTF-8 cannot be longer than 24 bytes or a empty string.
***This snippet can be used to truncate the string without giving an error: <code>[[llBase64ToString]]([[llGetSubString]]([[llStringToBase64]](theString), 0, 31))</code>
*The client will not display all the characters of a button if the text is wider than the text space of the button. See [[#Appearance]].
*If the script generates button labels from outside sources like inventory or object names, take care to avoid the special string <code>"!!llTextBox!!"</code>. This text, used as any button label, will cause [[llDialog]] to behave as [[llTextBox]] instead.
|examples=
<source lang="lsl2">
// When the prim is touched, give the toucher the option of killing the prim.

integer gListener; // Identity of the listener associated with the dialog, so we can clean up when not needed

default
{
touch_start(integer total_number)
{
// Kill off any outstanding listener, to avoid any chance of multiple listeners being active
llListenRemove(gListener);
// get the UUID of the person touching this prim
key user = llDetectedKey(0);
// Listen to any reply from that user only, and only on the same channel to be used by llDialog
// It's best to set up the listener before issuing the dialog
gListener = llListen(-99, "", user, "");
// Send a dialog to that person. We'll use a fixed negative channel number for simplicity
llDialog(user, "\nDo you wish this prim to die?", ["Yes", "No" ] , -99);
// Start a one-minute timer, after which we will stop listening for responses
llSetTimerEvent(60.0);
}
listen(integer chan, string name, key id, string msg)
{
// If the user clicked the "Yes" button, kill this prim.
if (msg == "Yes")
llDie();
// The user did not click "Yes" ...
// Make the timer fire immediately, to do clean-up actions
llSetTimerEvent(0.1);
}
timer()
{
// Stop listening. It's wise to do this to reduce lag
llListenRemove(gListener);
// Stop the timer now that its job is done
llSetTimerEvent(0.0);// you can use 0 as well to save memory
}
}
</source>
{{LSL Tip|Please make sure that you close open listeners where possible. You'll make the Second Life experience so much better when paying attention to details here.}}
{{LSL Tip|There are no built-in submenus nor pagination (like in a list with "previous" and "next") when using [[llDialog]]. You simply get one page with a max of 12 buttons, that's it. If you want a different dialog menu layout (other info and/or other buttons), you'll have to build that functionality into your script as the example below demonstrates. }}
<source lang="lsl2">
string mainMenuDialog = "\nWhich settings would you like to access?\nClick \"Close\" to close the menu.\n\nYou are here:\nMainmenu";
list mainMenuButtons = ["sub 01", "sub 02", "Close"];

string subMenu_01_Dialog = "\nClick \"Close\" to close the menu.\nClick \"-Main-\" to return to the main menu.\n\nYou are here:\nMainmenu > sub 01";
list subMenu_01_Buttons = ["action 01a", "action 01b", "Close", "-Main-"];

string subMenu_02_Dialog = "\nClick \"Close\" to close the menu.\nClick \"-Main-\" to return to the main menu.\n\nYou are here:\nMainmenu > sub 02";

list subMenu_02_Buttons = ["action 02a", "action 02b", "Close", "-Main-"];

integer dialogChannel;
integer dialogHandle;

open_menu(key inputKey, string inputString, list inputList)
{
dialogChannel = (integer)llFrand(DEBUG_CHANNEL)*-1;
dialogHandle = llListen(dialogChannel, "", inputKey, "");
llDialog(inputKey, inputString, inputList, dialogChannel);
llSetTimerEvent(30.0);
}

close_menu()
{
llSetTimerEvent(0.0);// you can use 0 as well to save memory
llListenRemove(dialogHandle);
}

default
{
on_rez(integer start_param)
{
llResetScript();
}

touch_start(integer total_number)
{
key id = llDetectedKey(0);
// Ensure any outstanding listener is removed before creating a new one
close_menu();
open_menu(id, mainMenuDialog, mainMenuButtons);
}

listen(integer channel, string name, key id, string message)
{
if(channel != dialogChannel)
return;

close_menu();

if(message == "-Main-")
open_menu(id, mainMenuDialog, mainMenuButtons);

else if(message == "sub 01")
open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);

else if(message == "sub 02")
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);

else if (message == "action 01a")
{
//do something
open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);
}
else if (message == "action 01b")
{
//do something else

//maybe not re-open the menu for this option?
//open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);
}
else if (message == "action 02a")
{
//do something
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);
}
else if (message == "action 02b")
{
//do something else
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);
}
}

timer()
{
close_menu();
}
}
</source>
|helpers=<source lang="lsl2">//Compact function to put buttons in "correct" human-readable order
integer channel;

list order_buttons(list buttons)
{
return llList2List(buttons, -3, -1) + llList2List(buttons, -6, -4)
+ llList2List(buttons, -9, -7) + llList2List(buttons, -12, -10);
}

default
{
state_entry()
{ // Create random channel within range [-1000000000,-2000000000]
channel = (integer)(llFrand(-1000000000.0) - 1000000000.0);

llListen(channel,"", "","");
}

touch_start(integer total_number)
{
llDialog(llDetectedKey(0),"\nPlease choose an option:\n",
order_buttons(["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"]),channel);
}

listen(integer _chan, string _name, key _id, string _option)
{
llSay(0, _name + " selected option " + _option);
}
}</source>
<source lang="lsl2">
list make_ordered_buttons(integer input)
{
string output;

if (input == 12) output = "10, 11, 12, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 11) output = "10, 11, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 10) output = "10, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 9) output = "7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 8) output = "7, 8, 4, 5, 6, 1, 2, 3";
else if (input == 7) output = "7, 4, 5, 6, 1, 2, 3";
else if (input == 6) output = "4, 5, 6, 1, 2, 3";
else if (input == 5) output = "4, 5, 1, 2, 3";
else if (input == 4) output = "4, 1, 2, 3";
else if (input == 3) output = "1, 2, 3";
else if (input == 2) output = "1, 2";
else if (input == 1) output = "1";

// when we want to return [] avoid returning [""] here

if (output == "") return [];
/* else convert output */ return llCSV2List(output);
}

// Usage:

llDialog(id, "dialog message", make_ordered_buttons(5), -37812);

// Output:

// - - -
// - - -
// - [ 4 ] [ 5 ]
// [ 1 ] [ 2 ] [ 3 ]
</source>
=== Helper Functions ===
{{{!}}
{{LSL DefineRow||[[User:Void_Singer/Functions#uDlgBtnPagList|uDlgBtnPagList]]|Compact Pagination for [[llDialog]] lists, remenu, and multi-user support}}
{{!}}}
|constants={{#vardefine:constants_nb}}
{{{!}}
{{!}}- valign="top"
{{!}}
{{{!}}{{Prettytable|style=margin-top:0;}}
{{!}}-{{Hl2}}
! colspan="4" {{!}} Button Order
{{!}}-
{{!}}9  
{{!}}10
{{!}}11
{{!}}-
{{!}}6
{{!}}7
{{!}}8  
{{!}}-
{{!}}3
{{!}}4
{{!}}5
{{!}}-
{{!}}0
{{!}}1
{{!}}2
{{!}}}
{{!}}
{{!}}}
|related
|notes=
To use dialog boxes to make menu systems, see [[Dialog Menus|Dialog Menus: A step by step guide]] (aimed at learners).

===Tips===
It is a good idea to use a very negative channel (if never more negative than the most negative 32-bit integer that is -2,147,483,648), ''e.g.'',
<source lang="lsl2">// Create random channel within range [-1000000000,-2000000000]
integer channel = (integer)(llFrand(-1000000000.0) - 1000000000.0);

llDialog(llDetectedKey(0), "Please choose one of the below options:",
["Yes", "No", "0", "1"], channel);</source>
Negative channels are popular for script communications because for years the standard SL client was unable to chat directly on those channels. However, since late 2016 both third party and the Linden Lab viewer can use negative channels from the chat bar. Previously, the only way for viewers to use negative channels prior to [[llTextBox]] was to use [[llDialog]], which was limited to 24 bytes.

You can be reasonably confident that all of your scripted objects have a unique chat channel with this small function:

<source lang="lsl2">integer dialog_channel; // top of script in variables

integer channel() { // top of script in functions
return (integer)("0x"+llGetSubString((string)llGetKey(),-8,-1));
}

dialog_channel = channel(); // somewhere in actual script execution, such as state_entry()</source>

'''Note:''' Since this function uses public information to generate the channel number it should by no means considered secret.

The preceding code can produce both positive and negative channels, depending on the 8th to last character of the key.
The following examples will always produce negative channels:-
<source lang="lsl2">
gChannel = 0x80000000 | (integer)("0x"+(string)llGetKey());
gChannel = 0x80000000 | (integer)("0x"+(string)llGetOwner());
</source>

This next version returns a channel number between -1073741823 (0xBFFFFFFF) and -2147483648 (0x80000000). It is also only one line of code.
<source lang="lsl2">privchan = ((integer)("0x"+llGetSubString((string)llGetKey(),-8,-1)) & 0x3FFFFFFF) ^ 0xBFFFFFFF;</source>

===Appearance===

If {{LSLP|message}} requires more than 8 lines, a vertical scroll bar will appear in the dialog.
: In viewer 3 there is no scroll bar, only the 512 chars message limit is effective, so you may show more than 40 short lines in the message
: Too many lines will hide some of the buttons or all of them outside the window though

The message text can be formatted somewhat using "\n" (for newline) and "\t" (for tab). If URLs are in the text, they will appear as clickable links, and some [[Viewer URI Name Space|viewer application URLs]] will receive special formatting. (Clickable links were not available before Viewer 2.) You can do nothing though to influence the font face, size or weight.

There is no way to change the actual size of the dialog, nor change its color.

The average number of characters that can be displayed on a dialog line is about 35 characters per line in ASCII7 characters. It depends upon the width of the characters, the viewer version, and font settings.

The number of characters that can be displayed in a button depends upon the width of the characters. You should expect around 10 chars, give or take, not the full 24 in the button definition. The full button definition IS said, up to 24 chars, into the chat channel even though fewer characters may be displayed in the button itself.

===Limits===

My testing shows the a Dialog box now works anywhere in the same Region as the object OR any region it hands you off to (e.g. the region you teleport to). It will not work for any subsequent hand offs. I have tested this with teleport only, I haven't tested it walking between regions.

I've tested from the next SIM with an Alt, and from 2 SIMs away myself. Both worked without restriction apart from some lag on the messages. (OQ).

|also_events=
{{LSL DefineRow||[[listen]]|}}
|also_functions=
{{LSL DefineRow||[[llListen]]|}}
{{LSL DefineRow||[[llTextBox]]|}}
{{LSL DefineRow||[[llRegionSay]]|}}
{{LSL DefineRow||[[llWhisper]]|Sends chat limited to 10 meters}}
{{LSL DefineRow||[[llSay]]|Sends chat limited to 20 meters}}
{{LSL DefineRow||[[llShout]]|Sends chat limited to 100 meters}}
{{LSL DefineRow||[[llInstantMessage]]|Sends chat to the specified user}}
{{LSL DefineRow||[[llOwnerSay]]|Sends chat to the owner only}}
|also_tests
|also_articles=
{{LSL DefineRow||[[Dialog Menus|Dialog Menus: A step by step guide]]|A walk through of the entire dialog menu process (aimed at learners).}}
|cat1=Chat
|cat2=Communications
|cat3=Dialog
|cat4
|haiku={{Haiku|click here click there. But,|read the options carefully|you might get a shock.}}
}}

LlDialog

2021-06-11T20:09:40Z

Darling Brody:

{{LSL_Function
|func=llDialog
|sort=Dialog
|func_id=247|func_sleep=1.0|func_energy=10.0
|inject-2=
{{Issues/VWR-17064}}
{{Issues/VWR-14537}}
{{Issues/SVC-1815}}
{{Issues/SCR-43}}
{{Issues/STORM-1718}}
{{LSL_Function/avatar|avatar|sim=*}}
{{LSL_Function/chat|channel|message|dialog=dialog box}}
|p1_type=key|p1_name=avatar|p1_desc
|p2_type=string|p2_name=message|p2_desc
|p3_type=list|p3_name=buttons|p3_desc=button labels
|p4_type=integer|p4_name=channel|p4_desc
|func_desc=Shows a dialog box in the lower right corner of the {{LSLP|avatar}}'s screen (upper right in Viewer 1.x) with a {{LSLP|message}} and choice {{LSLP|buttons}}, as well as an ignore button. This has many uses ranging from simple message delivery to complex menu systems.
|func_footnote=When a button is pressed, the {{LSLP|avatar}} says the text of the button label on {{LSLP|channel}}.<br/>The position where the chat is generated is where the root prim of the dialog generating object was when the dialog button was pressed.
|spec
|caveats=
*This function '''only''' opens a dialog box. The script must then also register a listener on the same ''channel'' using [[llListen]] and have a [[listen]] event handler to receive the response.
*There is no way by script to kill a dialog box.
*There is no way for the script to detect if the user clicked the small <code>["Ignore"]</code> button (no chat is generated as a result of pressing this button).
*There is no way to distinguish the input from a dialog box and regular chat made by the same user.
**It is important to expect that the response may not be one of the buttons.
*In most cases, the listener will be in the same script as the llDialog, however if not, the distance between the root prim of the [[listen]]ing object and the dialog generating prim becomes a factor. If this distance is greater than 20 meters when a button is pressed, the response will not be heard. See [[#Limits]].
**This limitation affects attachments too if the wearer moves more than 20 meters from where the listener is located. See [[#Limits]].
**If the [[listen]]er resides in the same script that created the dialog, then the dialog button is heard sim-wide.
*By default, only one dialog can be displayed per object in the Second Life Viewer. This can be overridden by the [[Debug_Settings|ScriptDialogLimitations debug setting]] in the Viewer.
----
*The '''dialog response''' (the generated chat) has its in world location at the '''root prim's global position'''.
: It can generate a listen event within 20 meters from that position.
*The listening location for a child prim in the object is either at the child prim's location or at the root prim's location
: see bugtrace JIRA [https://jira.secondlife.com/browse/SCR-43 SCR-43]

===<tt>message</tt> limits===
*{{LSLP|message}} must be fewer than 512 bytes in length and be not empty. If it is empty, [[llDialog]] will shout <code>"[[llDialog]]: must supply a message"</code> on the [[DEBUG_CHANNEL]]. If you want to create an empty message, however, you can do it legally by using a line feed as your message, as in <source lang="lsl2">llDialog(avatar_key," \n",button_list,dialog_channel);</source> If the message length is greater than or equal to 512 bytes, it shouts (again on the [[DEBUG_CHANNEL|debug channel]]): <code>"[[llDialog]]: message too long, must be less than 512 characters"</code>; in both instances, the dialog box will not be created for {{LSLP|avatar}}.
*The client displays 20 lines of {{LSLP|message}} not counting the extra line at the top which is used for the owner and name of the object. If there are more than 20 lines the scroll bar will be used. See [[#Appearance]].

===<tt>buttons</tt> limits===
*If {{LSLP|buttons}} is an empty list, it will default to as if it were <code>["OK"]</code>
*Buttons named "Client_Side_Mute" or "Client_Side_Ignore" will be interpreted by the viewer as if the user click the special "Mute" or "Ignore" buttons, respectively.
**Prior to [[Release_Notes/Second_Life_Release/3.3.1|SL viewer 3.3.1]] (released in 2012) the viewer treated the buttons with values of "Mute" and "Ignore" as being equivalent to the dialogs special buttons "Mute" and "Ignore". This was changed as a result of {{JIRA|STORM-1718}}. Some very old versions of some viewer, especially those with a V1-style interface, could still have this old behavior and should be tested.
**If you need a button in your menu that will collide with one of these special values, please consider adding spaces in the button name (e.g. <code>[" Ignore "]</code>).
*An error will be shouted on [[DEBUG_CHANNEL]], if...
**there are more than 12 buttons.
**any list item is not a string.
**any list item string length (measured in bytes, using UTF-8 encoding) is zero or greater than 24.
***In other words, a button's text when encoded as UTF-8 cannot be longer than 24 bytes or a empty string.
***This snippet can be used to truncate the string without giving an error: <code>[[llBase64ToString]]([[llGetSubString]]([[llStringToBase64]](theString), 0, 31))</code>
*The client will not display all the characters of a button if the text is wider than the text space of the button. See [[#Appearance]].
*If the script generates button labels from outside sources like inventory or object names, take care to avoid the special string <code>"!!llTextBox!!"</code>. This text, used as any button label, will cause [[llDialog]] to behave as [[llTextBox]] instead.
|examples=
<source lang="lsl2">
// When the prim is touched, give the toucher the option of killing the prim.

integer gListener; // Identity of the listener associated with the dialog, so we can clean up when not needed

default
{
touch_start(integer total_number)
{
// Kill off any outstanding listener, to avoid any chance of multiple listeners being active
llListenRemove(gListener);
// get the UUID of the person touching this prim
key user = llDetectedKey(0);
// Listen to any reply from that user only, and only on the same channel to be used by llDialog
// It's best to set up the listener before issuing the dialog
gListener = llListen(-99, "", user, "");
// Send a dialog to that person. We'll use a fixed negative channel number for simplicity
llDialog(user, "\nDo you wish this prim to die?", ["Yes", "No" ] , -99);
// Start a one-minute timer, after which we will stop listening for responses
llSetTimerEvent(60.0);
}
listen(integer chan, string name, key id, string msg)
{
// If the user clicked the "Yes" button, kill this prim.
if (msg == "Yes")
llDie();
// The user did not click "Yes" ...
// Make the timer fire immediately, to do clean-up actions
llSetTimerEvent(0.1);
}
timer()
{
// Stop listening. It's wise to do this to reduce lag
llListenRemove(gListener);
// Stop the timer now that its job is done
llSetTimerEvent(0.0);// you can use 0 as well to save memory
}
}
</source>
{{LSL Tip|Please make sure that you close open listeners where possible. You'll make the Second Life experience so much better when paying attention to details here.}}
{{LSL Tip|There are no built-in submenus nor pagination (like in a list with "previous" and "next") when using [[llDialog]]. You simply get one page with a max of 12 buttons, that's it. If you want a different dialog menu layout (other info and/or other buttons), you'll have to build that functionality into your script as the example below demonstrates. }}
<source lang="lsl2">
string mainMenuDialog = "\nWhich settings would you like to access?\nClick \"Close\" to close the menu.\n\nYou are here:\nMainmenu";
list mainMenuButtons = ["sub 01", "sub 02", "Close"];

string subMenu_01_Dialog = "\nClick \"Close\" to close the menu.\nClick \"-Main-\" to return to the main menu.\n\nYou are here:\nMainmenu > sub 01";
list subMenu_01_Buttons = ["action 01a", "action 01b", "Close", "-Main-"];

string subMenu_02_Dialog = "\nClick \"Close\" to close the menu.\nClick \"-Main-\" to return to the main menu.\n\nYou are here:\nMainmenu > sub 02";

list subMenu_02_Buttons = ["action 02a", "action 02b", "Close", "-Main-"];

integer dialogChannel;
integer dialogHandle;

open_menu(key inputKey, string inputString, list inputList)
{
dialogChannel = (integer)llFrand(DEBUG_CHANNEL)*-1;
dialogHandle = llListen(dialogChannel, "", inputKey, "");
llDialog(inputKey, inputString, inputList, dialogChannel);
llSetTimerEvent(30.0);
}

close_menu()
{
llSetTimerEvent(0.0);// you can use 0 as well to save memory
llListenRemove(dialogHandle);
}

default
{
on_rez(integer start_param)
{
llResetScript();
}

touch_start(integer total_number)
{
key id = llDetectedKey(0);
// Ensure any outstanding listener is removed before creating a new one
close_menu();
open_menu(id, mainMenuDialog, mainMenuButtons);
}

listen(integer channel, string name, key id, string message)
{
if(channel != dialogChannel)
return;

close_menu();

if(message == "-Main-")
open_menu(id, mainMenuDialog, mainMenuButtons);

else if(message == "sub 01")
open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);

else if(message == "sub 02")
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);

else if (message == "action 01a")
{
//do something
open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);
}
else if (message == "action 01b")
{
//do something else

//maybe not re-open the menu for this option?
//open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);
}
else if (message == "action 02a")
{
//do something
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);
}
else if (message == "action 02b")
{
//do something else
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);
}
}

timer()
{
close_menu();
}
}
</source>
|helpers=<source lang="lsl2">//Compact function to put buttons in "correct" human-readable order
integer channel;

list order_buttons(list buttons)
{
return llList2List(buttons, -3, -1) + llList2List(buttons, -6, -4)
+ llList2List(buttons, -9, -7) + llList2List(buttons, -12, -10);
}

default
{
state_entry()
{ // Create random channel within range [-1000000000,-2000000000]
channel = (integer)(llFrand(-1000000000.0) - 1000000000.0);

llListen(channel,"", "","");
}

touch_start(integer total_number)
{
llDialog(llDetectedKey(0),"\nPlease choose an option:\n",
order_buttons(["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"]),channel);
}

listen(integer _chan, string _name, key _id, string _option)
{
llSay(0, _name + " selected option " + _option);
}
}</source>
<source lang="lsl2">
list make_ordered_buttons(integer input)
{
string output;

if (input == 12) output = "10, 11, 12, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 11) output = "10, 11, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 10) output = "10, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 9) output = "7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 8) output = "7, 8, 4, 5, 6, 1, 2, 3";
else if (input == 7) output = "7, 4, 5, 6, 1, 2, 3";
else if (input == 6) output = "4, 5, 6, 1, 2, 3";
else if (input == 5) output = "4, 5, 1, 2, 3";
else if (input == 4) output = "4, 1, 2, 3";
else if (input == 3) output = "1, 2, 3";
else if (input == 2) output = "1, 2";
else if (input == 1) output = "1";

// when we want to return [] avoid returning [""] here

if (output == "") return [];
/* else convert output */ return llCSV2List(output);
}

// Usage:

llDialog(id, "dialog message", make_ordered_buttons(5), -37812);

// Output:

// - - -
// - - -
// - [ 4 ] [ 5 ]
// [ 1 ] [ 2 ] [ 3 ]
</source>
=== Helper Functions ===
{{{!}}
{{LSL DefineRow||[[User:Void_Singer/Functions#uDlgBtnPagList|uDlgBtnPagList]]|Compact Pagination for [[llDialog]] lists, remenu, and multi-user support}}
{{!}}}
|constants={{#vardefine:constants_nb}}
{{{!}}
{{!}}- valign="top"
{{!}}
{{{!}}{{Prettytable|style=margin-top:0;}}
{{!}}-{{Hl2}}
! colspan="4" {{!}} Button Order
{{!}}-
{{!}}9  
{{!}}10
{{!}}11
{{!}}-
{{!}}6
{{!}}7
{{!}}8  
{{!}}-
{{!}}3
{{!}}4
{{!}}5
{{!}}-
{{!}}0
{{!}}1
{{!}}2
{{!}}}
{{!}}
{{!}}}
|related
|notes=
To use dialog boxes to make menu systems, see [[Dialog Menus|Dialog Menus: A step by step guide]] (aimed at learners).

===Tips===
It is a good idea to use a very negative channel (if never more negative than the most negative 32-bit integer that is -2,147,483,648), ''e.g.'',
<source lang="lsl2">// Create random channel within range [-1000000000,-2000000000]
integer channel = (integer)(llFrand(-1000000000.0) - 1000000000.0);

llDialog(llDetectedKey(0), "Please choose one of the below options:",
["Yes", "No", "0", "1"], channel);</source>
Negative channels are popular for script communications because for years the standard SL client was unable to chat directly on those channels. However, since late 2016 both third party and the Linden Lab viewer can use negative channels from the chat bar. Previously, the only way for viewers to use negative channels prior to [[llTextBox]] was to use [[llDialog]], which was limited to 24 bytes.

You can be reasonably confident that all of your scripted objects have a unique chat channel with this small function:

<source lang="lsl2">integer dialog_channel; // top of script in variables

integer channel() { // top of script in functions
return (integer)("0x"+llGetSubString((string)llGetKey(),-8,-1));
}

dialog_channel = channel(); // somewhere in actual script execution, such as state_entry()</source>

'''Note:''' Since this function uses public information to generate the channel number it should by no means considered secret.

The preceding code can produce both positive and negative channels, depending on the 8th to last character of the key.
The following examples will always produce negative channels:-
<source lang="lsl2">
gChannel = 0x80000000 | (integer)("0x"+(string)llGetKey());
gChannel = 0x80000000 | (integer)("0x"+(string)llGetOwner());
</source>

This next version returns a channel number between -1073741823 (0xBFFFFFFF) and -2147483648 (0x80000000). It is also only one line of code.
<source lang="lsl2">privchan = ((integer)("0x"+llGetSubString((string)llGetKey(),-8,-1)) & 0x3FFFFFFF) ^ 0xBFFFFFFF;</source>

===Appearance===

If {{LSLP|message}} requires more than 20 lines, a vertical scroll bar will appear in the dialog.
: In viewer 3 there is no scroll bar, only the 512 chars message limit is effective, so you may show more than 40 short lines in the message
: In current 2021 viewer & Firestorm 20 lines can be displayed before the scroll bar appears with no limit other than the 512 memory to the number of lines.

The message text can be formatted somewhat using "\n" (for newline) and "\t" (for tab). If URLs are in the text, they will appear as clickable links, and some [[Viewer URI Name Space|viewer application URLs]] will receive special formatting. (Clickable links were not available before Viewer 2.) You can do nothing though to influence the font face, size or weight.

There is no way to change the actual size of the dialog, nor change its color.

The average number of characters that can be displayed on a dialog line is about 35 characters per line in ASCII7 characters. It depends upon the width of the characters, the viewer version, and font settings.

The number of characters that can be displayed in a button depends upon the width of the characters. You should expect around 10 chars, give or take, not the full 24 in the button definition. The full button definition IS said, up to 24 chars, into the chat channel even though fewer characters may be displayed in the button itself.

===Limits===

My testing shows the a Dialog box now works anywhere in the same Region as the object OR any region it hands you off to (e.g. the region you teleport to). It will not work for any subsequent hand offs. I have tested this with teleport only, I haven't tested it walking between regions.

I've tested from the next SIM with an Alt, and from 2 SIMs away myself. Both worked without restriction apart from some lag on the messages. (OQ).

|also_events=
{{LSL DefineRow||[[listen]]|}}
|also_functions=
{{LSL DefineRow||[[llListen]]|}}
{{LSL DefineRow||[[llTextBox]]|}}
{{LSL DefineRow||[[llRegionSay]]|}}
{{LSL DefineRow||[[llWhisper]]|Sends chat limited to 10 meters}}
{{LSL DefineRow||[[llSay]]|Sends chat limited to 20 meters}}
{{LSL DefineRow||[[llShout]]|Sends chat limited to 100 meters}}
{{LSL DefineRow||[[llInstantMessage]]|Sends chat to the specified user}}
{{LSL DefineRow||[[llOwnerSay]]|Sends chat to the owner only}}
|also_tests
|also_articles=
{{LSL DefineRow||[[Dialog Menus|Dialog Menus: A step by step guide]]|A walk through of the entire dialog menu process (aimed at learners).}}
|cat1=Chat
|cat2=Communications
|cat3=Dialog
|cat4
|haiku={{Haiku|click here click there. But,|read the options carefully|you might get a shock.}}
}}

LlDialog

2021-06-11T19:33:01Z

Darling Brody:

{{LSL_Function
|func=llDialog
|sort=Dialog
|func_id=247|func_sleep=1.0|func_energy=10.0
|inject-2=
{{Issues/VWR-17064}}
{{Issues/VWR-14537}}
{{Issues/SVC-1815}}
{{Issues/SCR-43}}
{{Issues/STORM-1718}}
{{LSL_Function/avatar|avatar|sim=*}}
{{LSL_Function/chat|channel|message|dialog=dialog box}}
|p1_type=key|p1_name=avatar|p1_desc
|p2_type=string|p2_name=message|p2_desc
|p3_type=list|p3_name=buttons|p3_desc=button labels
|p4_type=integer|p4_name=channel|p4_desc
|func_desc=Shows a dialog box in the lower right corner of the {{LSLP|avatar}}'s screen (upper right in Viewer 1.x) with a {{LSLP|message}} and choice {{LSLP|buttons}}, as well as an ignore button. This has many uses ranging from simple message delivery to complex menu systems.
|func_footnote=When a button is pressed, the {{LSLP|avatar}} says the text of the button label on {{LSLP|channel}}.<br/>The position where the chat is generated is where the root prim of the dialog generating object was when the dialog button was pressed.
|spec
|caveats=
*This function '''only''' opens a dialog box. The script must then also register a listener on the same ''channel'' using [[llListen]] and have a [[listen]] event handler to receive the response.
*There is no way by script to kill a dialog box.
*There is no way for the script to detect if the user clicked the small <code>["Ignore"]</code> button (no chat is generated as a result of pressing this button).
*There is no way to distinguish the input from a dialog box and regular chat made by the same user.
**It is important to expect that the response may not be one of the buttons.
*In most cases, the listener will be in the same script as the llDialog, however if not, the distance between the root prim of the [[listen]]ing object and the dialog generating prim becomes a factor. If this distance is greater than 20 meters when a button is pressed, the response will not be heard. See [[#Limits]].
**This limitation affects attachments too if the wearer moves more than 20 meters from where the listener is located. See [[#Limits]].
**If the [[listen]]er resides in the same script that created the dialog, then the dialog button is heard sim-wide.
*By default, only one dialog can be displayed per object in the Second Life Viewer. This can be overridden by the [[Debug_Settings|ScriptDialogLimitations debug setting]] in the Viewer.
----
*The '''dialog response''' (the generated chat) has its in world location at the '''root prim's global position'''.
: It can generate a listen event within 20 meters from that position.
*The listening location for a child prim in the object is either at the child prim's location or at the root prim's location
: see bugtrace JIRA [https://jira.secondlife.com/browse/SCR-43 SCR-43]

===<tt>message</tt> limits===
*{{LSLP|message}} must be fewer than 512 bytes in length and be not empty. If it is empty, [[llDialog]] will shout <code>"[[llDialog]]: must supply a message"</code> on the [[DEBUG_CHANNEL]]. If you want to create an empty message, however, you can do it legally by using a line feed as your message, as in <source lang="lsl2">llDialog(avatar_key," \n",button_list,dialog_channel);</source> If the message length is greater than or equal to 512 bytes, it shouts (again on the [[DEBUG_CHANNEL|debug channel]]): <code>"[[llDialog]]: message too long, must be less than 512 characters"</code>; in both instances, the dialog box will not be created for {{LSLP|avatar}}.
*The client only displays 8 lines of {{LSLP|message}}. If it is longer, the dialog has a scroll bar. See [[#Appearance]].
Note: This should be 14 lines of message, not counting the extra (15th) line used for the owner and name of the object. The scroll bar does not appear beyond 14 lines in the official viewer. (tested June 2021)

===<tt>buttons</tt> limits===
*If {{LSLP|buttons}} is an empty list, it will default to as if it were <code>["OK"]</code>
*Buttons named "Client_Side_Mute" or "Client_Side_Ignore" will be interpreted by the viewer as if the user click the special "Mute" or "Ignore" buttons, respectively.
**Prior to [[Release_Notes/Second_Life_Release/3.3.1|SL viewer 3.3.1]] (released in 2012) the viewer treated the buttons with values of "Mute" and "Ignore" as being equivalent to the dialogs special buttons "Mute" and "Ignore". This was changed as a result of {{JIRA|STORM-1718}}. Some very old versions of some viewer, especially those with a V1-style interface, could still have this old behavior and should be tested.
**If you need a button in your menu that will collide with one of these special values, please consider adding spaces in the button name (e.g. <code>[" Ignore "]</code>).
*An error will be shouted on [[DEBUG_CHANNEL]], if...
**there are more than 12 buttons.
**any list item is not a string.
**any list item string length (measured in bytes, using UTF-8 encoding) is zero or greater than 24.
***In other words, a button's text when encoded as UTF-8 cannot be longer than 24 bytes or a empty string.
***This snippet can be used to truncate the string without giving an error: <code>[[llBase64ToString]]([[llGetSubString]]([[llStringToBase64]](theString), 0, 31))</code>
*The client will not display all the characters of a button if the text is wider than the text space of the button. See [[#Appearance]].
*If the script generates button labels from outside sources like inventory or object names, take care to avoid the special string <code>"!!llTextBox!!"</code>. This text, used as any button label, will cause [[llDialog]] to behave as [[llTextBox]] instead.
|examples=
<source lang="lsl2">
// When the prim is touched, give the toucher the option of killing the prim.

integer gListener; // Identity of the listener associated with the dialog, so we can clean up when not needed

default
{
touch_start(integer total_number)
{
// Kill off any outstanding listener, to avoid any chance of multiple listeners being active
llListenRemove(gListener);
// get the UUID of the person touching this prim
key user = llDetectedKey(0);
// Listen to any reply from that user only, and only on the same channel to be used by llDialog
// It's best to set up the listener before issuing the dialog
gListener = llListen(-99, "", user, "");
// Send a dialog to that person. We'll use a fixed negative channel number for simplicity
llDialog(user, "\nDo you wish this prim to die?", ["Yes", "No" ] , -99);
// Start a one-minute timer, after which we will stop listening for responses
llSetTimerEvent(60.0);
}
listen(integer chan, string name, key id, string msg)
{
// If the user clicked the "Yes" button, kill this prim.
if (msg == "Yes")
llDie();
// The user did not click "Yes" ...
// Make the timer fire immediately, to do clean-up actions
llSetTimerEvent(0.1);
}
timer()
{
// Stop listening. It's wise to do this to reduce lag
llListenRemove(gListener);
// Stop the timer now that its job is done
llSetTimerEvent(0.0);// you can use 0 as well to save memory
}
}
</source>
{{LSL Tip|Please make sure that you close open listeners where possible. You'll make the Second Life experience so much better when paying attention to details here.}}
{{LSL Tip|There are no built-in submenus nor pagination (like in a list with "previous" and "next") when using [[llDialog]]. You simply get one page with a max of 12 buttons, that's it. If you want a different dialog menu layout (other info and/or other buttons), you'll have to build that functionality into your script as the example below demonstrates. }}
<source lang="lsl2">
string mainMenuDialog = "\nWhich settings would you like to access?\nClick \"Close\" to close the menu.\n\nYou are here:\nMainmenu";
list mainMenuButtons = ["sub 01", "sub 02", "Close"];

string subMenu_01_Dialog = "\nClick \"Close\" to close the menu.\nClick \"-Main-\" to return to the main menu.\n\nYou are here:\nMainmenu > sub 01";
list subMenu_01_Buttons = ["action 01a", "action 01b", "Close", "-Main-"];

string subMenu_02_Dialog = "\nClick \"Close\" to close the menu.\nClick \"-Main-\" to return to the main menu.\n\nYou are here:\nMainmenu > sub 02";

list subMenu_02_Buttons = ["action 02a", "action 02b", "Close", "-Main-"];

integer dialogChannel;
integer dialogHandle;

open_menu(key inputKey, string inputString, list inputList)
{
dialogChannel = (integer)llFrand(DEBUG_CHANNEL)*-1;
dialogHandle = llListen(dialogChannel, "", inputKey, "");
llDialog(inputKey, inputString, inputList, dialogChannel);
llSetTimerEvent(30.0);
}

close_menu()
{
llSetTimerEvent(0.0);// you can use 0 as well to save memory
llListenRemove(dialogHandle);
}

default
{
on_rez(integer start_param)
{
llResetScript();
}

touch_start(integer total_number)
{
key id = llDetectedKey(0);
// Ensure any outstanding listener is removed before creating a new one
close_menu();
open_menu(id, mainMenuDialog, mainMenuButtons);
}

listen(integer channel, string name, key id, string message)
{
if(channel != dialogChannel)
return;

close_menu();

if(message == "-Main-")
open_menu(id, mainMenuDialog, mainMenuButtons);

else if(message == "sub 01")
open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);

else if(message == "sub 02")
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);

else if (message == "action 01a")
{
//do something
open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);
}
else if (message == "action 01b")
{
//do something else

//maybe not re-open the menu for this option?
//open_menu(id, subMenu_01_Dialog, subMenu_01_Buttons);
}
else if (message == "action 02a")
{
//do something
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);
}
else if (message == "action 02b")
{
//do something else
open_menu(id, subMenu_02_Dialog, subMenu_02_Buttons);
}
}

timer()
{
close_menu();
}
}
</source>
|helpers=<source lang="lsl2">//Compact function to put buttons in "correct" human-readable order
integer channel;

list order_buttons(list buttons)
{
return llList2List(buttons, -3, -1) + llList2List(buttons, -6, -4)
+ llList2List(buttons, -9, -7) + llList2List(buttons, -12, -10);
}

default
{
state_entry()
{ // Create random channel within range [-1000000000,-2000000000]
channel = (integer)(llFrand(-1000000000.0) - 1000000000.0);

llListen(channel,"", "","");
}

touch_start(integer total_number)
{
llDialog(llDetectedKey(0),"\nPlease choose an option:\n",
order_buttons(["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"]),channel);
}

listen(integer _chan, string _name, key _id, string _option)
{
llSay(0, _name + " selected option " + _option);
}
}</source>
<source lang="lsl2">
list make_ordered_buttons(integer input)
{
string output;

if (input == 12) output = "10, 11, 12, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 11) output = "10, 11, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 10) output = "10, 7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 9) output = "7, 8, 9, 4, 5, 6, 1, 2, 3";
else if (input == 8) output = "7, 8, 4, 5, 6, 1, 2, 3";
else if (input == 7) output = "7, 4, 5, 6, 1, 2, 3";
else if (input == 6) output = "4, 5, 6, 1, 2, 3";
else if (input == 5) output = "4, 5, 1, 2, 3";
else if (input == 4) output = "4, 1, 2, 3";
else if (input == 3) output = "1, 2, 3";
else if (input == 2) output = "1, 2";
else if (input == 1) output = "1";

// when we want to return [] avoid returning [""] here

if (output == "") return [];
/* else convert output */ return llCSV2List(output);
}

// Usage:

llDialog(id, "dialog message", make_ordered_buttons(5), -37812);

// Output:

// - - -
// - - -
// - [ 4 ] [ 5 ]
// [ 1 ] [ 2 ] [ 3 ]
</source>
=== Helper Functions ===
{{{!}}
{{LSL DefineRow||[[User:Void_Singer/Functions#uDlgBtnPagList|uDlgBtnPagList]]|Compact Pagination for [[llDialog]] lists, remenu, and multi-user support}}
{{!}}}
|constants={{#vardefine:constants_nb}}
{{{!}}
{{!}}- valign="top"
{{!}}
{{{!}}{{Prettytable|style=margin-top:0;}}
{{!}}-{{Hl2}}
! colspan="4" {{!}} Button Order
{{!}}-
{{!}}9  
{{!}}10
{{!}}11
{{!}}-
{{!}}6
{{!}}7
{{!}}8  
{{!}}-
{{!}}3
{{!}}4
{{!}}5
{{!}}-
{{!}}0
{{!}}1
{{!}}2
{{!}}}
{{!}}
{{!}}}
|related
|notes=
To use dialog boxes to make menu systems, see [[Dialog Menus|Dialog Menus: A step by step guide]] (aimed at learners).

===Tips===
It is a good idea to use a very negative channel (if never more negative than the most negative 32-bit integer that is -2,147,483,648), ''e.g.'',
<source lang="lsl2">// Create random channel within range [-1000000000,-2000000000]
integer channel = (integer)(llFrand(-1000000000.0) - 1000000000.0);

llDialog(llDetectedKey(0), "Please choose one of the below options:",
["Yes", "No", "0", "1"], channel);</source>
Negative channels are popular for script communications because for years the standard SL client was unable to chat directly on those channels. However, since late 2016 both third party and the Linden Lab viewer can use negative channels from the chat bar. Previously, the only way for viewers to use negative channels prior to [[llTextBox]] was to use [[llDialog]], which was limited to 24 bytes.

You can be reasonably confident that all of your scripted objects have a unique chat channel with this small function:

<source lang="lsl2">integer dialog_channel; // top of script in variables

integer channel() { // top of script in functions
return (integer)("0x"+llGetSubString((string)llGetKey(),-8,-1));
}

dialog_channel = channel(); // somewhere in actual script execution, such as state_entry()</source>

'''Note:''' Since this function uses public information to generate the channel number it should by no means considered secret.

The preceding code can produce both positive and negative channels, depending on the 8th to last character of the key.
The following examples will always produce negative channels:-
<source lang="lsl2">
gChannel = 0x80000000 | (integer)("0x"+(string)llGetKey());
gChannel = 0x80000000 | (integer)("0x"+(string)llGetOwner());
</source>

This next version returns a channel number between -1073741823 (0xBFFFFFFF) and -2147483648 (0x80000000). It is also only one line of code.
<source lang="lsl2">privchan = ((integer)("0x"+llGetSubString((string)llGetKey(),-8,-1)) & 0x3FFFFFFF) ^ 0xBFFFFFFF;</source>

===Appearance===

If {{LSLP|message}} requires more than 8 lines, a vertical scroll bar will appear in the dialog.
: In viewer 3 there is no scroll bar, only the 512 chars message limit is effective, so you may show more than 40 short lines in the message
: Too many lines will hide some of the buttons or all of them outside the window though

The message text can be formatted somewhat using "\n" (for newline) and "\t" (for tab). If URLs are in the text, they will appear as clickable links, and some [[Viewer URI Name Space|viewer application URLs]] will receive special formatting. (Clickable links were not available before Viewer 2.) You can do nothing though to influence the font face, size or weight.

There is no way to change the actual size of the dialog, nor change its color.

The average number of characters that can be displayed on a dialog line is about 35 characters per line in ASCII7 characters. It depends upon the width of the characters, the viewer version, and font settings.

The number of characters that can be displayed in a button depends upon the width of the characters. You should expect around 10 chars, give or take, not the full 24 in the button definition. The full button definition IS said, up to 24 chars, into the chat channel even though fewer characters may be displayed in the button itself.

===Limits===

My testing shows the a Dialog box now works anywhere in the same Region as the object OR any region it hands you off to (e.g. the region you teleport to). It will not work for any subsequent hand offs. I have tested this with teleport only, I haven't tested it walking between regions.

I've tested from the next SIM with an Alt, and from 2 SIMs away myself. Both worked without restriction apart from some lag on the messages. (OQ).

|also_events=
{{LSL DefineRow||[[listen]]|}}
|also_functions=
{{LSL DefineRow||[[llListen]]|}}
{{LSL DefineRow||[[llTextBox]]|}}
{{LSL DefineRow||[[llRegionSay]]|}}
{{LSL DefineRow||[[llWhisper]]|Sends chat limited to 10 meters}}
{{LSL DefineRow||[[llSay]]|Sends chat limited to 20 meters}}
{{LSL DefineRow||[[llShout]]|Sends chat limited to 100 meters}}
{{LSL DefineRow||[[llInstantMessage]]|Sends chat to the specified user}}
{{LSL DefineRow||[[llOwnerSay]]|Sends chat to the owner only}}
|also_tests
|also_articles=
{{LSL DefineRow||[[Dialog Menus|Dialog Menus: A step by step guide]]|A walk through of the entire dialog menu process (aimed at learners).}}
|cat1=Chat
|cat2=Communications
|cat3=Dialog
|cat4
|haiku={{Haiku|click here click there. But,|read the options carefully|you might get a shock.}}
}}

Control

2020-10-21T15:49:29Z

Darling Brody: Added information about CONTROL_FWD and CONTROL_BACK being triggered together after a teleport, and how to fix the bug.

{{LSL_Event
|inject-2={{Issues/SCR-97}}{{Issues/SVC-3187}}{{LSL Function/avatar|id|}}
|event_id=15|event_delay=0.05|event=control
|p1_type=key|p1_name=id|p1_desc
|p2_type=integer|p2_subtype=bit_field|p2_name=level|p2_desc=bitfield of CONTROL_* flags, non-zero while one or more keys is being held down.
|p3_type=integer|p3_subtype=bit_field|p3_name=edge|p3_desc=bitfield of CONTROL_* flags, non-zero when one or more keys have been just pressed or released.
|event_desc=Result of [[llTakeControls]] library function call and user input.
|constants={{LSL Constants/Controls}}
|spec
|caveats=*[[CONTROL_ROT_LEFT]] and [[CONTROL_ROT_RIGHT]] can be triggered when an object is selected or edited. If the user is running Viewer 2.0 and later, [[llGetAgentInfo]] will have [[AGENT_AUTOPILOT]] set in this case.
**Autopilot control events can continue for a short time after AGENT_AUTOPILOT drops.
*The 'levels' and 'edges' of the control() event both receive ([[CONTROL_FWD]] + [[CONTROL_BACK]]) (value 3) after teleport, effecting scripts that use this combination for faster movement. Calling llTakeControls() again after a llSleep(3) will filter this out.

|examples=<source lang="lsl2">default
{
state_entry()
{
llRequestPermissions(llGetOwner(), PERMISSION_TAKE_CONTROLS);
}
run_time_permissions(integer perm)
{
if(PERMISSION_TAKE_CONTROLS & perm)
{
llTakeControls(
CONTROL_FWD |
CONTROL_BACK |
CONTROL_LEFT |
CONTROL_RIGHT |
CONTROL_ROT_LEFT |
CONTROL_ROT_RIGHT |
CONTROL_UP |
CONTROL_DOWN |
CONTROL_LBUTTON |
CONTROL_ML_LBUTTON |
0, TRUE, FALSE);
// | 0 is for edit convenience,
// it does not change the mask.
}
}
control(key id, integer level, integer edge)
{
integer start = level & edge;
integer end = ~level & edge;
integer held = level & ~edge;
integer untouched = ~(level | edge);
llOwnerSay(llList2CSV([level, edge, start, end, held, untouched]));
}
}</source>
|helpers
|also_header
|also_events={{LSL DefineRow||[[run_time_permissions]]}}
|also_functions={{LSL DefineRow||[[llTakeControls]]}}
{{LSL DefineRow||[[llReleaseControls]]}}
{{LSL DefineRow||[[llRequestPermissions]]}}
|also_tests
|also_articles
|also_footer
|notes=[[llGetRot]] in [[mouselook]] for an attachment returns the angle the avatar is looking in.

There are some bugs when you put two scripts in the same prim and call LlTakeControls(), the '''id''' may not be the intended one. See [http://jira.secondlife.com/browse/SVC-3187 SVC-3187].
|mode
|issues
|cat1=Controls
|cat2
|cat3
|cat4
}}

User:Darling Brody

2013-11-19T23:02:03Z

Darling Brody:

'''
== Darling Brody ==
'''

Either an annoying griefer or a programmer with a passion for creating.

Darling Brody founded Quantum Products in 2006 when she made her first teleporters. The following year she branched out into weapons because there wasn't any money in selling teleporters.

Darling Brody is best known for her Quantum Core and QHUD, but still prefers to work on teleporters because "the special effects are so sparkly". To date there are dozens of different teleporters, terraforming tools, etc created by her on sale in the region QUANTUM as well as a selection of weapons too.

Most people have very strong opinions of Darling Brody. They either love her or hate her. This love/hate relationship seems to be closely linked to "who owns her weapons, and who gets owned by her weapons". Either way Darling Brody has never been punished for griefing, so her reputation as a grifer is probably just cleaver marketing ;)

While she is known to be very friendly and helpful to her customers and strangers alike, she is also known to be completely uncooperative when people are rude to her. Of course none of us would ever be silly enough to be rude to a weapons maker, right?

Darling Brody is well known by many Lindens as someone who helps to fix bugs and plug content theft methods. She is also active in the JIRA opposing changes that break content. She has often fought to have useful bugs retained as a feature, such as the longer avatar Link Distance when sitting on a prim, and retaining the JumpPos bug until the llSetRegionPos() function was completed.

She has been a long time advocate of protecting content from theft. Ironical she has fallen victim to content theft several times, having her scripts used as the base to create competing products. Most notably the Quantum Core v3 scripts were stolen, resulting in a number of copycat products hitting the market. Darling responded by tossing out the old Quantum Core v3 scripts and starting a new product line from scratch called QHUD which included script theft protection.

In 2009 darling Brody had a Real Life mental breakdown that left her homeless for several years. Her products were not updated as often while she was homeless, however they stood the test of time and remained relevant despite the infrequent updates.

Today Darling is busy writing new updates and creating new products.

As Darling says "'''When life gets you down, orbit yourself.'''"

LSL Protocol/Teleport Helper Protocol

2013-11-19T23:01:08Z

Darling Brody:

'''Teleport Helper Protocol'''

A protocol that fixes the limitations in the llTeleportAgent* functions, avoids broken content, and blocks any possible abuse.

Useful for : Star Gates, Quantum Portals, Teleporter Platforms, Tours, etc...

The purpose of this protocol is to allow land owners to teleport visitors without the visitors needing to sit on objects.

The new Linden teleport functions are fantastic but they only work on the script's owner.

To make the new teleport functions useful they need to work on people who are visiting your land, while blocking any possibility for abuse.

The way to do this is to wear a script which will teleport you on request, while still asking you before doing so.

If enough people include this script into their HUDs, hair, shoes, etc the Linden teleport commands will become useful everywhere.

Details:-

This script will listen on channel 86400000 for the teleport command. (and other commands as the protocol is expanded)

command format "teleport[region_name~region_position~look_at_position]"
region_name : is the plain text name of the target region
region_position : is a vector for the local position in the region, <0-255, 0-255, 0-4096>
look_at_position : is a vector for the position the avatar should be turned to face, <0-255, 0-255, 0>.
eg: llRegionSayTo(AvatarUUID,86400000,"teleport[quantum~<128, 128, 500>~<0, 128, 0>]");

Note:

The ~ character is used as a field delimiter because it is not used by any variables, such as the comma in a vector, or the pipe in some chat commands.

Commands are a single word with their parameters enclosed in the [] brackets. Additional parameters may be added so long as they are added to the end of the existing parameters. eg: delete[object name] or teleport[quantum~<128, 128, 500>~<0, 128, 0>]]

llWhisper(), llSay(), llShout(), and llRegionSay() can all be used to deliver the teleport[] command to groups of people. While llRegionSayTo() is proffered for sending the command to one person only.

Features:-

Only works if the request comes from an object owned by the land owner. Group owned land requires group owned objects.
Limit of one teleport per minute to avoid spamming.
Permissions are dropped after use.
Only one teleport is offered, regardless of how many copies of the script is worn.

To Do:-

Make this page look nice with some formatting

Delete[object_name] Delete the script from the named object so people can remove duplicates they know they will never need. Must check that the owner send this command.

Expand this script to support any other protocols that are used in custom products, such as some star gates.

---------------

<lsl>
vector global_coordinates;
vector region_coordinates;
vector look_at;
integer Priority;
integer Active = TRUE; // Default is Active
key reqID;
default
{
on_rez(integer param)
{
llResetScript();
}
attach(key id)
{
if (id == NULL_KEY) llRegionSayTo(llGetOwner(),86400000,"1"); // on detach try to re-enable other scripts that may be inActive
}
state_entry()
{
llListen(86400000,"","",""); // used to receive teleport commands and set controller priority
Priority = (integer)((llFrand(10000)*10000)+2); // Pick a Priority
llRegionSayTo(llGetOwner(),86400000,(string)Priority); // share the Priority
}
listen(integer channel, string name, key id, string message)
{
if ((integer)message > 0) // Priority received
{
if ((integer)message > Priority) // compare my Priority with received one
{
Active = FALSE; // set inActive because I have a lower priority
return;
}
else
{
Active = TRUE; // set Active because I have a higher priority
llRegionSayTo(llGetOwner(),86400000,(string)Priority); // share my higher priority to set other script(s) inActive
return;
}
}

if ((llSubStringIndex(message,"teleport[") == 0) && (Active == TRUE)) // teleport command & Active Mode
{
if (llGetLandOwnerAt(llGetPos()) != llGetOwnerKey(id)) return; // must come from owner of land under avatar
list command = llParseString2List(message,["teleport[","~","]"],[]); // extract destination details
region_coordinates = (vector)llList2String(command,1); // save destination position
look_at = (vector)llList2String(command,2); // save look at position
reqID = llRequestSimulatorData(llList2String(command,0), DATA_SIM_POS); // request region position
return;
}
}

dataserver(key query_id, string data)
{
if (reqID != query_id) return; // filter out irralavant queries
global_coordinates = (vector)data; // save region position
llRequestPermissions(llGetOwner(), PERMISSION_TELEPORT); // request permission to teleport
// Active = FALSE; // Optional to avoid spamming additional permission requests when the last one wasn't answered
}

run_time_permissions(integer perm)
{
if (perm & PERMISSION_TELEPORT)
{
llUnSit(llGetOwner()); // sitting avatar will not teleport
llTeleportAgentGlobalCoords( llGetOwner(), global_coordinates, region_coordinates, look_at); // teleport
// avoid teleport spam by resetting after a pause
llSleep(60);
llResetScript();
}
}
}
</lsl>

User:Darling Brody

2013-11-19T21:56:40Z

Darling Brody:

'''Darling Brody'''

Either an annoying griefer or a programmer with a passion for creating.

Darling Brody founded Quantum Products in 2006 when she made her first teleporters. The following year she branched out into weapons because there wasn't any money in selling teleporters.

Darling Brody is best known for her Quantum Core and QHUD, but still prefers to work on teleporters because "the special effects are so sparkly". To date there are dozens of different teleporters, terraforming tools, etc created by her on sale in the region QUANTUM as well as a selection of weapons too.

Most people have very strong opinions of Darling Brody. They either love her or hate her. This love/hate relationship seems to be closely linked to "who owns her weapons, and who gets owned by her weapons". Either way Darling Brody has never been punished for griefing, so her reputation as a grifer is probably just cleaver marketing ;)

While she is known to be very friendly and helpful to her customers and strangers alike, she is also known to be completely uncooperative when people are rude to her. Of course none of us would ever be silly enough to be rude to a weapons maker, right?

Darling Brody is well known by many Lindens as someone who helps to fix bugs and plug content theft methods. She is also active in the JIRA opposing changes that break content. She has often fought to have useful bugs retained as a feature, such as the longer avatar Link Distance when sitting on a prim, and retaining the JumpPos bug until the llSetRegionPos() function was completed.

She has been a long time advocate of protecting content from theft. Ironical she has fallen victim to content theft several times, having her scripts used as the base to create competing products. Most notably the Quantum Core v3 scripts were stolen, resulting in a number of copycat products hitting the market. Darling responded by tossing out the old Quantum Core v3 scripts and starting a new product line from scratch called QHUD which included script theft protection.

In 2009 darling Brody had a Real Life mental breakdown that left her homeless for several years. Her products were not updated as often while she was homeless, however they stood the test of time and remained relevant despite the infrequent updates.

Today Darling is busy writing new updates and creating new products.

As Darling says "'''When life gets you down, orbit yourself.'''"

User:Darling Brody

2013-11-19T21:54:25Z

Darling Brody:

'''Darling Brody'''

Either an annoying griefer or a programmer with a passion for creating.

Darling Brody founded Quantum Products in 2006 when she made her first teleporters. The following year she branched out into weapons because there wasn't any money in selling teleporters.

Darling Brody is best known for her Quantum Core and QHUD, but still prefers to work on teleporters because "the special effects are so sparkly". To date there are dozens of different teleporters, terraforming tools, etc created by her on sale in the region QUANTUM as well as a selection of weapons too.

Most people have very strong opinions of Darling Brody. They either love her or hate her. This love/hate relationship seems to be closely linked to "who owns her weapons, and who gets owned by her weapons". Either way Darling Brody has never been punished for griefing, so her reputation as a grifer is probably just cleaver marketing ;)

While she is known to be very friendly and helpful to her customers and strangers alike, she is also known to be completely uncooperative when people are rude to her. Of course none of us would ever be silly enough to be rude to a weapons maker, right?

Darling Brody is well known by many Lindens as someone who helps to fix bugs and plug content theft methods. She is also active in the JIRA opposing changes that break content. She has often fought to have useful bugs retained as a feature, such as the longer avatar Link Distance when sitting on a prim, and retaining the JumpPos bug until the llSetRegionPos() function was completed.

Darling Brody has been a long time advocate of protecting content from theft. Ironical she has fallen victim to content theft several times, having her scripts used as the base to create competing products. Most notably the Quantum Core v3 scripts were stolen, resulting in a number of copycat products hitting the market. Darling responded by tossing out the old Quantum Core v3 scripts and starting a new product line from scratch called QHUD which included script theft protection.

In 2009 darling Brody had a Real Life mental breakdown that left her homeless for several years. Her products were not updated as often while she was homeless, however they stood the test of time and remained relevant despite the infrequent updates.

Today Darling is busy writing new updates and creating new products.

As Darling says "'''When life gets you down, orbit yourself.'''"

User:Darling Brody

2013-11-19T21:47:25Z

Darling Brody: Created page with "'''Darling Brody''' Either an annoying griefer or a programmer with a passion for creating. Darling Brody founded Quantum Products in 2006 when she made her first teleporters.…"

'''Darling Brody'''

Either an annoying griefer or a programmer with a passion for creating.

Darling Brody founded Quantum Products in 2006 when she made her first teleporters. The following year she branched out into weapons because there wasn't any money in selling teleporters.

Darling Brody is best known for her Quantum Core and QHUD, but still prefers to work on teleporters because "the special effects are so sparkly". To date there are dozens of different teleporters, terraforming tools, etc created by her on sale in the region QUANTUM as well as a selection of weapons too.

Most people have very strong opinions of Darling Brody. They either love her or hate her. This love/hate relationship seems to be closely linked to "who owns her weapons, and who gets owned by her weapons". Either way Darling Brody has never been punished for griefing, so her reputation as a grifer is probably just cleaver marketing ;)

While she is known to be very friendly and helpful to her customers and strangers alike, she is also known to be completely uncooperative when people are rude to her. Of course none of us would ever be silly enough to be rude to a weapons maker, right?

Darling Brody is well known by many Lindens as someone who helps to fix bugs and plug content theft methods. She is also active in the JIRA opposing changes that break content. She has often fought to have useful bugs retained as a feature, such as the longer avatar Link Distance when sitting on a prim, and retaining the JumpPos bug until the llSetRegionPos() function was completed.

Darling Brody has been a long time advocate of protecting content from theft. Ironical she has fallen victim to content theft several times, having her scripts used as the base to create competing products. Most notably the Quantum Core v3 scripts were released full permissions, resulting in a number of copycat products hitting the market. Darling responded by tossing out the old Quantum Core v3 scripts and starting a new product line from scratch called QHUD which included script theft protection.

In 2009 darling Brody had a Real Life mental breakdown that left her homeless for several years. Her products were not updated as often in this time, however they stood the test of time and remained relevant despite the infrequent updates.

Today Darling is busy writing new updates and creating new products.

As Darling says "'''When life gets you down, orbit yourself.'''"

LSL Protocol/Teleport Helper Protocol

2013-11-19T21:03:26Z

Darling Brody:

'''Teleport Helper Protocol'''

A protocol that fixes the limitations in the llTeleportAgent* functions, avoids broken content, and blocks any possible abuse.

Useful for : Star Gates, Quantum Portals, Teleporter Platforms, Tours, etc...

The purpose of this protocol is to allow land owners to teleport visitors without the visitors needing to sit on objects.

The new Linden teleport functions are fantastic but they only work on the script's owner.

To make the new teleport functions useful they need to work on people who are visiting your land, while blocking any possibility for abuse.

The way to do this is to wear a script which will teleport you on request, while still asking you before doing so.

If enough people include this script into their HUDs, hair, shoes, etc the Linden teleport commands will become useful everywhere.

Details:-

This script will listen on channel 86400000 for the teleport command. (and other commands as the protocol is expanded)

command format "teleport[region_name~region_position~look_at_position]"
region_name : is the plain text name of the target region
region_position : is a vector for the local position in the region, <0-255, 0-255, 0-4096>
look_at_position : is a vector for the position the avatar should be turned to face, <0-255, 0-255, 0>.
eg: llRegionSayTo(AvatarUUID,86400000,"teleport[quantum~<128, 128, 500>~<0, 128, 0>]");

Note:

The ~ character is used as a field delimiter because it is not used by any variables, such as the comma in a vector, or the pipe in some chat commands.

Commands are a single word with their parameters enclosed in the [] brackets. Additional parameters may be added so long as they are added to the end of the existing parameters. eg: delete[object name] or teleport[quantum~<128, 128, 500>~<0, 128, 0>]]

llWhisper(), llSay(), llShout(), and llRegionSay() can all be used to deliver the teleport[] command to groups of people. While llRegionSayTo() is proffered for sending the command to one person only.

Features:-

Only works if the request comes from an object owned by the land owner. Group owned land requires group owned objects.
Limit of one teleport per minute to avoid spamming.
Permissions are dropped after use.
Only one teleport is offered, regardless of how many copies of the script is worn.

To Do:-

Make this page look nice with some formatting

Delete[object_name] Delete the script from the named object so people can remove duplicates they know they will never need. Must check that the owner send this command.

Expand this script to support any other protocols that are used in custom products, such as some star gates.

---------------

vector global_coordinates;
vector region_coordinates;
vector look_at;
integer Priority;
integer Active = TRUE; // Default is Active
key reqID;
default
{
on_rez(integer param)
{
llResetScript();
}
attach(key id)
{
if (id == NULL_KEY) llRegionSayTo(llGetOwner(),86400000,"1"); // on detach try to re-enable other scripts that may be inActive
}
state_entry()
{
llListen(86400000,"","",""); // used to receive teleport commands and set controller priority
Priority = (integer)((llFrand(10000)*10000)+2); // Pick a Priority
llRegionSayTo(llGetOwner(),86400000,(string)Priority); // share the Priority
}
listen(integer channel, string name, key id, string message)
{
if ((integer)message > 0) // Priority received
{
if ((integer)message > Priority) // compare my Priority with received one
{
Active = FALSE; // set inActive because I have a lower priority
return;
}
else
{
Active = TRUE; // set Active because I have a higher priority
llRegionSayTo(llGetOwner(),86400000,(string)Priority); // share my higher priority to set other script(s) inActive
return;
}
}

if ((llSubStringIndex(message,"teleport[") == 0) && (Active == TRUE)) // teleport command & Active Mode
{
if (llGetLandOwnerAt(llGetPos()) != llGetOwnerKey(id)) return; // must come from owner of land under avatar
list command = llParseString2List(message,["teleport[","~","]"],[]); // extract destination details
region_coordinates = (vector)llList2String(command,1); // save destination position
look_at = (vector)llList2String(command,2); // save look at position
reqID = llRequestSimulatorData(llList2String(command,0), DATA_SIM_POS); // request region position
return;
}
}

dataserver(key query_id, string data)
{
if (reqID != query_id) return; // filter out irralavant queries
global_coordinates = (vector)data; // save region position
llRequestPermissions(llGetOwner(), PERMISSION_TELEPORT); // request permission to teleport
// Active = FALSE; // Optional to avoid spamming additional permission requests when the last one wasn't answered
}

run_time_permissions(integer perm)
{
if (perm & PERMISSION_TELEPORT)
{
llUnSit(llGetOwner()); // sitting avatar will not teleport
llTeleportAgentGlobalCoords( llGetOwner(), global_coordinates, region_coordinates, look_at); // teleport
// avoid teleport spam by resetting after a pause
llSleep(60);
llResetScript();
}
}
}

LSL Protocol/Teleport Helper Protocol

2013-11-19T20:52:19Z

Darling Brody:

'''Teleport Helper Protocol'''

A protocol that fixes the limitations in the llTeleportAgent* functions, avoids broken content, and blocks any possible abuse.

Useful for : Star Gates, Quantum Portals, Teleporter Platforms, Tours, etc...

The purpose of this protocol is to allow land owners to teleport visitors without the visitors needing to sit on objects.

The new Linden teleport functions are fantastic but they only work on the script's owner.

To make the new teleport functions useful they need to work on people who are visiting your land, while blocking any possibility for abuse.

The way to do this is to wear a script which will teleport you on request, while still asking you before doing so.

If enough people include this script into their HUDs, hair, shoes, etc the Linden teleport commands will become useful everywhere.

Details:-

This script will listen on channel 86400000 for the teleport command. (and other commands as the protocol is expanded)

command format "teleport[region_name~region_position~look_at_position]"
region_name : is the plain text name of the target region
region_position : is a vector for the local position in the region, <0-255, 0-255, 0-4096>
look_at_position : is a vector for the position the avatar should be turned to face, <0-255, 0-255, 0>.
eg: llRegionSayTo(AvatarUUID,86400000,"teleport[quantum~<128, 128, 500>~<0, 128, 0>]");

Note:

The ~ character is used as a field delimiter because it is not used by any variables, such as the comma in a vector, or the pipe in some chat commands.

Commands are a single word with their parameters enclosed in the [] brackets. Additional parameters may be added so long as they are added to the end of the existing parameters. eg: delete[object name] or teleport[quantum~<128, 128, 500>~<0, 128, 0>]]

llWhisper(), llSay(), llShout(), and llRegionSay() can all be used to deliver the teleport[] command to groups of people. While llRegionSayTo() is proffered for sending the command to one person only.

Features:-

Only works if the request comes from an object owned by the land owner. Group owned land requires group owned objects.
Limit of one teleport per minute to avoid spamming.
Permissions are dropped after use.
Only one teleport is offered, regardless of how many copies of the script is worn.

To Do:-

Make this page look nice with some formatting

Delete[object_name] Delete the script from the named object so people can remove duplicates they know they will never need. Must check that the owner send this command.

Expand this script to support any other protocols that are used in custom products, such as some star gates.

---------------

vector global_coordinates;
vector region_coordinates;
vector look_at;

integer Priority;
integer Active = TRUE; // Default is Active

key reqID;

default
{
on_rez(integer param)
{
llResetScript();
}
attach(key id)
{
if (id == NULL_KEY) llRegionSayTo(llGetOwner(),86400000,"1"); // on detach try to re-enable other scripts that may be inActive
}
state_entry()
{
llListen(86400000,"","",""); // used to receive teleport commands and set controller priority
Priority = (integer)((llFrand(10000)*10000)+2); // Pick a Priority
llRegionSayTo(llGetOwner(),86400000,(string)Priority); // share the Priority
}
listen(integer channel, string name, key id, string message)
{
if ((integer)message > 0) // Priority received
{
if ((integer)message > Priority) // compare my Priority with received one
{
Active = FALSE; // set inActive because it has a lower priority
return;
}
else
{
Active = TRUE; // set Active because it has a higher priority
llRegionSayTo(llGetOwner(),86400000,(string)Priority); // share my higher priority to set other script(s) inActive
return;
}
}

if ((llSubStringIndex(message,"teleport[") == 0) && (Active == TRUE)) // teleport command & Active Mode
{
if (llGetLandOwnerAt(llGetPos()) != llGetOwnerKey(id)) return; // must come from owner of land under avatar
list command = llParseString2List(message,["teleport[","~","]"],[]); // extract destination details
region_coordinates = (vector)llList2String(command,1); // save destination position
look_at = (vector)llList2String(command,2); // save look at position
reqID = llRequestSimulatorData(llList2String(command,0), DATA_SIM_POS); // request region position
return;
}
}

dataserver(key query_id, string data)
{
if (reqID != query_id) return; // filter out irralavant queries
global_coordinates = (vector)data; // save region position
llRequestPermissions(llGetOwner(), PERMISSION_TELEPORT); // request permission to teleport
}

run_time_permissions(integer perm)
{
if (perm & PERMISSION_TELEPORT)
{
llUnSit(llGetOwner()); // sitting avatar will not teleport
llTeleportAgentGlobalCoords( llGetOwner(), global_coordinates, region_coordinates, look_at); // teleport
// avoid teleport spam by resetting after a pause
llSleep(60);
llResetScript();
}
}
}

LSL Protocol/Teleport Helper Protocol

2013-11-19T20:43:24Z

Darling Brody:

Teleport Helper Protocol

A protocol that fixes the limitations in the llTeleportAgent* functions, avoids broken content, and blocks any possible abuse.

Useful for : Star Gates, Quantum Portals, Teleporter Platforms, Tours, etc...

The purpose of this protocol is to allow land owners to teleport visitors without the visitors needing to sit on objects.

The new Linden teleport functions are fantastic but they only work on the script's owner.

To make the new teleport functions useful they need to work on people who are visiting your land, while blocking any possibility for abuse.

The way to do this is to wear a script which will teleport you on request, while still asking you before doing so.

If enough people include this script into their HUDs, hair, shoes, etc the Linden teleport commands will become useful everywhere.

Details:-

This script will listen on channel 86400000 for the teleport command. (and other commands as the protocol is expanded)

command format "teleport[region_name~region_position~look_at_position]"

region_name : is the plain text name of the target region

region_position : is a vector for the local position in the region, <0-255, 0-255, 0-4096>

look_at_position : is a vector for the position the avatar should be turned to face, <0-255, 0-255, 0>.

eg: llRegionSayTo(AvatarUUID,86400000,"teleport[quantum~<128, 128, 500>~<0, 128, 0>]");

Note:
The ~ character is used as a field delimiter because it is not used by any variables, such as the comma in a vector, or the pipe in some chat commands.
Commands are a single word with their parameters enclosed in the [] brackets. Additional parameters may be added so long as they are added to the end of the existing parameters. eg: delete[object name] or teleport[quantum~<128, 128, 500>~<0, 128, 0>]]
llWhisper(), llSay(), llShout(), and llRegionSay() can all be used to deliver the teleport[] command to groups of people. While llRegionSayTo() is proffered for sending the command to one person only.

Features:-

Only works if the request comes from an object owned by the land owner. Group owned land requires group owned objects.
Limit of one teleport per minute to avoid spamming.
Permissions are dropped after use.
Only one teleport is offered, regardless of how many copies of the script is worn.

To Do:-

Make this page look nice with some formatting

Delete[object_name] - Delete the script from the named object so people can remove duplicates they know they will never need.
- Must check that the owner send this command

Expand this script to support any other protocols that are used in custom products, such as some star gates.

---------------

vector global_coordinates;
vector region_coordinates;
vector look_at;

integer Priority;
integer Active = TRUE; // Default is Active

key reqID;

default
{
on_rez(integer param)
{
llResetScript();
}

attach(key id)
{
if (id == NULL_KEY) llRegionSayTo(llGetOwner(),86400000,"1"); // on detach try to re-enable other scripts that may be inActive
}

state_entry()
{
llListen(86400000,"","",""); // used to receive teleport commands and set controller priority
Priority = (integer)((llFrand(10000)*10000)+2); // Pick a Priority
llRegionSayTo(llGetOwner(),86400000,(string)Priority); // share the Priority
}

listen(integer channel, string name, key id, string message)
{
if ((integer)message > 0) // Priority received
{
if ((integer)message > Priority) // compare my Priority with received one
{
Active = FALSE; // set inActive because it has a lower priority
return;
}
else
{
Active = TRUE; // set Active because it has a higher priority
llRegionSayTo(llGetOwner(),86400000,(string)Priority); // share my higher priority to set other script(s) inActive
return;
}
}

if ((llSubStringIndex(message,"teleport[") == 0) && (Active == TRUE)) // teleport command & Active Mode
{
if (llGetLandOwnerAt(llGetPos()) != llGetOwnerKey(id)) return; // must come from owner of land under avatar
list command = llParseString2List(message,["teleport[","~","]"],[]); // extract destination details
region_coordinates = (vector)llList2String(command,1); // save destination position
look_at = (vector)llList2String(command,2); // save look at position
reqID = llRequestSimulatorData(llList2String(command,0), DATA_SIM_POS); // request region position
return;
}
}

dataserver(key query_id, string data)
{
if (reqID != query_id) return; // filter out irralavant queries
global_coordinates = (vector)data; // save region position
llRequestPermissions(llGetOwner(), PERMISSION_TELEPORT); // request permission to teleport
}

run_time_permissions(integer perm)
{
if (perm & PERMISSION_TELEPORT)
{
llUnSit(llGetOwner()); // sitting avatar will not teleport
llTeleportAgentGlobalCoords( llGetOwner(), global_coordinates, region_coordinates, look_at); // teleport
// avoid teleport spam by resetting after a pause
llSleep(60);
llResetScript();
}
}
}

LSL Protocol/Teleport Helper Protocol

2013-11-19T20:20:58Z

Darling Brody: Created page with "Teleport Helper Protocol A protocol that fixes the limitations in the llTeleportAgent* functions, avoids broken content, and blocks any possible abuse."

Teleport Helper Protocol

A protocol that fixes the limitations in the llTeleportAgent* functions, avoids broken content, and blocks any possible abuse.

LSL Protocol

2013-11-19T20:16:49Z

Darling Brody: /* Protocol list */

{{LSL Header|ml=*}}
{{RightToc}}
==Script protocols and known chat channels==

<div id="box">
<div style="padding: 0.5em 0.5em 1.5em">
Some times, scripts in Second Life send messages to one another to exchange information or coordinate behavior. The rules for that conversation are a ''protocol''. Being able to say "/1show" or "/1hug lee" are examples.

Such protocols use a common [[chat channel]]. The examples above use channel 1. They could just as easily have used any other number, but a user (and other objects) have to have some way to find the correct number.

Some protocols, such as combat systems, are quite complicated and could be better documented. This page can be used to help prevent conflicts and allow multiple programmers to coordinate the protocol definitions.

Protocols can also be note card systems and systems that use object names.
</div>
</div>

<div id="box">

== Protocol list ==
<div style="padding: 0.5em">
Add a protocol here if it is widely used, or might be sometime in the future.

A protocol in this list should also have its own pages where the protocol is defined in some detail.
</div>

{| class="sortable" {{Prettytable}}
|-
|{{Hl2}}| '''Name'''
|{{Hl2}}| '''Creator'''
|{{Hl2}}| '''Description'''
|-
|| [[LSL Protocol/Teleport_Helper_Protocol|Teleport Helper Protocol ]]
|| {{User|Darling Brody}}
|| Teleporter Helper Protocol.
|-
|| [[LSL Protocol/Cool_Hud_Protocol|Cool Hud]]
|| {{User|Henri Beauchamp}}
|| Universal Hud protocol.
|-
|| [[LSL Protocol/DataBot|DataBot]]
|| {{User|Siann Beck}}
|| A protocol for specifying custom avatar information.
|-
|| [[LSL Protocol/EasyTalk|EasyTalk]]
|| Salahzar Stenvaag
|| |Very Easy and simple communication protocol. Use it to simply coordinate llSay/llRegionSay/llListen objects, as well as linked set
|-
|| [[LSL Protocol/ListMessage|ListMessage]]
|| Anonymous
|| Send and receive lists, non-lists, non-results, verb-not-found, and partially evaluated Polish expressions.
|-
|| [[LSL Protocol/LockMeister System|LockMeister System]]
|| Kyrah Abattoir
|| Used to coordinate different parts of bondage toys.
|-
|| [[MLPV2|Multi Love Pose v2]]
|| [[User:Lear_Cale|Lear Cale]]
|| Pose Ball Rezzing and Menuing kit (see menu to the right of linked page for indepth spec/protocol)
|-
|| [[User:Nandana_Singh/nPose|nPose]]
|| Nandana Singh
|| Furniture Posing Menuing kit (does not use pose balls)
|-
|| [[LSL Protocol/Ganymedia OpenMAIP v1.0 Specification|OpenMAIP]]
|| Ganymede Ceriaptrix
|| ''Note: Specification is presently incomplete.'' Ganymedia OpenMAIP (Metaverse Application Internetworking Protocol) provides a TCP/IP-like routing and service-oriented message exchange protocol across multiple transport methods (including cross-simulator and cross-grid); allowing scripts to advertise their available functions, and relevant commands, to external and/or third-party scripts and viewers. Controlled access to closed functions is provided via RC4 challenge-response authentication. OpenMAIP also provides an optional RC4 cryptography layer, further extensible to public-private key DHSS.
|-
|| [[LSL Protocol/P Vendor Linked Messages API & Environment|P Vendor Linked Messages API & Environment]]
|| Zep Palen
|| Allows an owner of the P Vendor system to develope custom vendors and use the API for input/output
|-
|| [[LSL Protocol/RestrainedLoveAPI|RestrainedLove viewer API]]
|| Marine Kelley
|| Use the features of the RestrainedLove viewer through llOwnerSay() calls.
|-
|| [[LSL Protocol/Restrained Love Relay Specs|RestrainedLove viewer relay spec]]
|| Marine Kelley
|| Allow your furniture or cages to issue commands to the user's RestrainedLove viewer
|-
|| [[LSL Protocol/Restrained Life Open Relay Group|RestrainedLove viewer open relay spec]]
|| Open Relay Group
|| A superset of the RestrainedLife viewer relay spec with useful extensions created and maintained by the community.
|-
|| [[User:Nexii_Malthus/Script_API|Script API]]
|| [[User:Nexii_Malthus|Nexii Malthus]]
|| A protocol to provide a useful communication layer between LSL scripts and supported clients, as well as a useful and purposeful feature set. (Vertical Life and Plywood clients currently)
|-
|| [[Teacup|Teacup (LSL HTTP Server)]]
|| [[User:Void_Singer|Void Singer]]
|| An LSL Web Page Server for serving HTML content solely from within SL using shared media (Spec, protocols, linked examples)
|}
----

==Known chat channels==
This list is intended to reduce the number of scripts using the same chat channel number.
Please try and keep them in sequence. Note that the absence of a channel reservation in this list does not mean that channel will never be used - some scripts choose channels randomly from a very, very large range, sometimes a range of all possible channels. ''Always'' design your communication protocols such that invalid/interfering messages are disposed of.
{| {{Prettytable}}
|-
|{{Hl2}}| '''Channel'''
|{{Hl2}}| '''Creator'''
|{{Hl2}}| '''Description'''
|{{Hl2}}| '''Messages'''
|-
|| 1, 4, 5, 9
|| Unknown
|| Very common in poseballs
|| "hide", "show"
|-
|| 3
|| katie.paine
|| rf gag - also used by Darie's gag scripts
|-
|| 4
|| {{User|Mo Noel}}
|| (Depreciated: Default channel for chat redirection like in gags or other voice manipulating tools)
|-
|| 5
|| Psistorm Ikura
|| PsiCorp Products
|-
|| 6
|| grumble Loudon
|| pre-appended text and say it.
|| "/6 hello" becomes "/me Lion says: hello"
|-
|| 8
|| {{User|Henri Beauchamp}}
|| Cool Collar command channel
|-
|| 8
|| unknown
|| Lulu cuffs / gags ..
|-
|| 9
|| DCS And Most Modern SLRPG Frame Works
|| Command channel for user commands for Combat Systems/ SLRPG Frameworks like DCS
|| /9on /9 reset /9<power> etc
|-
|| 10
|| [[ACE BnT]]/[[IntLibber Brautigan]]
|| Ancapistan Capital Exchange ATM user interface channel
|| "balance","withdraw","help"
|-
|| 10, 11, 12
|| Bettie Binder
|| doll life renamer
|-
|| 11
|| Racheal Young
|| Default channel of chat commands for Barre & Rachael Rockers Products
|-
|| 11
|| {{User|Mo Noel}}
|| Default channel of chat command interface of MoDesign products
|-
|| 12
|| Unknown
|| title and status of damage meter (combat system)
|-
|| 13
|| Daisy Rimbaud
|| evil titler
|-
|| 14
|| {{User|Mo Noel}}
|| Default channel for chat redirection like in gags or other voice manipulating tools
|-
|| 15
|| {{User|Mo Noel}}
|| Default channel for emote redirection like in gags or other voice manipulating tools
|-
|| 17
|| Susan Daviau
|| Susan's relay
|-
|| 19
|| Cloe
|| DEM rename
|-
|| 20
|| Unknown
|| SafeZone interface (combat system)
|-
|| 20
|| Bettie Binder
|| doll life dollyteer
|-
|| 21
|| Bettie Binder
|| doll life
|-
|| 22
|| {{User|Henri Beauchamp}}
|| Cool Cuffs command channel
|-
|| 22
|| {{User|unknown}}
|| OOC Textiness. Says what you type.
|-
|| 22
|| {{User|Corvan Nansen}}
|| Chat Enhancer. Out Of Character speech.
|-
|| 26
|| {{User|Agnes Paine}}
|| Command channel for restraints
|-
|| 33
|| {{User|Henri Beauchamp}}
|| Cool Nipples command channel
|-
|| 33
|| unknown
|| Collar
|-
|| 35
|| {{User|Corvan Nansen}}
|| Chat Enhancer Command channel.
|-
|| 36
|| {{User|Corvan Nansen}}
|| Ultimate Titler Command channel.
|-
|| 42
|| unknown
|| Common channel used by wiki example scripts
|-
|| 42, 55, 66, 77
|| Psistorm Ikura
|| Aventity avatar scripts
|-
|| 44
|| {{User|Corvan Nansen}}
|| Chat Enhancer. In Character speech.
|-
|| 45, 54
|| Ilobmirt Tenk
|| FOSSL Vending System Client/Server default command channel
|-
|| 55
|| {{User|Henri Beauchamp}}
|| Cool Chastity Belt command channel
|-
|| 63
|| {{User|FlipperPA Peregrine}}
|| FlipTitle and "Flip mod" Franimation commands
|-
|| 66
|| Travis Lambert
|| BanLink default chat command channel
|-
|| 66
|| {{User|Henri Beauchamp}}
|| Cool Diaper command channel
|-
|| 66
|| {{User|Corvan Nansen}}
|| Chat Enhancer. In Character emotes.
|-
|| 69
|| {{User|Henri Beauchamp}}
|| Cool Penis & Cool Pussy command channel
|-
|| 77
|| {{User|Marine Kelley}}
|| Real Restraints and similar BDSM equipment
|-
|| 77
|| Xarrk Dagger
|| KAIIA Systems devices default chat command channel
|-
|| 77
|| Mars Tamale
|| Mars Ring
|-
|| 88
|| Cadroe Murphy
|| Used by ShapeGen and other building tools
|-
|| 88
|| {{User|Corvan Nansen}}
|| Chat Enhancer. Narration channel.
|-
|| 88
|| {{User|Sharie Criss}}
|| Owners plugin for Marine Kelley's Real Restraint equipment. Chat command channel.
|-
|| 99
|| unknown
|| Dance Bracelets
|-
|| 100
|| {{User|Mo Noel}}
|| Channel used to ask the user for chat line entries from within usual dialog sessions
|-
|| 100-999 (Randomly chosen periodically)
|| {{User|Corvan Nansen}}
|| Ultimate Titler. Title setting channel.
|-
|| 777
|| Hank Ramos
|| [[Universal Translator]]: channel to allow users to open a dialog-box using a chat command on channel #777. Only accepted command on this channel is "translator" and all other chat is ignored. Allows user to silently bring up dialog by hiding command as "/777 translator".
|-
|| 888
|| Xarrk Dagger
|| KAIIA Systems device identification channel
|-
|| 2776
|| Tdub Dowler, Riden Blaisdale
|| Used for transmitting a csv list of keys for use in sim wide radars
|-
|| 4123 - 4130
|| {{User|Lastro Greenwood}}
|| Used by the Life Support System
|-
|| 9001, 908070
|| Mystical Cookie
|| MystiTool gesture commands, patch installers
|-
||10748, -10748
|| Lee Ponzu
|| Commonly used in scripts by Ponzu
|-
|| 31984
|| {{User|Coraa Prior}}
|| ACME interface (combat system)
|-
|}

==Known negative chat channels==
{| {{Prettytable}}
|-
|{{Hl2}}| '''Channel'''
|{{Hl2}}| '''Creator'''
|{{Hl2}}| '''Description'''
|{{Hl2}}| '''Messages'''
|-
|| -666
|| {{User|Dimentox Travanti}}
|| [[DCS]]: Unit to Hud Status Update Channel
|-
||-786
||{{User|Sly}}
||Sly's Modified Gear Communications Channel
|-
||-8888
||{{User|Kyrah Abattoir}}
||LockMeister Communications Channel
|-
||-9119
||Lillani Lowell
||LockGuard Communications Channel
|-
|| -10xxx
|| {{User|Ayelin Ethaniel}}
|| Communication channel of ::Wild Pets:: systems. Commonly generated automatically between -10000 -10999.
|-
||-30000,-30001
||{{User|Corvan Nansen}}
||Update station broadcast and coordination channels
|-
||-248177
||{{User|Corvan Nansen}}
||Bane Custodian communications. Used by the Custodian to communicate with the Bane Hood.
|-
||-426956
||{{User|Ganymede Ceriaptrix}}
|| Ganymedia Open Metaverse Application Internetworking Protocol (OpenMAIP): Broadcast Communications Channel (<code>MAIP_BROADCAST</code>). Used for public OpenMAIP service discovery queries. Region-wide. See the [[LSL Protocol/Ganymedia OpenMAIP v1.0 Specification|Ganymedia OpenMAIP v1.0 Specification]] for further information.
|-
||-504xxx
||Gal Canning
||only whispered inter-prim communication
|-
||-888888
||{{User|Henri Beauchamp}}
||Cool Hud communications channel
|-
||-1xxxxxx
||{{User|Corvan Nansen}}
||Update management channel for coordination between items to be updated and an update orb. Randomly chosen and temporary.
|-
||-2766532
||Hank Ramos
||[[Universal Translator]]: "back-channel" for inter-translator communications. This is an encrypted channel that passes translation and command-control messages between translators that are linked together to spread the translation load and HTTP communications.
|-
||-828983023
||{{User|Very Keynes}}
||VK-NET Public Channel for Inter Network Communication and Local Network Address Acquisition.
|-
||-1812221819
||{{User|Marine Kelley}}
||RestrainedLove relay communications channel
|-
||-1192zzzxxx
||{{User|Asbrandt Resident}}
||Internal Comms range for all projects : Z = Integer Project ID - Use of X range varies : All Comms are Headered with the Project ID : Some further info on User Page.
|-
|}

Aditi/ThouMustNotFail

2010-02-26T05:22:44Z

Darling Brody:

= Thou Must Not Fail =
== Synopsis ==
This is a list of the most critical resident created objects used in Second Life that need to always work.

== The Reasoning ==
Second Life is very complex. There are an infinite number of ways to do things in Second Life. These methods may be right or wrong. These methods may exploit bugs or logic holes. While testing upcoming server releases it just isn't possible to test everything resident created. QA will test changed features and make sure they work as expected. Oftentimes there are edge cases that fail without QA's knowledge. This list is a list of really important items that should always work. We will test these objects early on in the QA process and use it as a sort of canary in the coal mine test.

= Vendors =
* Hippo technologies products (hippo rent and hippo vend)
* XStreet SL Server Objects
* Metalife related vendors and servers objects.
* Quantum Products Vending and Rack Servers

= Land Management Tools =
* objects which ban/kick users
* automated parcel rental systems

= Physics =
* Posjump things
* Flight Feathers
* WarpPos. https://wiki.secondlife.com/wiki/WarpPos
* Dynamic avatar sit target. (llSetLinkPrimitiveParams(llGetNumberOfPrims(), [PRIM_POSITION, <50, 0,0>]);)
* Regular 300m sit target. llSitTarget(<300,300,300>,ZERO_ROTATION);

= Web =
* Transaction History Page (used by vendors to validate payments)

= Viewer =
* Alpha on HUDs to render the same as in world (broken by 1.23 VWR-13151)
* Content to render the same between viewer versions. eg: 1.x and 2.0

= DEBUG =
* Debug Channel number and data sent to remain consistant (used for auto script repair)

LlSetLinkPrimitiveParams

2008-11-27T12:24:25Z

Darling Brody:

{{LSL Function/link|linknumber}}{{LSL Function
|func_id=328|func_sleep=0.2|func_energy=10.0
|func=llSetLinkPrimitiveParams|sort=SetLinkPrimitiveParams
|p1_type=integer|p1_name=linknumber
|p2_type=list|p2_name=rules
|func_desc=Set primitive parameters for '''linknumber''' based on '''rules'''.
|spec
|caveats=*Applying an operation to [[LINK_SET]] is applied first to the root prim, then to each child prim.
*The sim will clamp attributes before storing them.
*The client will clamp attributes before rendering.
*There is currently no corresponding [[llGetLinkPrimitiveParams]].
**The only way to get many parameters from linked prims is to put a separate script in each child and use [[llMessageLinked|linked messages]].
|constants={{LSL Constants/PrimitiveParams|set|remote=true}}
|examples =
A simple script to light up a prim in a [[linkset]] when touched, and unlight the others using llSetLinkPrimitiveParams, when script is installed in the root prim of the linkset.
<lsl>
default
{
touch_start(integer total_number)
{
// Turn off all prims
llSetLinkPrimitiveParams(LINK_SET,[PRIM_FULLBRIGHT,ALL_SIDES,FALSE]);
// Turn on the one that was touched
llSetLinkPrimitiveParams(llDetectedLinkNumber(0),[PRIM_FULLBRIGHT,ALL_SIDES,TRUE]);
}
}
</lsl>
|helpers
|also_functions=
{{LSL DefineRow||[[llSetPrimitiveParams]]|Set many primitive parameters}}
{{LSL DefineRow||[[llGetPrimitiveParams]]|Get many primitive parameters}}
{{LSL DefineRow||[[llSetLinkAlpha]]|}}
{{LSL DefineRow||[[llSetLinkColor]]|}}
{{LSL DefineRow||[[llSetLinkTexture]]|}}
|also_tests
|also_events
|also_articles
|notes=
Note that avatars sitting on the object can be moved with this function as well. See [[llSitTarget#Useful_Snippets]] for an example of this.

The Mis-feature of using this function to move avatars 54 meters is now officialy supported according to Andrew Linden (see jira Link http://jira.secondlife.com/browse/SVC-3408?focusedCommentId=88574#action_88574 )

The below example moves avatar to x,y,z without moving the prim they are sitting on. If x,y,z is more than 54 meters away the function will silently fail. Remember x,y,z is in object ralative coordinates just like any other linked prim in a set.

Agents are always the last prim in the set, so using llGetNumberOfPrims() for a single agent sitting on a vehicle is usefull.

Example Code : llSetLinkPrimitiveParams(llGetNumberOfPrims(), [PRIM_POSITION, <x,y,z>]);

Darling Brody (27/11/2008)

|cat1=Prim
|cat2=Movement
|cat3=Status
|cat4=Texture
|cat5=Object
|cat6=Teleport
|cat7=Link/Set
|cat8
}}

Name2Key in LSL

2008-09-05T03:14:01Z

Darling Brody:

{{LSL Header}}

Still missing Name2Key functions in your code ? Still relying on external databases that are not always up to date with latests SL subscribers ?

Well now you can solve this by yourself, within your LSL script ! All you have to do is to rely on LL Search engine !

I put a kind of "library" and a sample of usage for your convenience

Library:
<lsl>
integer SERVICE_NAME2KEY = 19790;
integer SERVICE_NAME2KEY_RET=19791;
key ONE_KEY = "FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF";

integer gCurrentRequest=0;
key gReqId=NULL_KEY;
string gToSearch="";

ReturnService(integer Status, string message)
{
key Key;

if (Status)
Key=ONE_KEY;
else
Key=NULL_KEY;

llMessageLinked(LINK_THIS, gCurrentRequest+1, message, Key);

gCurrentRequest=0;
gReqId=NULL_KEY;
gToSearch="";
}

SvcName2Key(string message)
{
if (gCurrentRequest) {
ReturnService(FALSE, "BUSY");
}

gCurrentRequest=SERVICE_NAME2KEY;
string url="http://secondlife.com/app/search/search?s=Resident&q="+llEscapeURL(message);
gToSearch="secondlife:///app/agent/";

gReqId=llHTTPRequest(url, [HTTP_METHOD,"GET"], "");
}

default
{
link_message(integer sender_number, integer number, string message, key id)
{
if (number==SERVICE_NAME2KEY) {
SvcName2Key(message);
}
}

http_response(key request_id, integer status, list metadata, string body)
{
if (request_id==gReqId) {
integer Pos1=llSubStringIndex(body, gToSearch);
integer Pos2=0;
string Ret="";
if (Pos1!=-1) {
body=llGetSubString(body, Pos1+llStringLength(gToSearch), -1);
if (gCurrentRequest==SERVICE_NAME2KEY) {
Pos2=llStringLength((string)NULL_KEY);
string Dat=llGetSubString(body, 0, Pos2-1);
if (llStringLength((string)((key)Dat))==llStringLength(NULL_KEY)) {
// Success !
Ret=llGetSubString(body, 0, Pos2-1);
ReturnService(TRUE, Ret);
}
else
ReturnService(FALSE, "UNKNOWN");
}
else
ReturnService(FALSE, "UNKNOWN SERVICE");
}
else
ReturnService(FALSE, "UNKNOWN");
}

}
}
</lsl>

Usage sample:
<lsl>
integer SERVICE_NAME2KEY = 19790;
integer SERVICE_NAME2KEY_RET=19791;
key ONE_KEY = "FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF";

MyName2Key(string message)
{
llMessageLinked(LINK_THIS, SERVICE_NAME2KEY, message, NULL_KEY);
}

default
{
touch_start(integer total_number)
{
llOwnerSay("Searching key for avatar named Secret2 Linden");
MyName2Key("Secret2 Linden");
}

link_message(integer sender_number, integer number, string message, key id)
{
if (number==SERVICE_NAME2KEY_RET)
{
if (id==ONE_KEY)
llOwnerSay("Found ! Key is: "+message);
else
llOwnerSay("Error: "+message);
}
}
}
</lsl>

Hope this helps !
[[User:Maeva Anatine|Maeva Anatine]]

EDIT : Looks like the Lindens have either broken or blocked this function. It works from my browser, however from LSL I get an error page containing this message "Access control configuration prevents your request from
being allowed at this time. Please contact your service provider if
you feel this is incorrect." - Darling Brody.

{{LSLC|Library}}

User:Jana Kamachi/Detect

2008-03-22T11:13:30Z

Darling Brody:

{{Jana}}
<pre>
list dtc = [];
list darl = [];

integer darl_d = FALSE;
integer cnt = 0;

vector lastpos;
vector curpos;

default
{
state_entry()
{
llSensorRepeat("", "", SCRIPTED, 1.0, PI, 0.001);
llSetTimerEvent(0.001);
lastpos = llGetPos();
}

sensor(integer n_m){
integer i=0;
dtc = [];
if(n_m > 2) n_m = 2;//no need for a jump;
for(; i<n_m; ++i) {
dtc += (llDetectedName(1) + " owned by " + llKey2Name(llDetectedOwner(1)));
}
}

timer(){
if(llVecDist(lastpos, curpos = llGetPos()) > 1000){
llOwnerSay("Orbit Detect.");
llOwnerSay("Possible Orbiters\n" + llDumpList2String(dtc,"\n"));
cnt = 0;
lastpos = curpos;
}else if(500 < ++cnt){//will force update lastpos about every 25 to 50 seconds.
cnt = 0;
lastpos = curpos;
}
}
}
</pre>