llDialog()... Please Fix It

llDialog()... one of the newest functions added into LSL.

I just found a superb use for it, UI! (arent I completely obtuse )

However, Ive run into a few roadblocks and annoyances.

One:

Stuffing all that data thats needed to process the dialog into a listen() event is NOT PRETTY. At all. Period.

I'd rather have a:

dialog_responce(integer dialogId, string buttonChoice) event

and:

integer llDialog();

dialogId being the integer returned from llDialog() and buttonChoice being the text of the button the user pressed. Both of these can be implimented without any disturbance to the scripts that use the current llDialog(), as returning an integer, and returning void can be used with the same syntax.

Two:

More Buttons!!!
Having only 4 buttons is completely absurd. I think there should be a ratio of text to buttons; if you have less then n number of characters in your llDialog() text, your allowed m number more buttons.

EDIT: I just recently figured out a way to auto-track a person's position in a dialog. I believe if the last feature I mention in this post was implemented (llCloseDialog), then a "more..." button solution would be completely possible.

Three:

Newline support!
I filed this as a bug: dialogs dont allow you to specify new lines in their text.

Four:

Another pet peeve... Why do the dialogs default to the ignore button when their background is clicked! . This one really pisses me off, since we already have an ignore button.

And finally...
------------------------
EDIT: I no longer want this:

Get rid of the ignore button!!!
It throws too many of my scripts off, or allow us to know if a dialog is still open or not, so we dont open the same dialog over another one (and confuse the hell out of our scripts and users).

Another useful function that can arise from having this functionality, and the functionality mentioned in #1 added:

integer llDialogOpen(integer dialogId);

returns TRUE if dialog with dialogId is still open.
------------------------
EDIT: I do want this though:

llCloseDialog(integer dialogId);

Hehe, self explanatory

EDIT: Added an explanation
What this function does is close the dialog specified by dialogId, if its open, if its already closed, it does nothing.

Implimenting llCloseDialog would eliminate alot of confusion and loopholes my scripts need to go through to make sure the user didnt make a mistake. Take this situation:

John Doe is setting up his elevator, the setup dialog is open, and he gets an IM from Jane user and talks to her for more then 5 minutes, leaving the dialog idle.

Without this function, the script auto-timesout the dialog, and reopens it on John's screen, confusing John, when he comes back from IM, seeing two copies of the same dialog... what to do?

With llCloseDialog() I can make sure the dialog is close before issuing a new one. Implementing llCloseDialog would not undermine security, at least IMO.

-----

Whew. That was long. Sorry about that

Now! Who's with me!

==Chris

EDIT:
Added llCloseDialog().

EDIT2: Major Edit, changed around a few suggestions.

I second this.

However the integer llDialog confuses me. How, I dunno, but it does somehow, lol.

The ignore button serves a good purpose, but it would nice if something was returned to the script to let us know that ignore was pressed, but that would of course defeat the purpose of Ignore kinda.

Would be nice of course to have radio buttons/check boxes/input boxes and more on the dialogs also, not sure how that would be done.

The placement of the buttons when you have up to four is a bit odd also. But livable with.

I agree with anything else you said that I didn't critique here.

I was thinking of something along the lines of what llListen() does. It returns an integer so you can control it with llListenControl() and remove it with llListenRemove().

With the syntax, I meant that

