1.2: llDialog

Three things:

1) If you click the background in a dialog created with llDialog, it's as if you clicked the first choice

2) Longer labels are cut off with a "..." which is a big problem because

3) llDialog dialogs make _you_ the clicker say the choice on whatever chanel, not the object that caused the dialog, you, (this is good for scripting, as you don't have to go to extra effort to find out who caused the message, bit it's a bit surprising) and there's NO way to cancel, you have the choice of either saying one of the choices (possibly on channel 0) or leaving the dialog up forever.

Current implementation makes it trivial (I sent the extremely small script to Cory Linden) to make a window that will never go away until you log.

Please:
- Limit the distance to that of a sensor call (100m?)
- Allow a cancel with no response
- Add an option to mute dialogs from that object or objects by that owner.

Thanks!

Ack! Dont limit it to a sensor call! I was gonna use the feature as a remote for some objects across the world. I'd rather see a cancel button implimented.

I don't like the distance limiter either, but what is needed then is not only 'cancel' but also 'mute dialogs from object'.

The next preview release, and the final 1.2 release, will have some changes to llDialog.

* The message will have the prefix "Script Dialog:" instead of "Script Question:" to make it more clear it is the result of an llDialog() call.
* All llDialog() messages have an "Ignore" button. The user will say nothing if this button is clicked. Yes, this makes scripts a little harder to write, since you are not guaranteed a response, but it is the equivalent of the user logging out or losing their network connection, so a good script should be able to deal with this.
* The button formatting places Ignore on a separate line, so it's more clear that it isn't part of the script's buttons.
* Stacked up notifications have a "next" button (with bad art for now, better art to follow).

Dialogs that don't go away are a reportable offense, and should be reported to customer service. It will always be possible to create scripted objects that continuously have annoying behavior... for instance, constantly opening notecards. This is very difficult to be programmatically blocked, because it's super-useful to new users (born out in our in-house user testing) to have certain new items automatically open.

Something that *may* happen in 1.3 is another version of llDialog that raises a "dialog(integer button)" event, but that's too risky for 1.2.

James

James, can you put to rest the debate over the change for llInstantMessage() becoming a dialog as well?

We've concluded that it's redundant since we if we wanted to instant message with a dialog, we could easily duplicate this behavior with llDialog(message,["Ok"],31337), for example, but we would still like the old functionality of chat-inline IM text where preferable.

Thank you =)

-- Kex

....and llInstantMessage() is reverting to go into chat, for exactly that reason.

Wednesday, clicking the background of the dialog to click the default button is a feature, not a bug. The default button is almost always what you want to do, so rapidly clicking in the notification background lets you quickly dismiss the dialogs with minimal thought.

Fitt's law -> bigger click target!

James