2010-03-11T00:08:23Z

Winter Seale: Added @emailsnapshot feature suggestion

===Question regarding @remoutfit and teens===

Thank you for putting up that API.

But I got a question regarding the ''@remoutfit[:<part>]=<y/n>''-command:
It says''(underpants and underwear are kept for teens)''. What do you mean with that?

Is removing underwear disabled only on teengrid? Is it disabled in PG Areas? Or just one of your nice jokes? :-)

MK: No no this time it was not a joke, the standard viewer actually checks that you're not on the teen grid and if you are, discards removing underwear. I took care of not breaking that check when adding the remoutfit command :)

== How to use for bondage furniture? ==

Hi Marine,

Good stuff, your viewer. I have a question on how to use the API in bondage furniture.

As a test I did put the @remoutfit=force in the menuhandler of a bondage cross that I have. Now, when I use the menu while not sitting on the cross ... I am suddenly naked. Blush. Nice effect, but not what I expected. I expected the command to work on the AvatarOnSitTarget, if that person would use your viewer.

Do I do something wrong, or is your viewer focused to impact the Owner of worn attachments? If the former, please let me know how to do it right. If the latter, it would be great if the viewer would work on Owner in case of attachments, and work on AvatarOnSitTarget in case of objects to sit on.

Looking forward to your answer.
Ciao, Tam

The answer came to me in world. Use the RealRestraint Relay
https://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLifeRelaySpecs

== Meaningless or App-Defined Rules ==

I noticed (accidentially, due to a misspelling) that if you send a rule that doesn't exist, it has no effect, but it DOES remember the rule, and can be retrieved using @getstatus. For example, you can llOwnerSay("@randomtext=n") and later when you call llOwnerSay("@getstatus=x") the rules in the response will include "randomtext" in the list.

Is this a bug or a feature? The reason I ask is, there are some good uses for this if the behavior can be depended upon, but if it's likely to disappear in a future version, then I'll steer clear of using it. Thanks.

--[[User:Galatea Gynoid|Galatea Gynoid]] 12:07, 17 August 2008 (PDT)

Actually there is no such thing as "a rule that does not exist", the viewer takes whatever it is sent and puts it into its internal list for later. This is because I don't want to duplicate commands (I have to for some of them, for instance when checking whether the inventory is already open when issuing a @showinv). It's by design so it's easier to just poke at the code and add your own command without wondering whether you have to add it to a static table somewhere. So it's neither a bug nor a feature I would say.

And to answer your actual question, it's very unlikely to change in the future, at least as long as I'm in charge. Yes you're right, it could be a good way to store data in-world for the time of a unique session. However keep in mind that @getstatus gives a regular chat message, that is capped at 1023 characters.

--[[User:Marine Kelley|Marine Kelley]] 01:47, 18 August 2008 (PDT)

== @sendchannel needs a bit of clarification ==

The way it's worded, the explanation of sendchannel is a bit confusing. I ''assume'' the way the restriction works is that the command @sendchannel=n would restrict all alt-channel chat, but the command @sendchannel:3=n would allow chat on that specific channel even if the global restriction is in place. The way it's worded though, it seems like it could be that @sendchannel:3=n would restrict chat ''only'' on channel 3. -- [[User:Felis Darwin|Felis Darwin]] 21:12, 7 December 2008 (UTC)

Maybe it's poorly worded... @sendchannel:3=n does add an exception to the @sendchannel restriction, in other words you can speak on channel 3 when the former is applied.

[[User:Marine Kelley|Marine Kelley]] 15:16, 4 April 2009 (UTC)

== @acceptpermission & @denypermission ==

Marine, your blog lists these new commands, but I don't see anything on usage in here. Were they overlooked? --[[User:Teyonas Miklos|Teyonas Miklos]] 07:19, 8 February 2009 (UTC)

By the way, if @acceptpermission would also affect animation permission, that would be awesome! --[[User:Satomi Ahn|Satomi Ahn]] 16:42, 19 February 2009 (UTC)
:Oh it looks like the wiki has been completed now. Thanks Marine. But, may I ask, do @acceptpermission & @denypermission really work for animation permission now? Your blog says it is only for attachements and controls! --[[User:Satomi Ahn|Satomi Ahn]] 11:52, 31 March 2009 (UTC)

