[BUG-234286] Implement String Return Types for llDialog and llTextBox

[sl-service-account]

How would you like the feature to work?

The LSL functions llDialog and llTextBox are changed, or separate functions are created with these changes. The 'channel' parameter is removed, and a return type is added in the form of a string. As these changes would break just about every script that uses these functions, I would suggest making new functions. They might be named something like llDialogLocal.

When a dialog box button is selected, the function returns the name of that button as a string into the script it originated from. When a text box prompt is submitted, the function returns the contents of that text box as a string into the script it originated from.

The functionality of the original functions can be replicated by using llSay to send the returned string over the desired channel.

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

The premier ways of deriving user input for scripts with SL's built-in UI are through llDialog and llTextBox. The next best way is to require the user to use channel chat formatted into commands a script accepts and understands. Using these methods are very accessible; they are in a format the user is familiar with, and allow for a lot of interaction without the scripter needing to develop an advanced HUD. However, text chat commands are not seen as elegant as the other options, and require the user to be prompted for the command, or remember the command, every time, meaning that dialog boxes and text boxes are far more preferable. However, they have a severe limitation in that the input must be broadcast over channel chat, even when that is extremely inappropriate, to the point of becoming a severe obstacle.

By far, the biggest challenge associated with llDialog and llTextBox, is the limitation that the user input cannot be viewed or altered before it goes to a listener (or is lost forever). The codes which listeners often use to determine their response to a message often does not fit or form well into button names made for the user, and in the case of a text box, are unlikely to be present at all unless the user puts them in. The insistence by dialog boxes and text boxes that their input must be immediately spit out on their parameter channel is a severe hinderance, when the alternative is simple and sane.

This request maintains that, when a dialog box or text box is submitted, the button name or the content, respectively, should be returned as a string. If that data really must be broadcast over chat, it can be easily and painlessly done with an llSay (or allow the scripter a wider choice of how to send that information!). And, much more powerfully, it can allow the scripter to append, prepend, or alter that input in preparation for where it is going.

And even more powerfully than that, it enables scripts where the user input does not need to travel over open chat to avoid opening and managing listeners that it really, really doesn't need. Just about any script which calls on a dialog box or text box to collect input flounders when the script isn't just repeating the contents of a text box, or simply using dialog box buttons as a simple parameter for a regular function call. If the use for those tools is any bit complex, it simply fails, or becomes ridiculous and tedious.

