Ignored
| LSL Portal | Functions | Events | Types | Operators | Constants | Flow Control | Script Library | Categorized Library | Tutorials |
|
LSL Feature Request |
| The described event does not exist. This article is a feature request. |
Specification
Currently there is no way to tell if a dialog has been ignored. Scripts rely on timer events to decide when to stop listening on a channel. This can lead to delays for the user while a state is waiting for a timer event. Conversely it also leads to confusion when a user tries to click a button of a dialog that has stopped listening. This proposed event would go a long way towards alleviating the problem without breaking existing implementations.
Caveats
There is no way to tell which dialog sent the ignored event since dialogs cannot be identified. The channel number could be in use by more than one dialog. It is merely an attempt to give some useful information to the script.
Examples
<lsl> integer channel = -1000; integer listen_handle;
default {
state_entry()
{
listen_handle = llListen(channel,"", "","");
}
touch_start(integer count)
{
llDialog(llDetectedKey(0), "This is a test dialog.\n\nPlease choose one of the below options.",
["Yes", "No", "0", "1"], channel);
}
listen(integer chan, string name, key id, string mes)
{
if(id == llGetOwnerKey(id))//won't listen to objects unless they aren't in the region.
llSay(0,name + " (" + (string)llGetObjectDetails(id, (list)OBJECT_POS) + ") chose option " + mes);
}
ignored(key id, integer c)
{
if(channel == c)
{
llListenRemove(listen_handle);
}
}
} </lsl>
Notes
PJIRA feature request SVC-3624
Johan Laurasia: For Starers, wouldn't it be easier to simply return 'ignore' (the button text) to the listen event? Secondly, I think the entire point behind the listen event ignore button is to dismiss the dialog window without triggering the listen event. Scripting would be easier if pushing the ignore button triggered the event, but then automatically returned and closed the listen event. Also, the typical way of scripting around the ignore button is to set a timer event and when the timer event triggers, you close the listen there. Therefore there is a way to sort of indirectly detect ignore being pressed. You can't actually detect it, but you can assume (after a time limit) that ignore was pressed. The only way I could see an ignore event being useful would be if the event returned no data, and the only valid function within that event were llListenRemove();.
Fox Oxbar: Users should have the ability to completely ignore dialogs without having any data sent back, if at least for some sort of privacy concerns (granted, the only thing you might reveal by clicking "ignore" is your AFK status). Many devices like vending machines wait for a timeout as discussed above and then send an IM saying that the user's session has timed out. That's not totally elegant, since the dialog is still sitting there. It might be useful to be able to cancel an existing dialog, but this opens the doors for a sort of open-close-open-close-open-close-etc. grief attack.
Deep Notes
Signature |
|---|