::Yes if I remember correctly it only accepts attach and controls permissions... I am really torn on the animation permission because it is automatically accepted if you're sitting on the prim that contains the animation (like furnitures), or wearing it (like restraints) but it proves to be a vulnerability for griefers to exploit. Granted, griefing with weird animations is lame (as is griefing in general), but it is griefing nonetheless. I should see how to accept animation permission requests from prims you are sitting on, regardless of whether they contain the animation or not. That should help for rezzable poseballs at least. [[User:Marine Kelley|Marine Kelley]] 15:13, 4 April 2009 (UTC)

::: Is there a way to start an animation which is not in the prim? In case it is possible it would be interesting to extend the relay protocol to allow this. But I thought this was impossible? Another idea is to explicitly specify the key of the prim that should be allowed to start an animation: <code>@acceptpermission:7adf6218-ab26-8566-8387-660133840794=add</code>. I am not sure if the viewer has this information in the permission query function. The scenario I have in mind is a Star Trek like force-field cell door that will give an electroshock on touch, assuming that the cell has an active relay session. Something else to keep in mind is that there is a pyramid scheme vampire game out there which sees accepting animation permission as accepting to be added to the database. --[[User:Maike Short|Maike Short]] 18:54, 4 April 2009 (UTC)

::: Eh, you actually wrote this, on the wiki: "Force the viewer to automatically accept attach and 'animate' permission requests : @acceptpermission=<rem/add> ". So I guess this is an error. By the way, Kitty might have pointed this to you, but there is actually a way to to get animation permissions by mean of RLV commands, exploiting a loophole in the logic you use for @acceptpermission. Basically, if this behavior is enabled, if you request permission to animate along with either permission to attach or permission to take controls, then you are granted both. --[[User:Satomi Ahn|Satomi Ahn]] 20:35, 14 April 2009 (UTC)

== A shared root... and what about a protected root? ==

I mean, if you are tired to put your tatoos back every time someone strips you... it would be great to be able to protect easily some clothes and attachments (hair, tail, ears,...).
You can already somehow do this for clothes with @remoutfit:xxxx=n, and for prims with @detach=n, but this requires scripting, and very often, you will forget to lock them.

I believe this would be a lot easier if you could have a /#protected folder whose content cannot be force-detached by the mean of rlv commands.
Moreover, it would be even greater if RLV did not report items you are wearing and are in #protected: indeed some scripts will loop until they have successfully detached all they wanted to. If the viewer does not report those items are worn, then those scripts would be happy.

--[[User:Satomi Ahn|Satomi Ahn]] 23:52, 19 February 2009 (UTC)

I like the idea of checking against some kind of viewer-side characteristic of the object, but I'm not sure a folder would do... After all the user could want to protect-unprotect quickly, and moving a large chunk of inventory could reveal to be a hassle. I'll think about it.

[[User:Marine Kelley|Marine Kelley]] 15:09, 4 April 2009 (UTC)

Just a note a posteriori: Kitty Barnett's "nostrip" flag works really well for what I wanted. It would be nice if Marine Kelley's RLV had this feature too. How does it work? Easy: if an item or folder has (nostrip) in its name, then it will be protected against @remoutfit:layer=force or @detach:attachpt=force commands. A lot better than my initial proposal as it is really fine-grained.

--[[User:Satomi Ahn|Satomi Ahn]] 09:31, 27 July 2009 (UTC)

== Third party extension @putinv and the SL permission system ==

In my opinion the SL permission system has a serious) flaw. Objects owned by the land owner do have special rights without a permission dialog:
* manage the ban list
* change the media settings (can be used to get the ip-address of visitors)
* teraform (can be used to destroy the landscape and return rezzed objects to the lost and found folder, thous destroying a lovely place)

While I think it is an issue that SL automatically grants these rights to objects owned by the land lord, I am concerned that the auto-accept and attach might be used to simplify attacks. So if you implement this inofficial extension (the official RLV viewer does not) please add a warning.

PS: Oh, it just occured to me that it can be used to write a self replicating worm that jumps across avatars. This would surely have the potential to get the BDSM community some bad PR. --[[User:Maike Short|Maike Short]] 16:18, 8 April 2009 (UTC)