There is no reason, in my mind, that there should not be functions which collect user input AND keep it within the same script, when the originals fail to scale with any bit of complexity, and the part of their functionality getting in the way is so easily done manually, but with the option for far better, faster, and safer controls.

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-234286 | | Summary | Implement String Return Types for llDialog and llTextBox | | Type | New Feature Request | | Priority | Unset | | Status | Closed | | Resolution | Unactionable | | Created at | 2023-08-19T21:29:42Z | | Updated at | 2023-08-23T18:19:01Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2023-08-20T03:07:49.621-0500', 'How would you like the feature to work?': "The LSL functions llDialog and llTextBox are changed, or separate functions are created with these changes. The 'channel' parameter is removed, and a return type is added in the form of a string. As these changes would break just about every script that uses these functions, I would suggest making new functions. They might be named something like llDialogLocal.\r\n\r\nWhen a dialog box button is selected, the function returns the name of that button as a string into the script it originated from. When a text box prompt is submitted, the function returns the contents of that text box as a string into the script it originated from.\r\n\r\nThe functionality of the original functions can be replicated by using llSay to send the returned string over the desired channel.", 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': "The premier ways of deriving user input for scripts with SL's built-in UI are through llDialog and llTextBox. The next best way is to require the user to use channel chat formatted into commands a script accepts and understands. Using these methods are very accessible; they are in a format the user is familiar with, and allow for a lot of interaction without the scripter needing to develop an advanced HUD. However, text chat commands are not seen as elegant as the other options, and require the user to be prompted for the command, or remember the command, every time, meaning that dialog boxes and text boxes are far more preferable. However, they have a severe limitation in that the input must be broadcast over channel chat, even when that is extremely inappropriate, to the point of becoming a severe obstacle.\r\n\r\nBy far, the biggest challenge associated with llDialog and llTextBox, is the limitation that the user input cannot be viewed or altered before it goes to a listener (or is lost forever). The codes which listeners often use to determine their response to a message often does not fit or form well into button names made for the user, and in the case of a text box, are unlikely to be present at all unless the user puts them in. The insistence by dialog boxes and text boxes that their input must be immediately spit out on their parameter channel is a severe hinderance, when the alternative is simple and sane.\r\n\r\nThis request maintains that, when a dialog box or text box is submitted, the button name or the content, respectively, should be returned as a string. If that data really must be broadcast over chat, it can be easily and painlessly done with an llSay (or allow the scripter a wider choice of how to send that information!). And, much more powerfully, it can allow the scripter to append, prepend, or alter that input in preparation for where it is going.\r\n\r\nAnd even more powerfully than that, it enables scripts where the user input does not need to travel over open chat to avoid opening and managing listeners that it really, really doesn't need. Just about any script which calls on a dialog box or text box to collect input flounders when the script isn't just repeating the contents of a text box, or simply using dialog box buttons as a simple parameter for a regular function call. If the use for those tools is any bit complex, it simply fails, or becomes ridiculous and tedious.\r\n\r\nThere is no reason, in my mind, that there should not be functions which collect user input AND keep it within the same script, when the originals fail to scale with any bit of complexity, and the part of their functionality getting in the way is so easily done manually, but with the option for far better, faster, and safer controls.", } ```

[sl-service-account]

JIRAUSER341305 commented at 2023-08-20T08:07:50Z

While there are indeed flaws with those functions, they operate the way they do because the script and the client are on different ends of a network connection, and scripts can't (sic) just wait around for the user to click a button.

llDialog/llTextBox work by sending a message to the viewer to present the relevant input request, and then carry on with any further processing of the current event.  At some later time, the client may (assuming the user didn't ignore the dialog, didn't get disconnected, didn't teleport to a different sim, and/or the object wasn't detatched/derezzed in the meantime) send back a message carrying the users response.  In all those situations, what would you have the function return?  Significant time could have elapsed (assuming the script is even still running) during which your proposal would have the script sit there blocked and unable to do anything but wait — while it's event queue quite possibly fills and overflows.  Not to mention it would almost certainly guarantee the script won't get a detatch event before it gets boxed.

And it'd "only" probably require a new message for the viewer to send the response in, and all the requisite machinery in the sim to raise that message as an event of it's own, and that new/updated mechanism to add blocking behaviour to scripts, with the whole bucket load of brand new edge cases to sort out and test, and the inevitable slew of bugs that follow in it's wake…  And then when it was all said and done, I don't think I'd actually want to use it because of that blocking thing — far more trouble than it's worth.

It would be nice for those two to respond with their own event, though, which wouldn't require that whole blocking thing.  But you know, on second thoughts, the listen dance really isn't that much of a problem (certainly compared to the likes of HTTP-in).  Just give me a prefix string argument on both commands, that gets prepended to the response string.  That'll do me.

[sl-service-account]

JIRAUSER344921 commented at 2023-08-20T16:13:53Z

@Bleuhazenfurfle

Scripts which need to wait for those responses are exactly the kind that suffer from the current implementation. There are times where I would rather the script just hang until the text or dialog is dealt with, than continue. The inability for the scripter to set timeout durations (as parameters, at least; one could technically do that with timers) is definitely another issue, but one which I didn't bring up, because I felt the feature request might get too complex. I'd rather have a "no, but" than just a "no", and I feel we're on the right track right now. Another problem is definitely the lack of feedback from those toasts when they are ignored, muted, or x'd. If those toasts actually said useful things, then the script could be set up to wait until it gets what it needs, or the thing it's waiting for times out. Though, as you point out, prepends could help quite a lot.

However, I don't think prepends would work the best for dialog boxes. That might help for a script which has many dialog boxes that each have narrow purposes, but it does nothing for a script with some dialog boxes that can give a lot of options for very different functions. That's not the biggest deal, because one could turn some that do a lot into many that do a little, but if we're at the point of a new parameter like this, I'd rather just go the full way and turn the list parameter for the dialog box into something strided, so that its buttons are aliased: when a button is hit, it goes to its stride in that list and chats its alias instead of its name. What you would normally prepend could be included in the alias, but with the benefit of being able to define multiple codes on the same page.

So, instead of having a single parameter which always prepends "SAM" to any button pressed, buttons 0-2 might include "SAM" in their alias, while 3-7 might include "BOB" and 8-11 might include "RALPH". I would argue to only broadcast the alias and NOT the alias+button name, because that would give the scripter more freedom in naming their buttons to something attractive to the user, not to the code. For text boxes, however, there is no list parameter, so a parameter for a prepend would have to do, and I think it'd do great.

On the other hand, the dataserver event is meant for receiving asynchronous data. That wouldn't fix everything by a long shot. It'd basically just be trading needing to catch the data in a listener versus the dataserver. That might or might not be better. I haven't used or studied the dataserver event that much. But it would be an option? I think the other option, or maybe in addition to it, would be to, yes, when a dialog or text is opened, engineer it so that code block does not proceed until it outputs or times out. However, other blocks may still. So if a text box is opened on a touch_start, that touch_start hangs, but if the object is touched again, a parallel touch_start begins, up until a safe limit. Other states will continue to run, and certain states, such as state_exit, will remove any of those kind of events from the event queue, if they are still alive. But that will probably run into the issues you're talking about, and will be hard to make smooth.

So... in terms of feasibility.... Just having a few ounces more control over what dialog and textboxes output, before it gets to the listener, would go an incredibly long way. Your suggestion for a prepend would work really well for textboxes, I think, but for dialogs, not only is there the option for something more advanced because of the list, but it's far more useful to alias each and every button (and since that list is currently limited to 12 items of 24 bytes each, doubling the items to 24 and allowing for aliases that are a little longer shouldn't cause many problems).

I still think that this data traveling, unchaperoned, over open channels in the hopes that it is caught by a listener (and the correct listener) is... not good, but it seems I'll have to leave someone more knowledgeable than me to figure that out. It's not the main issue, anyway. I just don't want to have to change the entire way my script is written just to collect some basic user input.

[sl-service-account]

JIRAUSER341305 commented at 2023-08-21T07:51:12Z

I don't personally disagree with any of that, really…  However…

Scripts run or stop as an indivisible unit; you never have two events in the same script running concurrently — let alone two concurrent instances of the same event.  Thinking about that conjures nightmares of re-entrancy…  Cthulhu would likely be an easier beast to tame.

With that in mind…  It would be nice if LL provided us a few basic tools to help with that — function references/delegates are my #1 pick, of many (it's not hard to fake in LSL, just not terribly efficient, and sooo much boilerplate!).  So yes, I too would like to have the option for when I deem it safe — emphasis on it being an option, however.  LSL is an event-driven environment, and you just have to accept that and learn to live with it — the number one implication of that, is that blocking is generally bad news.

And yes, that is exactly what I'd meant by using a strided list.  (That's one of many ideas that've been around the block a few times, along with proposals for getting in colours and styles, my BUG-233599, and various others.)  A prefix string is simpler than the strided buttons list, and avoids the issue of a lot of repartition in those response values (allowing them to be shorter — if we were to get both, then even just another 24 bytes would be fine).  This would cover at least the rather common case of menu, page number, and a uuid (yes, it can fit a key, especially with a llKey2Base64 function).

Shoehorning it into dataserver would probably work (albeit horribly ugly), and additionally, bring it under the umbrella of something like BUG-232876 also (using the agents uuid as the event key); the benefit of which, is that the default behaviour (and indeed the underlying mechanism) remain event driven as they are — and then you wrap it in blocking behaviour when you deem it safe to do so (and it helps contain all those issues in one place).  232876 could additionally be extended to any event that uses a key as id (possibly even including listen — agent uuid), or a new event for this task (likely also using agent uuid).

Lastly, don't underestimate the pain induced by users being able to rudely disappear without warning!

[sl-service-account]

Spidey Linden commented at 2023-08-23T18:19:01Z

Hello, and thank you for your feature request.

Incoming suggestions are reviewed in the order they are received by a team of Lindens with diverse areas of expertise. We consider a number of factors: Is this change possible? Will it increase lag? Will it break existing content? Is it likely that the number of residents using this feature will justify the time to develop it? This wiki page further describes the reasoning we use: http://wiki.secondlife.com/wiki/Feature_Requests

This particular suggestion, unfortunately, cannot be tackled at this time. However, we regularly review previously deferred suggestions when circumstances change or resources become available.

We are grateful for the time you took to submit this feature request. We hope that you are not discouraged from submitting others in the future. Many excellent ideas to improve Second Life come from you, our residents. We can’t do it alone.

Thank you for your continued commitment to Second Life.