Allow llDialog() to have a typed response

I've repeatedly wanted to have an easy way for a user to type a response to an option other than clicking a predefined name. I also think llDialog() is the best place to add this ability without causing massive changes as it would require a fairly trivial implimentation change.

Currently the arguments for a dialog include a list variable to contain the predefined names of all options. My suggestions is that if an empty list is passed as the argument, instead of popping up buttons it will pop open a text field for the user to type their desired reply in plain text before clicking a 'send' button.

Of course the ignore button still needs to remain in the interface for users who dont wish to reply. And this is fine. As far as the server is concerned the implimentation is still the same. The typed response is spoken by the avatar at the same origin point as a regular dialog call on the predetermined channel. This is exactly how dialogs work now only currently the spoken response must match a predefined button label.

This would allow people who need complex responses to get them with a more intuitive interface than requiring the user to type some arbitrary channel number and their reply into a very non intelligent chat box. And effecient script writers could use the same methods for auto closing out the dialog listeners on a temporary timer or on reply to help reduce server load with methods they already understand.

From a developement standpoint the only change needed is identifying a null list (already done now to register an error), and then sending a 2nd dialog box message to the client to display the alternate text box.

Please comment and cast your votes:

http://secondlife.com/vote/index.php?get_id=1385

or how about adding a constant variable like USER_DEFINED that can be stuck into a dialog option list so you can mix and match buttons and user defined text fields in the same dialog pop-up, kinda like the pay option pop-up with quick pay buttons and a value field. just a thought. =)

I was about to raise a proposal for the same thing. The changes to llDialog would be trivial, and should not break existing scripts. I'm not sure though about the effect on the GUI - this may or may not be significant.

My thought was that the text input box should be an additional line in the dialog box, and also have the possibility of being partially of fully prefilled. I'd happily lose a row of buttons, but any method of text input is better than directing the user to the command line with an obscure channel number, and a command string to type before getting to the required data.

Anyone who uses llDialog should vote for this, and I suspect a lot of people don't use llDialog precisely because of the input limitations.

I'd like to have a sensible return code for llDialog() instead of stupidly returning the button name. You have to come up with the weirdest button names to distinguish between different dialog responses right now.

Why not have someting like this:

RPL_OPTION1=0;
RPL_OPTION2=1;
RPL_OPTION3=2;
RPL_OPTION4=3;
RPL_OPTION5=4;

dialog button list:
["Option 1",RPL_OPTION0,
"Option 2",RPL_OPTION1,
"Option 3",RPL_OPTION2,
"Option 4",RPL_OPTION3,
"Option 5",RPL_OPTION4]

So we can define our own return codes for different button sets to have the same button text return another number if used in another dialog.

Zi thats actually my 'dream' dialog service along with more. Mostly i just wanted to offer a quick 'server side' fix with minimal client and backend redesign to open up a LOT more functiosn

Your proposal along with prefilled text would be great as a llDialogAdv() function.

/me continues dreaming

Until LL get this working... it's an option to just have one button marked "text reply" or something and get it to listen on whatever channel you like (same one as the dialogue maybe) for the next 15 seconds or so...

It's messy, but it would work.

bump

Except losing a row of buttons could break existing scripts with more than 9 elements in the list llDialog uses.

But yes, text entry could be hot.

rather than break existing scripts using llDialog, how about this?

llDialogExtended(
  llDetectedKey(0),
  "Message goes here",
  [
    DIALOG_SEPARATOR," ", // Use a space to separate multiple items (default)
    DIALOG_BUTTON,"Button1",
    DIALOG_BUTTON,"Button2",
    DIALOG_TEXT,last_entry // (pre-filled-in default value)
  ],123456);

This would be the equivalent of llSay(123456,button+" "+text);

If you have multiple text inputs, they would be separated by a space or by DIALOG_SEPARATOR in the response. Since it uses a different call, it won't break existing scripts.

Err, no, you don't have to. Use extra variable to memorize 'page' of your menu last shown in the dialog, then on listen act accordingly sorting through page->button if-else structure... ^^;

So what if two users are using your script at the same time, calling different pages? I think, all this "workarounds" would not be necessary in the first place if llDialog() would allow us to specify our custom return codes.

As for losing a row of buttons: This would only be the case if we request a typed response, so all other dialogs would still work as expected. Nothing lost, only gains.

New Proposal: http://secondlife.com/vote/get_feature.php?get_id=1887

You should still make it a new call to avoid breaking existing scripts. But I do like the idea of having the name of the button different from the text...

llDialogExtended(
  llDetectedKey(0),
  "Message goes here",
  [
    DIALOG_BUTTON,"Button1","Text1",
    DIALOG_BUTTON,"Button2","Text2",
    DIALOG_TEXT,"Text1",last_entry // (pre-filled-in default value)
  ],123456);