:Hm there's already a (way too) long discussion about this on the forums.
:Here: http://forums.secondlife.com/showthread.php?t=223796&page=30&pp=15
:And here: http://sldev.free.fr/forum/viewtopic.php?f=7&t=8
:I personnaly don't want to discuss the issue anymore, but I thought I had to point you to this ;-), as I basically share your concerns.
:--[[User:Satomi Ahn|Satomi Ahn]] 20:29, 14 April 2009 (UTC)

== Protecting attachments against detach ==

I'm scripting a gizmo to prevent stripping of tattoos, piercings etc. It would be very useful to have a command similar to the "@remoutfit", but for attachments. That way texture clothing and prim clothing can be treated the same way, instead of having to drop a script into each protected attachment.

My question is: Would it be possible to include commands looking something like this?
* '''''Allow/prevent wearing attachments''''' : @addattach[:<attachpt>]=<y/n>
Where attachpt is :
chest|skull|left shoulder|right shoulder|left hand|right hand|left foot|right foot|spine|
pelvis|mouth|chin|left ear|right ear|left eyeball|right eyeball|nose|r upper arm|r forearm|
l upper arm|l forearm|right hip|r upper leg|r lower leg|left hip|l upper leg|l lower leg|stomach|left pec|
right pec|center 2|top right|top|top left|center|bottom left|bottom|bottom right
* '''''Allow/prevent removing attachments''''' : @remattach[:<attachpt>]=<y/n>
Where attachpt is :
chest|skull|left shoulder|right shoulder|left hand|right hand|left foot|right foot|spine|
pelvis|mouth|chin|left ear|right ear|left eyeball|right eyeball|nose|r upper arm|r forearm|
l upper arm|l forearm|right hip|r upper leg|r lower leg|left hip|l upper leg|l lower leg|stomach|left pec|
right pec|center 2|top right|top|top left|center|bottom left|bottom|bottom right

Or is there already an easy way to do this which I've overlooked? --[[User:Scarlett Flores|Scarlett Flores]] 13:58, 13 July 2009 (UTC)

