Talk:LlListen

Sorry Omei but I highly disagree with your judgement on the matter of the readability and grammar of this page. I would like a couple third-parties to judge the differences first before we keep this reverted. DonFabuuk Resident 20:19, 8 December 2013 (PST)

17. Has this function to be called in every state?
1. Yes, it's a feature. Strife Onizuka

17. How can i send commands in chat that cannot be seen by others?
1. 17. By other avatars?
   1. Use any channel other then 0 (PUBLIC_CHANNEL).
   17. By other scripts?
   1. Can't keep other scripts from hearing what scripts or avatars say. But you can write complicated channel hopping communications that span the entire range of 4 billion channels, reducing the probability of anyone capturing a complete message.
   17. What [happens] when i do configuration via public channel? There are some scripts that use commands like '/99stop' which cannot be seen in public channel by others
   1. They can be seen by other scripts, the number at the beginning indicates the channel. '/99stop' sends 'stop' on channel 99. That can also be written as '/99 stop' and have the same effect. Any script just has to listen on channel 99 to receive the command.

general usage

Please explain or show examples that explain what the arguments to llListen do. specific questions:

17. What does it mean to filter on name? is that the name of the speaker? does it have to be a full exact match, or can it match a substring of the character's name? (for example, can i filter by "Baroque" or "Ken" rather than "Kendown Baroque"?)
1. If you filter by name, the name must match exactly to the speaker. If it does not match in any way then no listen event is raised. There is no support for partial filtering on any of the filters.

17. similarly, I believe filtering by key means that the ID provided must be that of the speaker; is that correct?
1. Correct.

17. is the message filter case-sensitive? for that matter, is the name filter?
1. The message and name filters are case sensitive; the id filter is not.

17. What happens if you create a llListen with the exact same filters as a previously set up (and still active) listener? Does it ignore the second one? Create two with the same filter? Or error out? For instance, I have a case where I set up a listener to listen to a reply to several different dialog commands. Each command needs to make sure that the listener is open, but ideally, I could just set up the filter without checking to see if it already exists.
1. Nothing bad will happen if you open two listens with the same filters or if the filters overlap; only one listen event will be raised. That said, there is a limit to the number of listens you can have open at any one time by a single script (65 per script) which means that opening multiple listens and not doing any form of tracking is very bad.

Performance and Sim impact of llListen

I have heard some comments from sim owners that adding too many listens to a sim would either degrade performance, or there is a hard cap limit to the number that can be active. Is there any validity to this? There is also some discussion regarding filtered vs. unfiltered listens. Unfiltered is obviously an easy way to get aroung the 65 listener limit per script (and subsequently the number active on a sim), but may come with an overhead penalty. This seems somewhat counterintuitive as the filtering process should comsume more clock cycles than simply passing everything on a channel (or all channels?) to the script. -- Melany Lunasea

Listens do impact sim performance. It's better to have a single listen processing commands coming in on a single channel then it is to have multiple listens open all on the same channel. -- Strife Onizuka 23:13, 8 March 2008 (PST)

Kelly Linden on 11/13/07 to Scripters mailing list:

 You are pretty close.  The actual order of events is:
 1. Chat that is said gets added to a history.
 2. A script that is running and has a listen event will ask the history
 for a chat message during its slice of run time.
 3. When the script asks the history for a chat message the checks are
 done in this order:
  - channel
  - self chat (objects can't hear themselves)
  - distance/RegionSay
  - key
  - name
  - message
 4. If a message is found then a listen event is added to the event queue.

 The key/name/message checks only happen at all if those are specified of
 course.

 So, the most efficient way is llRegionSay on a rarely used channel.

( above comment by User:Winter Seale 19:32, 8 February 2009 )

Hee, i think i was adding this to the article while you were adding it to the talk page. Now we all know! --Cerise Sorbet 20:04, 8 February 2009 (UTC)

Trivia

The listen id can loop similar to a standard integer, such that it may become negative and then theoretically overlap. Although it would take months of straight opening/closing. Yes, I did just test this. -.- --Gregory Maurer 01:42, 16 January 2011 (UTC)