Help with Ignore Button with LLDialogue

Hi,

I'm having a problem with the ignore button using the LLDialogue function.
Can anyone tell me what it is for??
It says in the wiki that a script can't recognize this as a response.
This is apparent since if it gets selected the script freezes and can't be "Touched" again until reset.
The only idea so far is to put a test to see if the response is "None of the Above" - basically -
if(response != button1 or button2 or button3 , etc.);
This seems inelegant.

In the script I'm working with the buttons cause State Changes - which works fine - but could it be related to this approach??

As usual, thanks in advance.

Remember that the menu is only an automated way to send chat text out for you. The ignore button simply means "don't bother typing anything". So, your script needs to be prepared for the case that it won't get any input.

The ignore button is for exactly what is says: "Ignore" this dialog and do nothing else. It is there simply to dismiss the blue dialog box without selecting any options.

Trying right now to catch that event -

with LLDialogue the script waits for a reply from the user it is keyed to.

I have been trying to add an out with a call to another state after all the tests for the button script, but that doesn't seem to be working. It doesn't look like it gets any kind of event to even test the buttons if you hit the ignore button.

So - I can add a timer but that is not good.
If I set it for a reasonable amount of time to choose and respond, then after hitting the Ignore button you will be waiting and wondering what is going on until the timer gives a response.
But at least the script will move on and un-freeze.

I still don't understand the rationale of a button that doesn't give any kind of response in a situation where you are inevitably going to have the script sitting and waiting for one??
I am missing something aren't I?

There is the situation where you can use a dialogue box to simply tell an avatar something - but it seems set up precisely to get a user response. I know of other programs where you can hit the Ignore button and the script continues so I know its possible but just don't see the method.

LSL scripting is event based. it isn't quitie like traditional PC programming. It took me awhile to get used to it I know. You have to think of Dialog as offering choices, and having the code act on those choices, but not actually "waiting" for a choice. The code should be structured so that if you never receive a response, that's okay. Using a timer to time-out the listen is perfectly okay. It's hard to really explain what you should do without seeing and understanding exactly what you are trying to accomplish.

The script does not wait at llDialog. It continues to run completely independent of it.

You can issue a llDialog call today, and wait until tomorrow to click an option, and the script will not be waiting for you.

Here's how it works:

When you call llDialog, a packet of data is sent to the client, containing the title, and the list of option/button strings. The client displays the dialog to the user. The user clicks one of the options, whereupon the selected string is sent back to the server as a chat message on the specified channel. If the user clicked "Ignore", this doesn't happen; the dialog box goes away and nothing is sent back to the server.

The object then hears your avatar saying the selected option on the channel via the listen event, assuming you set one up, and then picks up processing from there. Between the llDialog and the receipt of the option text message in chat, the script is blissfully unaware of it, and continues on completely and totally asynchronously. It doesn't wait, it doesn't return the option at the llDialog. It blows right through it to any/all statements past the llDialog and continues processing events when that event is done executing.

A dialog represents an event outside of your script. Indeed it doesn't even 'belong' to the script that launches it. It simply acts as a proxy on behalf of the agent with the key id with which it was launched. When a button is pressed it presents itself as a listen Event to *any* script that has the relevant listen filter in force - hence it is also very common to randomise the channel being used with llDialog to guard against 'cross-talk'.

The ignore button means the agent remains silent, which would also be the case if they just left the dialog on the screen, or logged off. You can include your own Cancel (or whatever) button but the ignore button is really there for the convenience of the agent, not your script.

So, the best you can do is to wait a 'reasonable' interval before putting the script back into a touch-ready condition.

Here's one of the dialogue boxes where the user selects a volume for a sound being played by another state. If you select Ignore the program just sits and can no longer be touched to trigger any other event. Maybe a touch-start is needed??

