[BUG-233022] LSL Dialogs 2.0

[sl-service-account]

How would you like the feature to work?

New Function: llShowDialog(key avatar, integer type, string message, string name, list values)

• Shows a dialog to an avatar. If a dialog is already shown to the user by the same script, the new dialog replaces the previous one.
• "type" is one of DIALOG_BUTTONS, DIALOG_TEXTBOX, DIALOG_LIST, or DIALOG_AVATARS.
• "message" works the same as it currently does for llDialog.
• "name" is a script-defined name for the dialog and is used to supply menu state related information back to the script when an interaction occurs.
• "values" depends on the type of menu. For DIALOG_BUTTONS and DIALOG_LIST it is a strided list of [display_text, value] pairs. For DIALOG_AVATARS it is a list of avatar UUIDs. It is ignored for DIALOG_TEXTBOX.

New Function: llHideDialog(key avatar)

• Closes all dialogs shown to an avatar by the script.

New Event: dialog_action(key avatar, integer action, string name, string value)

• Event received when a dialog is interacted with. With these new dialogs, a listener is not needed.
• "action" is one of "DIALOG_VALUE" or "DIALOG_CANCEL". DIALOG_VALUE is sent when a value is selected (e.g. a button click or a list selection then confirmation). DIALOG_CANCEL is sent when the Cancel button is clicked.
• "name" is the value of "name" supplied to llShowDialog
• "value" is the value of the button or item selected. In the case of DIALOG_AVATARS, it is the avatar's UUID.

Behavioral Notes:

• Dialog buttons will now be rendered "left to right", then "top to bottom" instead of the current "bottom to top" behavior of llDialog.
• A maximum of 6 rows of buttons will be supported instead of the current 4.
• Dialog buttons with empty display text as not rendered and are treated as blank space in the UI.
• The DIALOG_LIST dialog type render a scrollable list of items, one of which can be selected.
• The DIALOG_AVATARS dialog type functions the same as DIALOG_LIST, except it also automatically retrieves and renders avatar names from supplied UUIDs.
• All dialogs will have a "Cancel" and "Block" button. Cancel works the same as Ignore currently does with llDialog, but has been renamed to better match most other user interfaces (Windows, Mac OS, phones, etc). An additional "OK" button will be shown to the left of "Cancel" for the DIALOG_LIST and DIALOG_AVATARS dialog types to allow the user to confirm when they are done making their selection want to submit it to the script.

• If the dialog message, button display text, or list display text is too long to be displayed it is truncated instead of causing the dialog to fail.

  Why is this feature important to you? How would it benefit the community?

  This LSL feature request resolves many issues with the existing dialog system:

