Talk:LlListen

general usage

17. Does this function have to be called in every state?
1. Yes, it's a feature.

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.

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)

Queen's English

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)

I mostly ignore grammar changes unless some nuance is lost or it becomes factually inaccurate. Furthermore short of Engrish, I will ignore minor grammar uglinesses unless I can add technical value to the content. I recommend this approach to all editors as it reduces conflict. Preaching done, onto the disputed territory.

1. "channel channel" - Repetition is repetitive, there isn't much gained by having it and it's a bit tacky. I'm more on the side of chucking it then keeping it.
2. "If id is a valid and not a null key then..." is not grammatical ("is a valid and"?) I think what you meant was "If id is a valid key and not a null key then...". Part of the reason for making it "null key" vs. "null key" vs. "NULL_KEY" is that a key can be effectively null without being NULL_KEY.
3. "the speaker's key must match exactly." vs "the speaker's key must be equivalent." The thing is, keys aren't case sensitive in this context. "equivalent" is the better word, however this does bring up the point that we don't expose this idiosyncrasy of keys anywhere in the documentation. This will have to go on the ToDo list.

I'll accept 'equivalent' then Omei Qunhua 01:30, 9 December 2013 (PST)

1. "If name is set then the speaker's name; then name must match exactly." I don't see what grammar rule makes that work, it's an odd place to put a pause and using two "then"s in a sentence is kinda passe.

I can understand why Omei would not like the changes, they are awkward. In an ideal situation, reverting would only be used when an edit was entirely wrong but this is reality. Normally when a situation like this would happen we (the community, yourself included) would review the final product make any corrections, and fix any awkward parts. If it were a little more obvious what you were trying to achieve with your edit, what nuance you were trying to elucidate, we would fix your edit, but your edit is sufficiently deficient the only way we can make the content make sense again is to revert your changes. I am not in love with the current content, I have no attachment to it, if you could explain what is wrong with it, I will help you change it.

-- Strife ^{(talk|contribs)} 22:05, 8 December 2013 (PST)

Being the busy body that I am, I couldn't leave well enough alone and had to edit the article (I have a cold, I was tired, not a good combination). I hope the changes are acceptable. I am aware the links to key don't lead anywhere (I'll work on them later). Any thoughts? -- Strife ^{(talk|contribs)} 10:00, 9 December 2013 (PST)

Debug messages viewable by others?

In this edit [1] it is stated that "you can raise your own script errors by using llSay on DEBUG_CHANNEL; however, remember that others will just see the script errors as the hovering 'script error' icon". That's not true for my viewer, which filters out debug messages coming from scripts in objects that I don't own. Is there any modern viewer for which that sentence is correct? If not, it should be removed. --Sei Lisa (talk) 06:15, 7 July 2022 (PDT)

I haven't found any viewers that allow you to view third-party script errors in my testing, either actual errors or messages via DEBUG_CHANNEL. Also server script errors appear to use llSay in my testing, so they cannot be heard region-wide as claimed. Also this isn't really a caveat. Moved to notes section and revised. -- Nelson Jenkins (talk) 20:11, 5 January 2023 (PST)