The response still is going to come back as a string... there's no reason to restrict it to an integer. Having a string would make it easier to parse, for example you could do this:

list dialog = [
  DIALOG_BUTTON,"%%kick%%","Kick",
  DIALOG_BUTTON,"%%hug%%","Hug",
  DIALOG_TEXT,"%%target%%",last_victim_name
];
llDialogExtended(llDetectedKey(0),"Enter the avatar name and action",dialog,123456);
//...
listen(integer channel,string name,key id,string text)
{
  if(channel == 123456) 
  {
    list l = llParseString2List(text, [ "%%" ],[]);
    integer target_index = llListFindList(l, ["target"]);
    if(target_index != -1)
    {
      last_victim_name = llList2String(l, target_index + 1);
      if(llListFindList(l,["hug"]) != -1) hug_action(last_victim_name);      
      else if(llListFindList(l,["kick"]) != -1) kick_action(last_victim_name);
    }
  }
}

Then you have multi-threading situation which is a big enough can of worm on its own... but for this particular use you can replace the single 'menu page' variable with a (strided) list in form <av key><menu page>..) and then figure out the correct page through list scan for id field provided when listen() is triggered. Which is (variable instancing) what you'd need to do with most of code that supports multiple users at the same time anyway.


It'd be indeed nice, i just don't find in extremely urgent thing to have. To be honest, i'd be much eager to get dialog box that can actually display the 20+ characters per button it's supposed to support, for starters ^^;;;

But that said, the idea of extended llDialog with text entry field is very nice, and if it can provide what you ask for, like in most recent Argent's post, then all the better.

Now I see this post.
Here is mine..
/13/2d/134671/1.html
it is prtty much the same thing but a new function all together.

llDialogEntry(key id, string message, list buttons, integer entry,integer chat_channel)
entry would be TRUE or FALSE. if the dialog entry is shown or not.

Where it would show or not show the Entry line sort of like the llSetPayPrice dialog window,

You mean bool entry. Integers aren't true/false values, and while LSL lacks a true boolean variable, LSL fucntions still use them.

There is no need to break any existing llDialog scripts. an easy way to achieve this is to use the buttons list which currently allows string entries only.
Add an the option of an integer entry to define the chat channel for text input (which could be the same as the button channel), followed by an additional string entry defining any pre loaded text. e.g.

llDialog(AV_key, "Text Message",[ "FORWARD", "BACKWARD", "UP", "DOWN", 12, "replace this text"], 13);

The presence of the integer in the list, with a non zero value, would indicate that a text input field was needed. No integer entry (which is illegal in current scripts), no change. The above line would produce a dialog box with 4 buttons and a text entry field preloaded with "replace this text", chatting the button content on channel 13, and the text input content on channel 12.

As to giving buttons different names to the text they contain, there is an easy workaround.
Just set all the button text to 24 characters, and use the last 4 for the button name:

[ "BUTTON1 0301","BUTTON2 0302","BUTTON1 0303".... etc.

I use the first 2 digits for the menu number, and the second 2 for the button number.

then

if (llGetSubString(listen_msg, 20,21) == "03"
{
// processing button input from menu 3
if(llGetSubString(listen_msg, 22,23) == "01"
{
//button 1, menu 3


I certainly have no objections to the introduction of llDialogX though, anything to get simple text input, but I do think the buttons and text input should be on the same dialog menu.

As I said in a previous post, I think the changes to the script fuction are almost trivial, the difficultly could well be the changes to the client to respond to the box and capture any text typed in there. This is an area I know nothing about.

Going off on a tangent, I was wondering about forcing text into the standard chat entry box
allowing the user to change it or append to it. cruder, but it would achieve the same objective.

I was looking troug votes for once and somehow happned to stumble on this thread.
I would just like to say that there is a way to work around this and indeed using the same name on a button in several or more different dialogs.

Simplified: Send different dialog pages on different channels. (say blue red white on channel 12345 .. and the same on channel 67890 but for a different part of your script, the listener gives you what channel it heard something on.)

Advanced: Create your own dialog handler script that takes linkmessage input and sends it to a user, swiching channel each time you send a new dialog (and closing listeners as dialogs time out). Keeping track of the info and buttons you sent it, different channels aswell as keeping the key of who you send the dialog to (and all other info you wish) will make sure you can mach the response as so its comming from the same person you sent the dialog. (I have sucessfully made this, it keeps track of a variable i give it and returns it with the button response of the user. Not willing to share it tho, but give me a nudge inworld, i might be willing to share some pointers or aid you if i have a moment