Best way to issue commands to a script?

I'm trying to get into 'good' habits with my scripting here early on....so I was hoping someone could share with me...

What is the best method for allowing the user to 'control' your scripts? I've read in the Wiki how "Open Listens" can be 'bad' (Although I'm not sure what an "Open Listen" exactly is).

Are llListens best? Is it that llListen is just 'bad' when used on channel 0 but its good when used on another channel? Is it better to use menus?

Thanks!

A Touch menu with a time-limited listen. If you need sample code I can provide it.

Think it's more based on the particular situation. Using llListen isn't *bad*, but using multiple listens or sensors unnecessarily is.

When in doubt, and especially as you get started scripting and get familiar with the language, do what I did - ask other people who know more about scripting, or post in the forums and ask, and see if there's a more efficient, less cumbersome way to try to do what you're doing.

Yeah, llDialog is best for things with relatively fixed options, just have the touch event create a listener and have a timer kill the listener if no input for 30 seconds or so. Dialogs become a problem if the command input is not known in advance (think titlers, text above an av's head) in which case a touched listen (like dialog, but without the popup menu) is probably best. If the listen needs to be active constantly, then definately use a non-zero channel, the lag reduction of this seems to be in dispute, but it isn't worse, and less command chat spam.

all good answers.
to fill in the techie bits, Cyrus, "open listens" are "llListens".
they are "bad" because they wake scripts up and make them eat up processing power on the sims.

listens on channel 0 wake up whenever anyone in the area says pretty much anything - and as people are chatting all the time, that's bad.
listens on private channels are generally believed to be more efficient than listens on 0 - a certain level of activity is triggered even when people chat on 0, but the script is not completely woken up.
dialogs rely on open listens, and so suffer from the same "bad"ness - which is why everyone is recommending that you llListenRemove the open listen a few seconds after the touch.

Great!

Thanks to everyone for the great information I really didn't want to start getting into 'bad' habits and taking the 'easy way out' early on...and instead learn to do it the right way off the bat.

The touch-event to start the listener, and then killing the listen after a set-period of time will work fine for my purposes.

My question though is...what do you do if the item that will be listening is a small worn attachment? Like say...an animation overide that is small and attached to the spine? Do you folks have problems 'touching' it to activate the listen?

Yeah - if it's embedded inside your back it'll be tricky - this is why many AOs have been built into rings - until 1.7.

Now you can build it into a HUD attachment. No-one else can see it, but you can touch it.

In fact - if it's an AO - you possibly just want an ON/OFF control - this could be toggled directly in the touch event (without the need for a listen) - but even if you need 2 or 3 more options, seperate buttons on the HUD attachment might be just what you're looking for.

*little light goes on over head*

Thanks Ben! In the process of still learning all this, I hadn't even looked at the new HUD stuff everyone was so excited about. I had seen a few screenshots and just figured that they were for dashboards for vehicles and such. In reading and reading and reading the forums to try and learn, I had heard mention of folks saying that attaching things to the HUD would eliminate the needs for listens in many cases...and now I understand why.

Thankyou!

With regards to a "Timed Listen"...does anyone have a small code segment with an example of a "Timed Listen" I could take a look at?

This sounds like something the Lindens should fix. I normally have my objects listen on a high channel all the time because I assumed that would be efficiently implemented. Why would the sim even look at a script that's got a listen on another channel?

whats the opinion on llListenControl

Argent's question prompted me to go look up Kelly Linden's explanation again - and I must correct myself.

According to Kelly, open listens cause some proccessing even when no-one is chatting at all. Apparently each listen you have open causes a filter to run during each script frame. The filter checks all recent messages on its channel. Channel 0 filters will have a lot more messages to go through, comparing distance, id, message, name etc than other channels. But even high-channel listens appear to be waking up every frame, only to discover that their list of messages is empty.

So:seconded!!!

I'll try to get hold of Kelly to get this confirmed (who knows - maybe it's changed in1.7 ) and to try get an answer on llListenControl.

*sits quietly listening and soaking up the information*