llListen(0,"","","";

is equivelant to:

integer foo = llListen(0,"","","";

You dont have to store the value returned from llListen. I wanted the pattern to remain the same with llDialog(), since everyone using llDialog uses it without thinking it has a return value.

Ah I see what you mean now, yeah that'd be good to have too.

It's possible to write a script that has a 'more...' button and keeps track of agents, values, and current positions within the values using lists. I made a script that did this just today, actually.

The problem with that, in my script, is that I only have a limited amount of space to write these values in. Its not really designed around list manipulation. Adding list manipulation functionality would clutter it more and I cant afford reaching the stack-heap limits (Its the Setup UI module in a project with many modules, Id like it to stay in only one module).

I also want to avoid using a more... button when I need to fit only one more button into the window, it makes little sence.

One
I'm not sure how your number one will help. What are you having to stuff in the listen? The 4 ifs? You will still need that. A check of who is responding? Still need that (just now with the dialog id that you have to keep track of). I dunno, I'm not seeing the overall benefit.

Two
I agree there should be more buttons! 4 is kid of silly, seeing as 6 fits in the same number of lines.

Three
Most definatly! /n and /t support are needed!

Four
I thought they canceled if you pressed the center? But you are right, there is a cancel button, clicking on the dialog itself should do nothing

Five
<bbbzzzt> wrong answer. The first incarnation of lldialog had no ignor button! And it was abused in the first day of it being on the test server!! So someone puts down a box at an event that does some sensor and sends a dialog to everyone at the party, the choices are "I am an idiot" and worse. Clicking on one says your choice, as though it was from you, on the 0 channel. Yay fun. And no way to not say it. Basically we don't want to be forced to say stuff.

I like the idea of letting the script know when it is canceled. Maybe if a listen event can be triggered with a null string message? Otherwise I'm not really sure how it would work.

Number 6 (my addition!)

Add a type field. DIALOG_BUTTON, DIALOG_RADIO, DIALOG_DROPDOWN, DIALOG_TEXTBOX. This would change the kind of dialog that pops up. For the text box one, the choices that are used are labels, and the text sent back is a CSV of label,responce,label,response. Or it can be limited to 1 option.

Bump! I ran into this problem yet again. We need a better script UI interface!

Agreed!!! I would LOVE THIS!!!!

I agree that a separate hook for dialog responses would be nice. I don't mind the automatic 'ignore' feature, except for a few things:

1. No response is given when 'ignore' is pressed, necessitating a cumbersome timeout script.
   
2. If I issue a dialog with no buttons specified (an empty list), the user receives two buttons 'Ok', which actually says 'Ok' on the dialog channel and 'Ignore', which of course reports nothing. How about just the 'Ok' button?
   
3. Finally, If this hasn't been implemented (I haven't checked), it should be. If I'm ignoring another user, I should also automatically ignore all dialogs from scripts owned by that user.
   [/list=1]

Issuing another bump to this thread!
And I found a new reason, here
Implementing a new dialog_button(integer dialogId, string buttonText) event will dramaticly improve security while using dialogs, since now we are forced to use a public chat channel to get responces from dialogs.

Two things...

1. I don't think the change should be implimented on the existing llDialog. If it was A LOT of objects would BREAK, and a good number of them are quite useful or expensive. it would cause a lot of work for a lot of people, and put a lot of people out of a lot of linden.

there should be a llPrivDialog() that would depreciate llDialog().

2. llPrivDialog() boxes as their own kind of communication would remove the need for the ignore because then it wouldn't be able to make someone say something in a public chat channel. problem solved.

FYI you trolled a 17 month old topic.
Some of the suggestions were implimented ages ago.

well, it WAS a good point. and, FYI, the wiki has this post linked for "discussion of future llDialog() features"... but a lot of these features would still be nice to have.

Yay, I've got to use this function. This must have been implimented because it was requested over a year ago!

Or does anyone know any technique to close dialog boxes? e.g. Can't I hit an ignore button by a command line?

I suggest that a dialog box closes whenever the user says one of the options (text of one button) on the dialog's channel. In other words: if I have a dialog that offers a "Do" button set to point at channel 23, saying /23 Do should close the dialog.

This would make it possible to even bind keys to gestures that push buttons in dialogs directly

Why does the dialog have to use a listen event? I thought those were frowned on as using up valuable cpu resources just to scan for text.. Wouldn't it be better to have the dialog return an integer corresponding to a specific choice? or initiate a 'dialog(int choice)' event?

Seems like they were planning on implimenting an input box at some point, but haven't gotten around to it yet.