Coding for Multiple Dialogs

I'm new to SL scripting. Right now I'm trying to figure out how to implement multiple dialog boxes. I want to write the following code.

-Present Dialog 1
-Get User informatoin from Dialog 1

-Present Dialog 2
-Get User information from Dialog 2

-Perform Calculations based on Dialogs 1 & 2

-Present Results of Calculations to User

Right now, I have figured out that I would have to move my code for the calculations from the touch_start section to the listen section of the script. This would work if I only needed the results of one dialog box, but I'm stuck when it comes to how to wait until I have the results of both dialogs.

Any help, would be appreciated.

probally the most basic way would to use states ie

default, start ask first dialog question
wait for response, define a varible and move to state two

state two, ask second dialog question
wait for response, define a second varible and move to state three

state three tally the values

Thanks Osgeld, I was considering going that direction after I posted my question.

Right now, I'm researching how SL cleans up after itself. For instance, if the user clicks Ignore or the dialog times out, my listen will not get a response. Do I need to set a timer to check to see if this is the case so I can clean up and exit gracefully? Once I change states, does SL automatically terminate the previous listener?

And, if User A touches the object, then User B touches the object (before User A is done), does SL create separate instances of the script, or do I have to keep track of the separate users manually?

Perhaps, I'm being overly cautious, and I'm definitely still a little unclear on how SL scripts handle states. This seems to require a mindset change from usual programming. I just want to write clean code that doesn't waste server resources.

SL doesnt clean up anything, there is no timeout on llDialog and pushing the ignore button doesnt do anything but clear off the menu from the user's screen

so you will probally need to setup a timer each time a question is asked just to shut off listens and reset the script

listens get shut off during a state change timers do not

I'm going to have to test that, because I thought a timer and relevant event were local, not global (and never had a problem).

Yes, thank you, the Wiki says that. *Rolls eyes* Doesn't mean I believe it any more than previously. I said I'd have to check it out for myself.

let me save you some thought

default
{
    state_entry()
    {
        llSetTimerEvent(10);
        state two;
    }
}

state two
{
    timer(){llOwnerSay("time");}
}

Thanks Osgeld and Draco.

I used the changing states method and it works, at least if the user doesn't do anything wierd/wrong, and we all know how users never do anything wierd or wrong.

Now, all I have to do is go and add some error checking with the timers, etc.

I'll post a generic sample of my code in the forums once I get the code tightened up.

Thanks, Osgeld. What I meant by "test later" I meant test LATER, as I dont' have the time to be poking around with scripts at the moment. Real Life is currently got me quite busy.

If you'll trust other people, and hunt on this forum, I didn't know that timers persisted, did something very similar to the script above and I can confirm that if you start a timer in one state and change states, the timer event in the new state fires.

The script and the transcript I got are posted somewhere.

I trust other people, but it's still something I want to poke around with myself.

And just did, they do persist. Good to know.

OK, since the timer event persists, how do you go about killing the timer once it's no longer needed? And once it fires, does it repeat automatically?

Hi Tex

to cancel timer:
llSetTimerEvent(0);

repeats with the period (in x seconds) of the latest llSetTimerEvent(x);

btw, if you redo llSetTimerEvent(x) for each state you get the illusion that timers are state dependent.

Ed

Thanks Ed. I'll try that tomorrow when I get home, it's time for bed now : )

Oh, as an alternative to the multiple states, you can have each dialog box use a different channel for it's answer, and filter initially by channel, then by answer.

the listen would like this (in psuedo code)

listen()
if chan==dialogOne
if(msg==ans1.1)
else if(msg==ans1.2)
else if chan==dialogTwo
if(msg==ans2.1)

etc...

everyone probally has a way to do it hehe

There's quite a few ways, but for quite a few applications that I use nested dialogs like this changing states isn't usually desireable, so the changing channel number is one I use quite a lot. Just for completeness it deserved a mention.

Personally I use it sometimes when states would do the trick too - I find it's easier if the logic of the menus is all together, but that's just me.

And whilst talking about completeness you can also do it in at least one other way. Since the buttons will accept 24 character "names" but only display 8 characters or so, put the button name, some spaces and a number for the menu level, then llGetSubString(msg, -1, -1) to check the last character so you know which menu you're using. I think it's slower than the channel change approach, and chews memory too, but it's an option.

Thanks Eloise, that is an elegant solution to my problem. I'll keep that method in mind for later, since I already have some working code using Osgeld's method : )