state GettingVolume
{
state_entry()

{// llOwnerSay("Entering State GettingVolume";
Handle = llListen(CHANNEL, "", DJ_Key, "";
llDialog(DJ_Key,"The Present Volume Is " + MyVolume, MENU_Volume, CHANNEL);
} // end of state entry


listen(integer CHANNEL,string name,key DJ_Key, string GetVolume)
{ MyVolume = GetVolume;

llOwnerSay("The Volume You Picked is " +MyVolume+ " MasterVolume is " +MasterVolume);

TotalVolume = ((float)MyVolume * (float)MasterVolume) / 100.0;
if(TotalVolume > 1.0)
TotalVolume = 1.0;

llAdjustSoundVolume(TotalVolume);
state Programming_Audicle;

} // end of listen

} // end of state GettingWave

Yup. You are depending on the condition that there MUST be a response, which you can't do, because it is possible you may never get one, for many reasons, not the least of which is someone clicking the Ignore button.

If you MUST code it like this, then you will have to include a timeout of some kind which puts the script back into a functioning state. Stick llSetTimerEvent(10.0); in the state_entry() event, and add a timer() { llSetTimerEvent(0.0); state Programming_Audicle;} event to your script or somethign similar.

Imagine there was no ignore button...

Imagine someone flying into a really crowded place, scanning for all the avatars, and presenting them all with a dialog with options that said things that were quite inappropriate...

Now, you MUST click one of the dialogs to get it off your screen...

Do you want to make your avatar say something really horrible? Because it won't be an object speaking...it will be white text coming from you. Or would you like to click IGNORE?

There wasn't always an ignore button, and what I just typed doesn't have to be imagined.

Thanks for all the response to this.

My conundrum I think is that while the program could just move on with a call to another state - that state change would, I believe, eliminate the listen that would be used to get the response I want from the displayed dialogue. So I don't see any option there but to sit and wait for some event. I know I can always add a BACK button, and usually do, but it just bothers me to have a situation where a user response can hang the whole thing - it just begs to be clicked. lol.

Welcome to the world of event-driven programming! Where blocking calls/functions/code/whatever of any kind are da DEBBIL!

Design your code to work whether or not the user clicks on an option, and you're golden.

Da5id, this is implied in what everyone one else is saying although not clearly stated. The reason the dialog "hangs" is that it gets stuck in the GettingVolume state and can never move on because it never "hears" anything if ignore is pressed.

If you want to allow the user to bail out, you could offer a cancel button that you trap for. That won't help you get untrapped if the user hits ignore though.

Why do you need to use a separate state for this? Why can't all of this be placed in your main state? That way your program could continue to work. My advice is to find a way to put this functionality in your main state.

Talarus gave the correct answer using a timer event:

state GettingVolume
{
	state_entry()

	{//   llOwnerSay("Entering State GettingVolume");
		Handle = llListen(CHANNEL, "", DJ_Key, "");
		llSetTimerEvent(10.0);
		llDialog(DJ_Key,"The Present Volume Is  " +  MyVolume, MENU_Volume, CHANNEL);
	} // end of state entry

	listen(integer CHANNEL,string name,key DJ_Key, string GetVolume)
	{
		MyVolume = GetVolume;
		llOwnerSay("The Volume You Picked is " +MyVolume+ " MasterVolume is " +MasterVolume);
		TotalVolume = ((float)MyVolume * (float)MasterVolume) / 100.0;
		if(TotalVolume > 1.0)
			TotalVolume = 1.0;
		llAdjustSoundVolume(TotalVolume);
		state Programming_Audicle;
	}     // end of listen
	timer()
	{
		state Programming_Audicle;
	}
} // end of state GettingWave

Just declare a global variable for a default volume level. If it times out then it will go to the next state with either that default value or the last declared MyVolume if the user has set it previously.

Not necessarily... you can always log off.

It's a fine distinction, but actually the text will be coming from the object which called the dialog, so the griefer must remain in the area for the gag to work (assuming an attachment). And since dialogs contain the name and owner of the object which created it, that leaves the griefer open to his/her gag being called by anyone subjected to it. Though if they do take such a chance, it would require a lot of careful observation of who is withing speaking distance of whom to discern the true origin point of the remark in question.

Brief messages (24 characters max) can be done in white text. (They do break eventually, but the origin won't be clear in chat)

default
{
    touch_start(integer schminteger)
    {
        llDialog(llDetectedKey(0), "Would you like to be invited to the free cookies and milk group?  Members get free cookies!  And milk!",["OK! I want to club seals", "No, I don't bathe. Ever."], 0);
    }
}

Sure, but making people say they're stinky is a far cry from inappropriate uses of soap.

yes, you are =)

llDialog provides an OPTION to interact with, just like the menu buttons on your web browser. you don't have to push any of those buttons, and the program doesn't wait for you to do so to keep working. it is a passive and reaction based item, rather than a stepped action based item.

it may help to think of each event as a separate program, it only runs when it gets it's specific input... untill then it's just an option, like a desktop icon.

llDialog is opened in response to an event, it provides buttons, and those buttons may or may not be linked to actions that can be triggered in the listen event. it may only cause an av to say something (actually this is all it ever does). maybe I don't want to say anything, or press any buttons...

now if it were a program I'd just kill it, just like a popup, and just like a popup, if it knows it's been killed, it can do soemthing else on the way out, like spawn another pop-up.

llDialog is only providing a more controlled option to interact with llListen... it doesn't force you to, it only rovides an option....

as for coding I try to put 30-45sec timeouts on my listens, and provide a cancel button (which is bigger so more likely to be used), so I can process null listens out faster, it may not be perfect, but just because you offer something, doesn't mean someone wants it, and forcing users to jump through hoops (while programaticaly effective) isn't very friendly.

EDIT:
actually llDialog Text DOES come from the user clicking it (as determined by speaker key) although the center for the chat radius might be the object that called llDialog (cant remember on that one)

Whatever option you click is the same thing as you typing the text of that button into your chat bar on the specified dialog channel. The only difference is that when you type into your chat bar, it originates from your avatar. When you click the button, your chat originates from the point the dialog was called.