• Listeners are not required, which reduces script resource usage and allows users to interact with a dialog after any amount of time (most existing dialog scripts close the listener after a timer to free up resources).
• Directly supports two of the most common dialog use cases: selecting an item from a list (e.g. an animation in furniture) or selecting an avatar from a list.
• Allows the displayed text for a button or list item to be different than the value received by the script. This helps avoid complex data management in the script.
• Allows an additional script-defined value ("name") to be sent to the dialog and received when an interaction occurs. This also helps avoid complex data management in the script and makes implementing pagination or hierarchical menus much easier.
• Improves the user experience by making it much easier to have menus support multiple simultaneous users due to the simplified data management.
• Improves the user experience by having a consistent "Close" button (most existing dialog scripts add a "Close" button in addition to the default "Ignore" for usability reasons).
• Improves the user experience by avoiding multiple dialogs shown simultaneously by the same script (note: this might only be true for third-party viewers today).

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-233022 | | Summary | LSL Dialogs 2.0 | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Unresolved | | Reporter | Thornotter (thornotter) | | Created at | 2022-12-04T04:42:08Z | | Updated at | 2022-12-09T10:05:19Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2022-12-04T07:05:41.463-0600', 'How would you like the feature to work?': 'llShowDialog(key avatar, integer type, string message, string name, list values) {}\r\n• Shows a dialog to an avatar. If a dialog is already shown to the user by the same script, the new dialog replaces the previous one.\r\n• "type" can be one of DIALOG_BUTTONS, DIALOG_TEXTBOX, DIALOG_LIST, or DIALOG_AVATARS.\r\n• "message" works the same as it does for llDialog.\r\n• "name" is a script-defined name for the dialog and is used to supply menu state related information back to the script when an interaction occurs.\r\n• "values" depends on the type of menu. For DIALOG_BUTTONS and DIALOG_LIST it is a strided list of [display_text, value] pairs. For DIALOG_AVATARS it is a list of avatar UUIDs. It is ignored for DIALOG_TEXTBOX.\r\n• Dialog buttons are rendered "left to right", then "top to bottom" instead of the "bottom to top" behavior of llDialog.\r\n• Up to a maximum of 6 rows of buttons is supported instead of 4.\r\n• Dialog buttons with empty display text as not rendered and are treated as blank space in the UI.\r\n• The LIST and AVATARS dialog types renders a scrollable list of items, one of which can be selected. The AVATARS dialog type automatically retrieves avatar names.\r\n• The "Ignore" button (i.e. of llDialog) is changed to display "Close". "Block" works the same as with llDialog.\r\n\r\nllHideDialog(key avatar) {}\r\n• Closes all dialogs shown to an avatar by the script.\r\n\r\ndialog_action(key avatar, integer action, string name, string value)\r\n• Event received when a dialog is interacted with. With these new dialogs, a listener is not needed.\r\n• "action" is one of "DIALOG_VALUE" or "DIALOG_CLOSED". DIALOG_VALUE is sent when a value is selected (e.g. a button click or a list selection then confirmation). DIALOG_CLOSED is sent when the Close button is clicked.\r\n• "name" is the value of "name" supplied to llShowDialog\r\n• "value" is the value of the button or item selected. In the case of DIALOG_AVATARS, it is the avatar\'s UUID.', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'This LSL feature request resolves many issues with the existing dialog system:\r\n\r\n• Listeners are not required, reducing script resource usage and also resolves the negative user experience of listeners randomly closing on a timer while the dialog is still open.\r\n\r\n• Adds direct support for two of the most common dialog use cases - selecting an item from a list (e.g. an animation in furniture) or selecting an avatar from a list.\r\n\r\n• Resolves the confusion of most dialogs having an "Ignore" button as well as a script-defined "Close" button, the later of which closes the listener.\r\n\r\n• Allows the displayed text for a button or list item to be different than the value. This reduces the need for having "lists of lookup data" stored in the script.\r\n\r\n• Allows script-defined data to be passed through the dialog and back via the action. For example, a "menu name" to distinguish between multiple menus, a "page" for paginated menus. This also makes it much easier for scripts to write dialogs that support multiple simultaneous users without complex data management and overhead.', } ```

[sl-service-account]

Extrude Ragu commented at 2022-12-04T13:05:41Z

I agree with the need for better tools for objects to converse ideas and concepts back and forth with a user, but do not agree with this particular implementation because I do not think it's future proof, really we need to be able to just pass a list of dialog parameters. Ie llDialog2(list options) this allows for expansion in the future

Reason for this is that I can think of many features and controls that could be added to dialogs such as new controls (for example, pose adjustment controls, sliders, radios, checkboxes, joysticks) or new features (such as dialog position, dialog themes, dialog icons, option to show dialog inworld next to object like in a game rather than as a pop up window...) . Don't suspect LL would add it all in one go and the ways we need to converse with objects change over time. Better to have a function that can be expanded upon later than be limited by the function signature

An alternative was suggested on the discord by Simon Linden, using the ability to render text-on-a-face and using objects instead to provide flexibility, which is also not a bad idea, but needs fixing the obvious problem that objects usually need attach permission to appear in hud space whilst a dialog does not. We need some solution for that to make Simon Linden's suggestion viable IMO. Link to the discord conversation https://discord.com/channels/677442248157167619/681996187162640406/1048821680878927932

 

[sl-service-account]

Toothless Draegonne commented at 2022-12-04T14:26:34Z

I would consider making the new function return an identifying key, which can be tested for by the key being passed into the proposed dialog event. This would allow for a (limited) number of dialogs per script, as well as allowing for an llCloseDialog(key id) function, for closing of single dialogs as well as a close-all function.

This may make it possible for a script to more easily handle input via dialog from multiple agents at once. 16 may be a good limit initially, as that's the same number of agents that can be detected via sensors.

[sl-service-account]

Dan Linden commented at 2022-12-07T21:46:25Z

Issue accepted. We have no estimate when it may be implemented. Please see future release notes for this fix.

[sl-service-account]

Kadah Coba commented at 2022-12-09T10:05:20Z

+1 for dialogs as events.

Things I'd love to see:

Controls that aren't just buttons. Like dropdowns, checkbox/toggles, spinners (number input), texture picker (would only work for full perm, but thats also true of the current workarounds use text box and UUIDs).

Mixed controls on the same dialog. Example, text input with custom buttons.

Timeouts.

Image display.