:There is currently no way to do that in Marine's Viewer, but I can point you to Kitty's nostrip flag [http://rlva.catznip.com/blog/2009/07/feature-nostrip/] which would work well for what you want (currently in Emerald Greenlife Viewer only).
:However there is still a use case for @detach:attachpt=n that cannot be covered by nostrip: for locking an attachement against the wearer's will (but in that case, it is likely the attachment has already been made in the first place for the purpose of being locked, and is scripted with a llOwnerSay("@detach=n")). Still, in my opinion this remains an inconsistency in the current RLV API as @remoutfit:arg can be used both with =n and =force but @detach:arg can only be used with =force...
:--[[User:Satomi Ahn|Satomi Ahn]] 09:39, 27 July 2009 (UTC)

== Loading a preset is laggy, but still better than loading each parameter by script? ==

Loading WL presets is laggy, but is it less laggy than loading all parameters by script? Or would a script doing this not cause lag but just lag itself? --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 21:25, 16 July 2009 (UTC)

== Version Changelog ==

Can we have a little section on the API page that briefly lists the additions and changes? --[[User:Ninjafoo Ng|Ninjafoo Ng]] 07:47, 18 July 2009 (UTC)

== feature suggestion: forcechat and forceIM ==

How about allowing scripts to make ther person say somthing, emote or otherwise? This woudl serve to, among other things, mind control situations, doing emoting without a choice (like flinching when zapped, blushing when groped etc), having a script send voice commands to another script that usually only obeys voice commands fromt he avatar etc

ps: is there a better place to make feature suggestions?

--[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 16:24, 19 July 2009 (UTC)

===force chat level (whisper, talk or shout) ===
the idea is to allow scripts to force the target (usually only the owner can be the target) to have all chat messages be either whisper, regular talk or shout, regardless of what keyboard shortcuts or gui buttons were pressed --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 19:24, 26 July 2009 (UTC)

==Feature Suggestion: No-Fly/Fly zones ==

a command to set a range of altitude where flying is allowed or forbidden, operates on top of @fly, defining a zone where the behavior is the opposite of what @fly defined.

It would also be nice to be able to have both a fly and a no-fly zone defined at once, whatever is defined last will overwrite the other where they overlap (would allow for a zone that has a hole in the middle, a sandwich if you will) --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 19:13, 28 July 2009 (UTC)

== Feature sugestion: @Forcefly ==

This command would force the avatar to start or stop flying, if flying is forbidden by the same object that now is running @Forcefly, the avatar would be unable to change their flying/no flying status --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 19:21, 28 July 2009 (UTC)

== Feature suggestion: @Forcepresskeys ==

This command would result in the client behaving as if the user pressed the keys, including triggering control events in scripts.

The parameter would be a list of key and time pairs (time as integer miliseconds), so a sequence of keypresses can be defined in single command. Zero, or an special keyword would indicate no key being pressed. Perhaps use two different separators, one to indicate the keys afterward must wait the last key to timeout and another to indicate they should start being pressed already.

If possible make all keys avaiable (perhaps except for dangerous ones, like delete, backspace, combinations like alt-F4, control-alt-del (this one isn't as bad as it used to be on Windows, but still better not allow), alt-tab, backspace etc), and for the keypresses must only work inside the client, if another window has focus or somthing, they keys would simply not work, or trigger client behavior event without the client window having focus. --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 19:34, 28 July 2009 (UTC)

== Feature suggestion: @allowpay ==

My goddess brought up a interesting concept of forcing slaves to not being able to spend lindens without the permission of the dom. So my idea is to have a api command to change the status of whether you are allowed to give money or not give money. I may write a patch for it in due time if this function wants to be considered. This would cover all abilities to debit funds from the current balance. [[User:Chibi Pedalo|Chibi Pedalo]] 17:24, 5 August 2009 (UTC)

== Feature Suggestion: force paint ==

(Inspired partially by an idea from a friend of mine)

a command to have the client overlay a texture specified by UUID, over the baked texture, making that the new baked texture, alpha pixels and all

this would allow scripts to make people get dirty, covered in slime sploches, darkyellow semi-transparent stain between the legs implying the person pissed on their pants, bloody gashes across the face etc

there should also be a command to do a clean rebake (a rebake that isntead of being the old rebake, perhaps composited with new textures, would actually do a regular rebake, reading the clothing info and generating the regular baked texture that woudl result form that.

A copy of dirty baked textures would be kept on the client, when a rebake is done, either by the user request or during default functioning of the client, that saved temporary rebake would be what is sent to the server. Having the dirty rebaked textures be saved would allow for cumulative effects, since each time a new texture is applied the results are saved as the baked texture, each new one would be applied to whatever is there already, be it the normal baked texture, or one with dirt on it.

There would also of course be a command to lock/unlock the current (re)baked texture, if it's dirty, prevent a clean rebake, and if it isn't prevent, though better would be separated locks, one for clean rebake, and one for getting any more dirty than how it already is

--[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 05:51, 8 August 2009 (UTC)

== Curious behavior with exceptions and @sendim/@recvim ==

So I was toying with a "Safety" plugin for my toy's collar, something I wrote after she was locked to something and was unable to tell me or get help from me. I just wrote something simple that obtained the collar's owner, then set TP and IM restriction exceptions for that person on the wearer, thus ensuring that the owner would always be able to Teleport the wearer or Send/Receive IMs from them. Initially this worked fine... I thought. Every device we tested restricted everything covered except for SENDING IMs.

When we finally were in a situation where a separate restraint (a gag) restricted her IM sending ability she wasn't able to IM me, despite an IM sending exception being set on her collar. The same gag also restricted her ability to receive IMs, but the exception on the collar allowed me to IM her just fine. The same was true for the teleport lure exception. Bottom line, it seems that ONLY for the @sendIM restriction the exception MUST be set on the same object that sets the overall restriction.

Apparently she is using RLV v1.17 (she said it was based on 1.22.11, so I think that's right), so I don't know if this is something which has been addressed in v1.19. Am I right in assuming this is a glitch? -- [[User:Felis Darwin|Felis Darwin]] 06:06, 20 August 2009 (UTC)

== Feature Suggestion: @logout=force ==

Forces the wearer to log out of SL with a message explaining that such and such item as removed you from SL. Its a interesting idea to make a pet or slave leave SL for various reasons.

== @clear, detachments and locked status ==

If an attachment is not locked, sending @clear when dettaching should still be recommended since in that case the attachment won't be automaticly reattached and the permissions will have to be garbage collected. Only when the attachment is locked that the @clear should be omitted when it is detached --[[User:TigroSpottystripes Katsu|TigroSpottystripes Katsu]] 19:38, 2 October 2009 (UTC)

== Moderate rewrite of Architecture section ==

I just did a moderate rewrite of the Architecture section. The main change was to give preference to the term 'command' instead of 'behavior', because a) the next section is called "List of Commands" and uses that word in the introductory paragraph; and b) not all of these things are behaviors but they are all commands. The other significant change was to just make more effective use of wiki formatting.

I hope that people will consider this an improvement, but I won't be offended by constructive criticism or even reverting to the original text (if accompanied by some reasoning).
[[User:Kidd Krasner|Kidd Krasner]] 14:28, 17 December 2009 (UTC)

----
== Feature suggestion: @getlocked[:attachpt]=<channel_number> ==

A way to see which attachments are locked and not detachable or attachable.
There is, as far as I know, no way yet to see which attachmentpoints are locked.

'''discription:'''

Makes the viewer automatically answer the current lockstatus of attachment points as a list of 0s (unlocked) and 1s (locked) immediately on the chat channel number <channel_number> that the script can listen to. Always use a positive integer. Remember that regular viewers do not answer anything at all so remove the listener after a timeout.

'''The list of 0s and 1s corresponds to :'''
{{Box|none,chest,skull,left shoulder,right shoulder,left hand,right hand,left foot,right foot,spine,
pelvis,mouth,chin,left ear,right ear,left eyeball,right eyeball,nose,r upper arm,r forearm,
l upper arm,l forearm,right hip,r upper leg,r lower leg,left hip,l upper leg,l lower leg,stomach,left pec,
right pec,center 2,top right,top,top left,center,bottom left,bottom,bottom right}}

in that order.

If an attachment point is specified, answers a single 0 (unlocked) or 1 (locked) corresponding to the point.

''A similiar feature would be very usefull for the clothing layers.''

[[User:Misty Wulluf|Misty Wulluf]] 12:37, 17 February 2010 (UTC)

== Possible bug with respect to setdebug for scenegamma and renderresolutiondivisor ==

While ''setenv_scenegamma'' and ''setdebug_renderresolutiondivisor'' could be seen to be useful commands, there is an issue of knowing what to do if multiple objects are issuing them. Right now it appears that the viewer is single-threaded, insofar as the last command entered wins. To make the case specific, assume I am wearing a blindfold that affects my vision using ''setdebug_renderresolutiondivisor'' and then accidentally step into a trap that sends a ''setdebug_renderresolutiondivisor'' change through a relay to my viewer. Now that command overrides the blindfold. On being freed from the trap (either by standing or safewording out from the relay) the value of ''renderresolutiondivisor'' will be set back to 1, thus negating the blindfold. It could be argued that using an appropriate ''@getdebug_renderresolutiondivisor'' before the trap operates, would allow the trap, when the avatar stands, to set the value back to the value it found before it operated. The problem is that if the order is: put on blindfold, sit on trap, take off blindfold, stand up from trap then the trap would set ''renderresolutiondivisor'' to the value as if the blindfold were on.

Note that as a relay developer, I have the same problem, knowing what to do when safeword is called, since I have no obvious value to set for ''renderresolutiondivisor'' or ''scenegamma''. I could set them to 1 and 1.0 respectively, but that is now an escape from other worn attachments. This seems to be something of a problem that it is hard, maybe even impossible to script your way out of, given the global nature of the debug values and the need to respond on a per-object basis.

Should a relay just set the values back to 1.0 for ''scenegamma'' and 1 for ''renderresolutiondivisor''?

--[[User:Chloe1982 Constantine|Chloe1982 Constantine]] 21:06, 23 February 2010 (UTC)

----
== Feature suggestion: @emailsnapshot:<emailaddr>=force ==
This would use the snapshot email feature to send a snapshot to <emailaddr>. This would allow a range of products to be made that can't currently, particularly in conjunction with Shared Media.

Due to privacy and spam concerns, the user should be asked for permission the first time an object tries to send to a specific address. This permission (or rejection) should be kept on a per-object basis in the same way restrictions are (and so cleared when the object is derezed or the user relogs). Something like:

+----------------------------------------------------
|
| May the object 'Shapshot Taker' send
| snapshots to 'test@example.com'?
|
| [Yes] [No]
|
+----------------------------------------------------

It might be desirable to set the resolution, in which case I would propose:

@emailsnapshot:<emailaddr>[;<width>x<height>]

Although it would need to be limited to something reasonable.

I don't think it would be desirable to allow the interface to be included in the snapshot, due to privacy concerns, although perhaps that boat has already sailed.

I would also say that HUD objects should only be shown in the snapshot if the HUD is locked (and so would be forced on for other snapshots).

However, if these were to be configurable, I would propose:

@emailsnapshot:<emailaddr>[;<width>x<height>][;includehud][;includeinterface]

[[User:Winter Seale|Winter Seale]] 00:08, 11 March 2010 (UTC)

Viewer URI Name Space

2009-03-30T18:18:54Z

Winter Seale: Added documentation on /app/chat

{{ProtocolNav}}
aka Viewer URL Namespace

aka SLAPP URLs

aka Application SLURL

[[Category: Name Spaces]]
[[Category: Search]]

The SL client supports links of the format secondlife://Region/123/45/67/, which have traditionally specified a region name and x/y/z location. This means "open Second Life and show Region on the world map".

The new URL scheme has 3 slashes, and allows direct control of the user interface and login. For example, secondlife:///app/login

Most secondlife:///app URLs only work from browser instances running inside Second Life because of a denial-of-service attack using secondlife:///app/teleport links to force repeated teleports. SLURLs that work with external browsers include:
* secondlife://<region name>
* secondlife:///app/login

'''secondlife://'''
* <region_name> ''log in to this region or, if logged in, show information and offer teleport''
** /<local_x> ''optional X position, defaults to 128''
*** /<local_y> ''optional Y position, defaults to 128''
**** /<local_z> ''optional Z position, defaults to 0''

* /app
** /agent
*** /<agent_id>
**** /about ''open agent's profile, with 2nd Life tab selected''
** /login ''log in on launch. External and internal browsers.''
*** see below for query parameters, of course, values are URL escaped
** /event
*** /<event_id>
**** /about ''open floater describing event''
** /group
*** /<group_id>
**** /about ''open floater describing group''
*** /create ''open the create group dialog, added in 1.20''
*** /list
**** /show ''open the list of groups to which user belongs, added in 1.20''
** /parcel
*** /<parcel_id>
**** /about ''open floater describing place''
** /classified
*** /<classified_id>
**** /about ''open floater describing classified''
** /region
*** /<region_id>
**** /about ''information from database about that region? list of parcels? covenant?''
** /teleport
*** /<region_name> ''teleport instantly to this region, no dialog''
**** /<local_x> ''optional X position, defaults to 128''
***** /<local_y> ''optional Y position, defaults to 128''
****** /<local_z> ''optional Z position, defaults to 0''
** /chat
*** /<channel> ''any channel number greater then or equal to 0''
**** /<text>

This could be extended to things like:
* /app/event/<event_id>/subscribe to register for notifications
* /app/parcel/<parcel_id>/teleport to teleport to a specific location
* /app/agent/<agent_id>/im to start IM session

== Login Query Parameters ==
{| border="1"
|-
| first || the account first name
|-
| last || the account last name
|-
| session || the secure session id
|-
| location || login location, format TBD, optional
|}

Talk:LlListen

2009-02-08T19:32:20Z

Winter Seale: /* Performance and Sim impact of llListen */ added a post to the scripters ml from Kelly Linden describing how listens are processed

{{QA
|Q=Has this function to be called in every state?
|A=Yes, it's a feature. [[User:Strife Onizuka|Strife Onizuka]]
}}
{{QA
|Q=How can i send commands in chat that cannot be seen by others?
|A=
{{QA
|Q=By other avatars?
|A=Use any channel other then 0 ([[PUBLIC_CHANNEL]]).
}}
{{QA
|Q=By other scripts?
|A=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.
}}
{{QA
|Q=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
|A=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:

{{QA
|Q=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"?)
|A=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.
}}

{{QA
|Q=similarly, I believe filtering by key means that the ID provided must be that of the speaker; is that correct?
|A=Correct.
}}

{{QA
|Q=is the message filter case-sensitive? for that matter, is the name filter?
|A=The message and name filters are case sensitive; the id filter is not.
}}

{{QA
|Q=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.
|A=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. -- {{User|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. -- [[User:Strife Onizuka|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.