Method to close llDialog
tracked
Andromeda Quonset
There are times when the LSL scripter wants the script to remove the currently-display llDialog, and maybe put up a new one instead. My idea: when calling the llDialog, have it optionally return a value to identify it. The obvious would be key K = llDialog(key avatar, string message, list buttons, integer channel ); So the script could save key K, and if the specific dialog needs to be disabled, in the very least have a new function: llCancelDialog(key k); where all that's needed is to send the Key K value back (possibly having to supply the avatar key, too) and on the viewer, the llDialog could vanish. Or turn to a light-gray, which is also a recognized disabled-condition on other apps and web sites. The viewer could even have an option of Preference settings for an llCancelDialog to either be gray or to simply vanish. If the llCancelDialog were invoked on an llTextBox, have it cancel the same way.
Log In
Moo Boo
This is already available by structuring your llDialog users in a list with their last visited page before rendering the page dynamically:
[code]
userList = [];
userPage = [];
renderPage(key uuid, string page) {
string tmp_string;
list tmp_buttons = [];
if(page == "Home") {
tmp_string+="Welcome!";
tmp_buttons+=["Exit"];
}
llDialog(uuid,tmp_string, tmp_buttons, 1);
}
default {
click_end(integer num) {
integer tmp_id = llListFindList(userList, llDetectedKey(0));
if(!~tmp_id) {
userList+=llDetectedKey(0);
userPage+=["Home"];
}
renderPage(llDetectedKey(0), llList2String(userPage, tmp_id));
}
}
[/code]
*quick idea sketch, i'm not somewhere i can compile code at rn
I've personally managed to create a really dynamic multi-user menu system this way in approx 10KiB of memory, utilizing a notecard and llGetNotecardLineSync to maximize page count while minimizing memory usage.
mistaether Resident
If given the inclusion of a Specific Identifier for a dialog floater as per the proposal:
Have a viewer side mechanism to close a dialog box after a time X adjustable by a debug setting. (Something like 5 mins)
- Provides a consistent '-ish' mechanism for all dialogs, new and preexisting, to just close.
- If agent is no longer in the region, then it just closes. So no depending on an 'out of range' item.
Now the time specified by end user is arbitrary and in some cases might conflict with the intention of the scripter to maintain the dialog for a long period of time. Scripter can recall lldialog() via stored user.
---
As an additional tool using llenddialog (), to 'push' an updated dialog (updated message, updated buttons) to an end user could be useful. Especially in cases where more than one user is able to interface with an item. Just have as default behavior closing the old dialog, less 'stuff' on screen.
---
One thing to consider though is this. Using the llenddialog (), a script could just keep reopening a dialog on a users screen indefinitely. So having a built in 'If no new user action done in X mins, just stop sending it, period.' thing intrinsic to the function would be important. Thus preventing a need to 'instruct' less technical users to 'Hunt down and Block it'
Signal Linden
marked this post as
tracked
Extrude Ragu
One of those things that make SecondLife look like a clunky old game is having buttons on the screen that do nothing when clicked, so I generally agree with the need to be able to close a dialog.
Since an object can only host one dialog at a time (Calling llDialog a second time replaces the existing dialog) I don't think it's necessary to return a key? - It would be sufficient to just have llCloseDialog() and the viewer would close the dialog currently associated with the object.
Bleuhazenfurfle Resident
Extrude Ragu:
> Since an object can only host one dialog at a time
I believe that's still a viewer option, isn't it? So it's still not reliable. But I agree we don't need to be able to address a specific dialog.
llDialogClose can just close any open dialogs, in accordance with the same rules they'd use to replace them.
Andromeda Quonset
Bleuhazenfurfle ResidentI think there is an option to display more than one dialog at a time in viewer settings, but I don't think there's any real limitation on the number of dialogs that can be hosted. It's a matter of the script being able to receive and act on the additional responses, as every dialog could be talking on a different channel, and you'd have to have listeners for the active channels in the script. I think a script max's out at 64 listeners.
Cheshyr Pontchartrain
I can see this being useful to close a timed-out dialog, but there is no need to close one dialog to open another. The client does that automatically and has for a few years now. Unfortunately, it is impossible to change the behavior of current functions without breaking old code. It would require a new menu function. And since the system needs an overhaul anyway, it's best to address it there.
Zi Ree
The whole dialog system could use an overhaul as it was outlined in several posts on the old JIRA, for example: https://jira.secondlife.com/browse/BUG-233022
Thornotter Resident
Zi Ree That was my old JIRA post! Think it would be worth reposting it here?
Zi Ree
Thornotter Resident Go for it!