llListen Best Practice

Hi guys,

I am working on a script that will be inside an attachment (a watch) that will listen for a command from the owner (/101Menu), and display a Menu.

I have never really got my head around the potential lag-inducing pitfalls of the llListen command, so I am hoping the forum can advise me of best practice. Is the following perfectly OK or not?

handle = llListen(101, "", llGetOwner(), "Menu";

TIA

Rock

This is pretty much as specific as you'll ever need to be. Keep in mind, though, that if you're using a llDialog call, that listen won't pick up any commands besides "Menu." Generally people just use a blank message filter with llGetOwner() as the key filter on a non-zero channel like you have, and use if statements or look up the command in a list to perform operations based on the message that comes in the listen event.

And remember to reset the script when it changes owner, so that the key in the listen filter will be updated.

Thanks guys,

It is just that I was getting confused when I saw sample menu scripts that use llListenRemove, timers and menu timeouts.

Rock

'Best' practice, is to make listens as filtered as possible, use low traffic channels if possible, and limit their amount of proccessing (by turning them off) if possible.

sometimes you have to leave them unfiltered (so anyone can use them)
sometimes you need to use crowded channels (like 0, so they can process general chat)
sometimes you need them to be always ready (so you can't close them)

worst case scenario is listening to general chat, all the time, and anyone that speaks

just out of curiousity, does you watch use the touch event? if not you could use that to start the dialog and listen, eliminating the need for an always open listen

Sometimes, it can be difficult to click a small attachment to start a dialog - especially while dancing.

As for your listen, Rock, the one downside to hard-coding the command ("Menu", is that you can't check for the lowercase version ("menu".

I will note though that by worrying about the possible impact your scripts can have on the sim marks the transition from just being a script tinkerer to a full blown scripter.