Second Life Wiki - User contributions [en]

Limits

2013-10-30T02:33:16Z

Inusaito Kanya: /* Sound */

<noinclude>{{KBmaster}}</noinclude>
== Summary ==
{{RightToc}}
The Second Life Viewer and simulators have a division of labor, keeping track of the data that makes Second Life run. The Viewer's job is to:

* Handle locations of objects.
* Get velocities and other physics information, and does simple physics to keep track of what is moving where.

The simulator's job is to:

* Run the physics engine.
* Detect collisions.
* Keep track of where everything is
* Send locations of content to the Viewer along with updates when certain changes occur.

Limits are necessary for all of these components to work together. The list below outlines many of the '''Second Life numerical limits that affect your inworld experience'''. Some of these will likely change over time, so if you spot something incorrect/outdated, please take a moment to update it.

{{KBcaution|1=The scope of this page is focused on Linden Lab's official Viewers, keeping in mind [[Third_Party_Viewer_Directory|3rd-party viewers may differ]]. Cite sources and provide substantiation for limits that aren't provided by Linden Lab. Also, unconfirmed speculation [[Talk:Limits|goes on this discussion page]]. Don't add data without a hard limit, and don't add obscure trivia that doesn't practically affect the general inworld experience.|width=80%}}

== [[Avatar]] ==

* '''Max. # of attachments''' - 38 combined [[HUD]] or body attachments.
** They can be viewed by right-clicking your avatar and choosing '''Take Off''' > '''HUD''' or '''Detach'''.
** With the formal introduction of [[multiple attachments|multiple attachments to a single point]] in Viewer 2.4, you can attach up to 38 total objects, and they can all be attached to a single point.
* '''Max. # of clothing layers per slot''' - 5 (this includes alpha and Tattoo Layers)
* '''Max Clothing Texture''' - 512x512px - Server Side Appearance will downsize larger textures. 
* '''Max. unassisted fly height''' - Stable hover at 5064m.
** You can easily acquire a flight attachment to fly high. Also see [[flight limit]] and [[Limits#Navigation|the Navigation section]] below.
* '''Common shoe sizes''' - Most women's shoes are designed for a size 0 (zero) foot. Men's generally scale up to 14.
** You can check this by going to Edit menu > Appearance and clicking on the Shape > Legs tab.

* '''Max. length of avatar name''' - 31 for first name, 31 for last name, 63 in total (including the space).

* '''Max. length of {{LSLGC|Username}}''' - All lower case and a maximum of 63 including the '.'(eg; firstname.lastname)
**Older account user names are a combination of the First and last name in lower case separated by a period(.)(eg; lilmix.pixelmaid)
**Modern user names are a single name(no period)(eg; john1234) - '''Max.''' length is 31 characters
**The {{LSLGC|Legacy Name}}s for modern user names always shows Resident as the last name. So the Max is 40 characters in total for a new avatar's legacy name(including the space and last name 'Resident')
*'''Min. length of [[Display_Names]]''' - At least one script character
*'''Max. length of Display Names''' - 31 characters
**Display Names can include most Unicode script characters, spaces, and some punctuation.

* '''Max. avatar speed''' - 250m/s (with only attachments to assist)
* '''Max. teleport speed'''
** '''Server 1.27.1''' - 10 teleports per 15 seconds
** '''Server 1.27.0''' - 3 teleports per 15 seconds

== [[Animation]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Category'''
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||[[Animation]]
||Length of animation
| n/a
| {{no|60.0 seconds}}
| Limited by length or Size, whichever is reached first
| n/a
|-
||[[Animation]]
||Size of Animation
| n/a
| {{no|120k bytes}}
| Limited by length or Size, whichever is reached first
| n/a

|-
||[[Animation]]
||animation priority
| {{no|0}}
| {{no|4, with custom tools 5}}
| n/a
| [[Animation_Priority]]
|-
||[[Animation]]
||Number of unique joints per animation
| n/a
| {{no|32}}
| n/a
| n/a
|}

== Building ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Category'''
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||'''BUILDING'''
||[[Prim]] dimensions
| {{no|<0.01, 0.01, 0.01>}}
| {{no|<64.0, 64.0, 64.0>}}
| Used to be <10.0, 10.0, 10.0> prior to Second Life Server version 11.08.17.238770
| [[llSetScale]] and [[PRIM_SIZE]] and [[Megaprim]]
|-
||'''BUILDING'''
||Number of prims in a linkset
| n/a
| {{no|256 prims}}
| Used to be 255 prior to Second Life Server version 1.26
| n/a
|-
||'''BUILDING'''
||Linking distance
| n/a
| {{no|[[Linkability_Rules]]}}
| n/a
| n/a
|-
||'''BUILDING'''
||Physics weight for a physical object
| n/a
| {{no|32.0}}
||Additional notes:
* If you try to link more, it'll either say "Can't enable physics for objects with more than 32 primitives" or "Object has too many primitives -- its dynamics have been disabled.".
* On server versions 1.38 and below, each sitting avatar counted as 1 prim. From 1.40.2 the limit is only on actual prims.
| n/a
|-
||'''BUILDING'''
||Build or rez height
| n/a
| {{no|4096.0 meters}}
| 768.0 meters for Viewers prior to version 1.20
| n/a
|-
||'''BUILDING'''
||Prim name length
| n/a
| {{no|63 bytes UTF-8 [[String|string]]}}
| same limit for {{LSLGC|Avatar/Name|avatar names}}, although the character set for avatar names is significantly limited.
| n/a
|-
||'''BUILDING'''
||Prim description length
| n/a
| {{no|127 bytes UTF-8 [[String|string]]}}
| n/a
| n/a
|-
||'''BUILDING'''
||Temporary prims' lifetime
| n/a
| {{no|up to around 60 seconds}}
| depends upon when the next garbage collector cycle is
| n/a
|-
||'''BUILDING'''
||Number of temporary prims
| n/a
| {{no|RegionPrimLimit - NumberOfPrimsInRegion + Minimum(0.5*RegionPrimLimit, 1000)}}
| n/a
| n/a
|-
||'''BUILDING'''
||Length of hovertext
| n/a
| {{no|254 bytes UTF-8 [[String|string]]}}
| n/a
| [[llSetText]] and [[PRIM_TEXT]]
|}

== [[Communication]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Category'''
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||[[Communication]]
||Whisper distance
| n/a
| {{no|10 meters}}
| <code>/whisper</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||[[Communication]]
||Chat distance
| n/a
| {{no|20 meters}}
| text spoken as a "chat" step '''within gestures''' cannot be shouted or whispered.
| n/a
|-
||[[Communication]]
||Shout distance
| n/a
| {{no|100 meters}}
| <code>/shout</code> as the first few characters in a message can be used in viewer-2-code based viewers in local chat.
| n/a
|-
||[[Communication]]
||Length of a chat message and whether or not it is truncated
| {{no|1 byte or single-byte character}}
| {{no|1024 bytes or single-byte characters}}
| Limit does not apply to instant messages via [[llInstantMessage]] and communication between IM and email, the limit there is 1180 bytes or single-byte characters. This is true as of 2012-08-13.
| [[llInstantMessage]]
|-
||[[Communication]]
||Number of offline messages
| n/a
| {{no|Capped at 25 messages.}}
| Number of offline messages (involving [[IM|IMs]], inventory offers, group notices, group invitations) received before messages get capped.
| [[IM]]
|-
||[[Communication]]
||Length of a properly delivered email reply to an [[IM]]
| n/a
| {{no|1023 bytes or single-byte characters}}
| n/a
| n/a
|-
||[[Communication]]
||Time after which a reply to an [[IM]] can be sent via email.
| {{no|when receiving the IM via email.}}
| {{no|5 days after receiving the offline IM via email.}}
| n/a
| [https://blogs.secondlife.com/community/features/blog/2007/02/06/im-to-e-mail-return-addresses-changing Second Life Blogs]
|-
||[[Communication]]
||Time period for which [[IM|IMs]] are stored within Second Life.
| n/a
| {{no|31 days after receiving the [[IM]]}}
| [[User:Torley_Linden|Torley Linden]] confirmed this with [[User:Kelly_Linden|Kelly Linden]]
| n/a
|-
||[[Communication]]
||Number of [[IM|IMs]] sent by an object within an hour
| n/a
| {{no|5000 per hour}}
| n/a
| n/a
|}

== [[Gesture]]s ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Category'''
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||[[Gesture]]
||Shortcut key mappings
| n/a
| {{no|33 unique combinations, since {{K|F2}}–{{K|F12}} can be used with the {{K|Ctrl}} or {{K|Shift}} modifiers.}}
| n/a
| [[All_keyboard_shortcut_keys]] and [[Viewer_2_Quick_Start_Guide/Appendix_-_Keyboard_Shortcuts]]
|-
||[[Gesture]]
||Chat step length
| n/a
| {{no|127 bytes or single-byte characters}}
| n/a
| n/a
|-
||[[Gesture]]
||Wait time
| n/a
| {{no|3600 seconds (which is one hour)}}
| n/a
| n/a
|}

== [[Group]]s ==

* '''Maximum number of groups you can belong to:''' 42
** Roles within groups are sort of like sub-groups. In many cases, you can use them instead of creating new groups.
* '''Minimum number of members in a group:''' 2
** A group with only 1 person for 48 hours will be disbanded (cancelled). Unless the group owns land.
* '''Maximum number of roles allowed in a group:''' 10 (including "Owners" and "Everyone", which cannot be deleted)
* '''Maximum Group Name:''' 35 single-byte characters.
* '''Maximum Group Title:''' 20 single-byte characters.
* '''Maximum Length of a Group Notice:''' 512 single-byte characters.

== [[Inventory]] ==

* '''Maximum number of inventory items that can be sent in a folder:''' 42
** Folders count as items too. This has more to do with packet size limits than cheeky Douglas Adams references.
* '''Maximum number of inventory items that can be contained in a prim:''' None, but more items increase the loading time when you open it.
* '''Maximum characters in an inventory item name:''' 63
* '''Maximum notecard line:''' None, but scripts can only read the first 255 bytes.
* '''Maximum notecard size:''' 65,536 bytes
* '''Number of items in the Library:''' 1,248 as of 2010-06-17
* '''Number of items in the Library:''' 2,210 as of 2012-11-04
** Verified by [[How_does_the_Library_work|hiding the Library]] and counting the difference.
* '''Maximum number of inventory items Displayed in an Inventory Folder:''' Approximately 10,000.
** This was discussed during [http://wiki.secondlife.com/wiki/Simulator_User_Group/Transcripts/2011.03.08] "the folder will load up to the limit number of items, and remaining ones won't show up in the viewer. you still own them, they aren't lost, but they will be hidden until the folder size is reduced."

== [[Land]] ==

* '''Maximum [[Land#Parcel|parcel]] size:''' 65,536 meters²
** Covering a whole region, or square on the World Map.
* '''Minimum parcel size:''' 16 meters²
* '''Maximum parcel name length:''' 63 single-byte characters
* '''Maximum parcel description length:''' 255 characters
* '''Region name length:''' Under Linden Concierge policy, minimum of 3 characters, and a maximum of 25 characters (including spaces). See [[Linden Lab Official:Guidelines for Private Region Naming|Guidelines for Private Region Naming]].
** Rare exceptions exist, like [http://slurl.com/secondlife/Q/128/128/24 Q].
* '''Maximum "NO ENTRY" ban line height:''' is for all options 80 meter. Only the option 'Banned Residents' (named) has a 5020 meter ban line high, which is visible up to a high of 800 meter above the terrain mesh.
* '''Maximum prims in a [[Land#Region|region]]:'''
** Full region: 15,000
** [[Land#Homestead|Homestead]]: 3,750
** [[Land#Openspace|Openspace]]: 750
* '''Maximum auto return value''': Besides "0" (which means ''never''), {{HoverText|999,999|Almost 23 months}} minutes is the highest auto return value.
* '''Terraforming limits:'''
** Most mainland can be raised/lowered by 4 meters (+/-).
** Some mainland cannot be terraformed, including: Bay City Regions, Blumfield, Boardman, Brown, De Haro, Nautilus City Regions, Nova Albion Regions, Shermerville Regions, and West Haven.
** A few, very old mainland Regions like Da Boom have a terraform range of 40 meters (+/-).
** Estate (private island) terraformability is settable to a maximum of 100 meters (+/-) by the estate owner or managers.
* '''Maximum water height:''' 100 meters using inworld controls (mainland limit), 255 meters by using a *.raw file upload.
** Region water height is usually 20 meters, and adjacent regions should have the same water height, or else they will look discontinuous.
* '''Maximum terrain height:''' 255 meters using inworld controls (mainland limit), 510 meters by using a *.raw file upload.
* '''Miscellaneous estate limits:''' You can have a maximum of 10 estate managers, 500 allowed Residents, 63 allowed groups, and 500 banned Residents.
** See World menu > Region/Estate > Estate tab.
* '''Mainland maximum number of agents'''
** Full region: 100 (Historically set to 40 by LL but this does vary. Some meeting areas have this set to 60 and higher.)
*** Recent server performance improvements make regions with 60 agents in them perform quite well.
** [[Land#Homestead|Homestead]]: 20
** [[Land#Openspace|Openspace]]: 10
* '''Island maximum number of agents:'''
** Full region: 100
** [[Land#Homestead|Homestead]]: 20
** [[Land#Openspace|Openspace]]: 10
* '''Freeze Time:''' Land owners can [[freeze]] other Residents for up to 30 seconds. Members of land owning groups can also be granted this ability.
* '''Minimum parcel that can be listed in Places or All search:''' 144 meters² 
* '''Minimum parcel that can be listed in Events:''' 512 meters²
* '''Maximum altitude for event listings:''' 768 meters ({{JIRA|WEB-814}})
* '''Maximum heights that objects can be seen on the [[World Map]]:''' 400.005m
* '''[[Classic clouds]] layer:''' Approximately 150-225 meters, although the edges of particles can appear to exceed that.

== [[Mesh]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Category'''
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||[[Mesh]]
||Number of vertices
| n/a
| {{no|65536 vertices per LOD for each [[mesh]]}}
| n/a
| n/a
|-
||[[Mesh]]
||COLLADA file size
| n/a
| {{no|Maximum mesh asset size after compression is 8 MB, roughly equivalent to a 256 MB Raw COLLADA file.}}
| n/a
| n/a
|-
||[[Mesh]]
||Bone influence weights per vertex
| n/a
| {{no|4}}
| n/a
| n/a
|-
||[[Mesh]]
||Number of materials per mesh
| n/a
| {{no|8}}
| n/a
| n/a
|-
||[[Mesh]]
||Number of materials per face
| n/a
| {{no|1}}
| n/a
| n/a
|-
||[[Mesh]]
||Physics weight for a vehicle
| n/a
| {{no|32.0}}
| n/a
| n/a
|}

===User Found Temporary Mesh limits:===
''Because of an apparent bug in the importer stay within these limits.''
* 174,752 triangles, beyond which additional triangles will appear as holes.
* The 64k vertices per material is pre-empted by a limit of 21,844 triangles per material, which is presently reported as a bug. (2/2013)

:: The import process will continue making new materials beyond 8 x 21,844 (=174,752) triangles, but the extra triangles then get dropped by the limitation to 8 materials, causing holes in the resulting object. Over the 21,844 triangle limit, the vertex count will start to climb steeply, even with smooth shading, because the materials get highly interspersed. So the same vertices have to appear in multiple material lists. So the moral of the story is to stay below 21,844 triangles per material, for now, if you want to avoid some unexpected effects.

== Misc. ==

*'''[https://secondlife.com/currency/describe-limits.php Billing and Trading Limits]''' - Includes [https://secondlife.com/whatis/economy-market.php LindeX] currency exchange limits.
*'''Contacts in Communication > Friends tab ''' - A maximum of 20 simultaneous contacts can be selected to change permissions, remove, or invite for a conference chat.

== Navigation ==

[[File:Max Alt.jpg|thumb|right|435px|'''Height counter error above 2147483647 meters''']]
* '''Absolute height limit:''' [http://en.wikipedia.org/wiki/2147483647#2147483647_in_computing 2147483647] = 2<sup>31</sup> − 1 meters, which causes the altitude counter to roll over. Altitudes well below this cause graphics errors probably due to limited floating point number precision.
* '''Highest z-value of an [[SLurl]], that will still teleport you to a positive altitude:''' 2147483583
** This is lower than the ''Absolute height limit'' above probably because of precision issues. Any value higher than 2147483583 would be rounded up to something beyond 2147483647 and thus cause an [http://en.wikipedia.org/wiki/Arithmetic_overflow overflow], while 2147483583 will still be rounded down to 2147483520 (see below).
* '''Highest altitude you can teleport to with an SLurl:''' 2147483520 meters

== [[Profile]] ==

Each 7-bit ASCII character is encoded in one byte. International characters might need more bytes. When pasting text instead of typing, you can get in one byte more into each of the below.

* '''2nd Life tab's About field''' - 510 bytes
* '''Picks tab''' - 10 picks with 1022 bytes each
* '''1st Life tab's Info field''' - 253 bytes
* '''Classified tab''' - 100 listings with x bytes each
* '''My Notes''' - 1022 bytes

== Performance ==

* '''Healthy Viewer FPS''' - Generally, FPS above 15 is good. The higher it gets, the smoother. You can check via Help menu > Lag Meter, or for more advanced usage, see View menu > Statistics Bar.
* '''Avatar Rendering Cost scores''' - [[Avatar Rendering Cost|Learn all about it!]]

== [[Scripting]] ==

* '''Height at which scripts reactivate on a no-script parcel''' - 50 m above terrain mesh. Scripted objects that take controls continue to remain active when you fly down or enter a no-script parcel.
* '''Maximum height where scripts can run''' - none, as long as the object remains rezzed or attached.
* '''Maximum script source code size''' - 65536 single byte characters (that's a viewer limit and can be changed in the config file 'panel_script_ed.xml').
* '''Maximum script memory size (LSO)''' - 16384 bytes.
* '''Maximum script memory size (Mono)''' - 65536 bytes (the memory size of Mono scripts can be reduced with [[LlSetMemoryLimit]]).
* '''Maximum activ listener per script''' - 65.
** '''Usable channel for each listener''' - ''min.'' -2147483648, ''max.'' 2147483647, ''local chat'' 0 ''and'' [[DEBUG_CHANNEL]].
* For specific scripting limits, lookup calls in the '''[[LSL Portal]]'''.

== [[Sound]] ==

{| class="sortable" width="100%" {{Prettytable}}
|- {{Hl2}}
! '''Category'''
! '''Limit affects'''
! '''Lower limit'''
! '''Upper limit'''
! '''Comment'''
! '''More coverage'''
|-
||[[Sound]]
||Sound length
| n/a
| {{no|10.0 seconds}}
| You're advised to cut longer sounds into 9.9-second-pieces.
| n/a
|}

== [[Textures]] ==
* '''[http://en.wikipedia.org/wiki/Aspect_ratio Aspect ratios]''' of profile, place, etc. pictures — all of these were measured at UI size (Edit menu > Preferences > General tab > UI Size) = 1.000:

=== 1.x Series Viewers ===

(official Viewer up to 1.23.5, most [[Alternate viewers|Third Party Viewers]])
* '''Search > All for "Classifieds", "People", and "Places"''' - 4:3 (256×192 pi×els)
* '''Search > Places and Classified tabs''' - ~7:5 (398×282 pixels)
* '''Search > Land tab''' - ~7:5 (358×252 pixels)
* '''Profile > 2nd Life tab''' - ~4:3 (178×133 pixels)
* '''Profile > Picks tab''' - 16:9 (288×162 pixels)
* '''Profile > 1st Life tab''' - 1:1 (133×133 pixels)
* '''Profile > Classifieds tab''' - ~3:2 (206×137 pixels)
* '''Profile > Web tab''' - 1:1 (400×400 pixels)
** A scrollbar uses 15 pixels on the right-hand side.
* '''About Land > Options tab''' - ~3:2 (178×117 pixels)
* '''Group Information > General tab's "Group Insignia"''' - 1:1 (126×126 pixels)
** Some of these textures are shared (for example, Search > All place pages, Search > Places, and About Land > Options use the same image), so you should pick a well-balanced ratio and size.
** [[Texture_aspect_ratios|Learn how to get correct texture aspect ratios when editing images.]]

=== 2.x Series Viewers ===

* '''Search > Classifieds thumbnail''' - 4:3 (60×45 pixels)
* '''Search > Classifieds expanded''' - ~4:3 (252×188 pixels)
* '''Search > Classifieds expanded > Details''' - 17:7 (272×112 pixels)
* '''Search > People''' - 4:3 (188×141 pixels)
* '''Search > Destination Guide thumbnail''' - ~4:3 (45×34 pixels)
* '''Search > Destination Guide expanded''' - 5:3 (250×150 pixels)
* '''Profile > 2nd Life tab''' - ~1:1 (100×99 pixels)
* '''Profile > Picks thumbnail''' - 8:5 (88×55 pixels)
* '''Profile > Pick expanded''' - ~5:3 (285×172 pixels)
* '''About Land > Options tab''' - ~20:13 (193×125 pixels)
* '''Places > More information''' - ~11:7 (272×173 pixels)

=== All Viewers ===

* '''Maximum texture size''' - 1024×1024 pixels
** All Second Life textures are constrained to [http://en.wikipedia.org/wiki/Power_of_2 powers of 2] (e.g., 128, 256, 512).
** Some textures inworld have a resolution as high as 2048×2048; this is due to a previous limit that was higher.
** We strongly recommend you use as small textures as possible because larger ones consume more memory and take substantially longer to load.
** Where large textures are being forced by import to only 512×512, lower your ...> Preferences >...> UI Size under 1.0, to increase import size to the max 1024×1024.

[[Category:Creation]] [[Category:Tutorials]] [[Category:Lists]]

=== Notes ===
In general 1 byte is enough to contain one character.

Viewer 2 Microsoft Windows Builds

2012-07-17T23:47:56Z

Inusaito Kanya: Make the top of the page look more proper

{{multi-lang}}

Philosophy: to keep it brief, this page should only include steps we KNOW ARE NEEDED, not random hints. Extra details or open issues can go on the talk page.

{{KBnote|Following this recipe will probably take 6 to 12 hours of wall-clock time, and 2 to 6 hours of your time, if you're starting from a fresh Windows XP/Vista/7 system.}}

{{KBcaution|If you want alter the build instructions please try to have a discussion with at least one person on [irc://irc.freenode.net/opensl #opensl on Freenode]. There are language and stylistic conventions we try to follow and we want to make sure any change to these instructions is tested in a number of build environments before being published here.}}
{{CompileNav}}

== Establish your programming environment ==

This is needed for compiling any viewer based on the LL open source code and only needs to be done once.

=== Install and update Visual Studio and SDKs ===

*Install [http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express Visual C++ 2010 Express] (Web install) or [http://go.microsoft.com/?linkid=9709969 Visual C++ 2010 Express] (ISO)
*Install [http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84&displaylang=en Microsoft Visual C++ 2010 Redistributable Package]
*Install [http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6B6C21D2-2006-4AFA-9702-529FA782D63B Windows SDK for Windows 7 and .NET Framework 4] (Web install) [Note: uncheck the Redistributable Package option to prevent installation failure] or [http://www.microsoft.com/downloads/en/details.aspx?FamilyID=35aeda01-421d-4ba5-b44b-543dc8c33a20 Windows SDK for Windows 7 and .NET Framework 4] (ISO)
*Install [http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=3021d52b-514e-41d3-ad02-438a3ba730ba DirectX SDK (June 2010)]
*Run [http://www.update.microsoft.com/microsoftupdate/v6 Microsoft Update], and keep running it until no updates are needed. This may take 6~8 iterations on older versions of windows.
** For Windows Vista and Windows 7, you need to select "Get updates from other Microsoft products" to get the updates for Visual Studio.
** For Windows XP, use the provided link above. The Windows Update menu item on your computer is not the correct updater to use.
** During the update cycles make sure you have picked up [http://www.microsoft.com/downloads/en/confirmation.aspx?FamilyID=75568aa6-8107-475d-948a-ef22627e57a5 Microsoft Visual Studio 2010 Service Pack 1] (Web install) or [http://go.microsoft.com/fwlink/?LinkId=210710 Microsoft Visual Studio 2010 Service Pack 1] (ISO)
*If you are running VS2010 under anything older than Windows 7, then you might need to install the "Windows Automation" library to avoid seeing VS2010's UI crawl like a tortoise. [http://support.microsoft.com/kb/981741 Here is the relevant MS support article].

=== Install required development tools ===

{{KBnote|The order of the following installations should not matter.}}
{{KBnote|If the installer for a particular package does not update your PATH environment variable you will have to do this manually.}}

* '''CMake''' ([http://www.cmake.org/HTML/Download.html download CMake])
** This should be version 2.8.4 (or above in the 2.8.x series).
**Add the <code>\bin</code> directory to your path.
* '''Python''' (either [http://www.python.org/download/ Standard Python] or [http://www.activestate.com/activepython/downloads ActivePython])
** Version 2.7.1 works with the build scripts.
* '''Mercurial''' (either [http://tortoisehg.bitbucket.org/ TortoiseHg] or [http://mercurial.selenic.com/ Mercurial Hg])
**Create a new file <code>%USERPROFILE%\Mercurial.ini</code> and in it put your Second Life name and optionally your email address:
[ui]
username = John Doe <john@example.com>
* '''Cygwin''' ([http://www.cygwin.com/ download Cygwin])
** When you run the cygwin setup utility make sure you have selected to install '''unzip''' (under "Archives"), '''bison''', '''flex''', '''patchutils''' (all located under "devel"), and '''curl''' (under "Web"), which are not part of the default install. Do not install Cygwin Python or Mercurial. You won't need to use the Cygwin shell for anything.
**Add the <code>cygwin\bin</code> directory to the '''very end''' of your path and make sure it stays that way.

=== Install optional development tools ===

* [http://code.google.com/p/unsis/downloads/list Unicode NSIS (Nullsoft Scriptable Install System)]
** This is the package installer used to build <code>Second_Life_<version-code>_LindenDeveloper_Setup.exe</code>. You only need this package if you are going to distribute the viewer you compile or if you want to install it locally.
*: In the [[#Configuring_the_Viewer|Configure VS2010 step]] below you will need to add a line in the '''Executable Directories''' section:
*:* 64 bit systems use <code>%ProgramFiles(x86)%\NSIS\Unicode</code>
*:* 32 bit systems use <code>%ProgramFiles%\NSIS\Unicode</code>
* [http://notepadplusplus.org/ Notepad++]
** You need to use an editor that conforms to the [[Coding Standard]]. In particular, you must not check in files with DOS line endings except in very limited circumstances; see [[How to avoid DOS line endings in Windows tools]].
* [[Mercurial_Tools]] (strongly recommended)
** When you are following these instructions you will be updating the <code>%USERPROFILE%\Mercurial.ini</code> file you created when you installed Mercurial.

=== Install Autobuild ===
* Follow the directions at [[Autobuild#Getting_Autobuild|Getting Autobuild]] to install Autobuild.

* Add an environment variable, so that autobuild doesn't default to using (or trying) older compiler versions:
** Right-click "My Computer" and select '''Properties''' or press the windows logo key and the pause key at the same time.
** For XP, when the Properties dialog opens, click the '''Advanced''' tab followed by the '''Environmental Variables''' button. This will open a new window with a list of System and User variables. For Vista and later, when the System Properties window opens, click the '''Advanced system settings''' on the left column, then click '''Environment Variables...'''
** In the User section, click '''New'''. Set '''Variable Name''' to AUTOBUILD_VSVER and set '''Variable Value''' to 100.
** Click the OK/Close buttons to close all the windows.

=== Configure VC2010 ===
While you may choose to use autobuild for all your compiling you still need to establish certain settings internal to VC2010.

*Start the IDE.

*Navigate to '''Tools''' > '''Options''' > '''Projects and Solutions''' > '''Build and Run''' and set '''maximum number of parallel projects builds''' to <code>1</code>.
*(VC Express only) Enable Tools > Settings > Expert Settings to get the Build (and other) menus. If you already have a '''Build''' menu you do not need to perform this step.

{{KBnote|The following steps require an open visual studio project. It does not matter which project you use, as you will only change some global settings used by all projects when they are opened. The open project itself won't be changed.}}

You will need to set a number of paths.
* Open any existing project you may have or make a New Project.

* Navigate to '''View''' ( > '''Other Windows''' ) > '''Property Manager'''. You will see Property Manager as a pane on the left side.

At the bottom on the Solution Explorer you will see three tabs.

*Click the one on the right labeled '''Property Manager'''. (The name may be somewhat truncated.)

[[File:VS2010_Property_Manager.PNG|100px]]
[[:File:VS2010_Property_Manager.PNG|Example image]]

*On the left side click to expand any project and then click again to expand the '''Release''' folder.

[[File:VS2010_Project_Config.PNG|100px]]
[[:File:VS2010_Project_Config.PNG|Example image]]

*Right click on '''Microsoft.Cpp.Win32.user'''.

*Pick '''General'''
Set '''Enable Managed Incremental Build''' to <code>Yes</code>.

*Pick '''VC++ Directories'''.

This is where the build environment is pulled together into a functional VC2010 build system and also where much hand wringing, hair pulling, and fist pounding frustration takes place.

*Set '''Executable Directories''' to:

$(ExecutablePath)
$(DXSDK_DIR)
$(WindowsSdkDir)\Bin
C:\cygwin\bin
$(SystemRoot)

[[File:32BitExecutableDirectories.png|100px]]
[[:File:32BitExecutableDirectories.png|32 bit Executable Directories example image]]

*Set '''Include Directories''' to:

$(WindowsSdkDir)\Include
$(WindowsSdkDir)\Include\gl
$(DXSDK_DIR)\Include

[[File:32BitIncludeDirectories.png|100px]]
[[:File:32BitIncludeDirectories.png|32 bit Include Directories example image]]

*Set '''Library Directories''' to:

$(WindowsSdkDir)\Lib
$(DXSDK_DIR)

[[File:32BitLibraryDirectories.png|100px]]
[[:File:32BitLibraryDirectories.png|32 bit Library Directories example image]]

== Set up your source code tree ==

Plan your directory structure ahead of time. If you are going to be producing changes or patches you will be cloning a copy of an unaltered source code tree for every change or patch you make, so you might want to have all this work stored in it's own directory.

To get a copy of the source code tree:
* Open up a DOS Command window
* CD to where you want to install viewer-release. Do not have any spaces in this path.
* Do:
hg clone <nowiki>http://hg.secondlife.com/viewer-release</nowiki>

Let's say some time has gone by since you have performed the previous steps and now you want to develop a change or work on a jira. You will update your clean local repository with all the changes committed to viewer-release since you last synchronized your files:
* CD into <code>viewer-release</code>
* Do:
hg pull -u

* Move up one level from <code>viewer-release</code>
* Do:
hg clone viewer-release VWR-nnnnn
Note: <code>nnnnn</code> is the jira number. You can also clone to a name of your choosing if you are making changes not associated with the LL jira system.

== Prepare third party libraries ==
Most third party libraries needed to build the viewer will be automatically downloaded for you and installed into the build directory within your source tree during the [[#Configuring_the_Viewer|configuration step]] below. Some few need to be manually set up, though, when using an open source developer configuration (<code>Release'''OS'''</code>, <code>RelWithDebInfo'''OS'''</code> or <code>Debug'''OS'''</code>)

=== Fmod ===

{{KBcaution|If you are just starting out building the viewer or if you do not care for sound skip these FMOD steps. You will save some time and it is less confusing to make a non-FMOD build.}}

CD to where you want to install the 3p-fmod repository and do:
hg clone <nowiki>https://bitbucket.org/lindenlab/3p-fmod</nowiki>

CD into the <code>3p-fmod</code> directory you created and build it:
autobuild build --all

'''If the above command fails, you might have the version of bash packaged with Git in your PATH.''' Please edit your path and ensure that the Git path (e.g 'C:\Program Files (x86)\Git\cmd'), if it exists, appears AFTER 'c:\cygwin\bin'.

Package the results:
autobuild package

Update autobuild with the filename and hash just displayed. CD to the directory where you cloned viewer-release and do:

copy autobuild.xml my_autobuild.xml
set AUTOBUILD_CONFIG_FILE=my_autobuild.xml
autobuild installables edit fmod platform=windows hash=<hash> url=file:///<fmod-filespec>

Example:

copy autobuild.xml my_autobuild.xml
autobuild installables edit fmod platform=windows hash=0f196f00e7dff49f22252efb68525658 url=file:///C:/3p-fmod/fmod-3.75-windows-20110531.tar.bz2

{{KBnote|Having to copy <code>autobuild.xml</code> and modify the copy from within a cloned repository is a lot of work for every repository you make, but this is the only way to guarantee you pick up upstream changes to <code>autobuild.xml</code> and do not send up a modified <code>autobuild.xml</code> when you do an hg push.}}

== Configuring the Viewer Build ==

Fmod is the audio library the viewer uses. If you are compiling with Fmod you will need to do:

set AUTOBUILD_CONFIG_FILE=my_autobuild.xml

The environment variable <nowiki>AUTOBUILD_INSTALLABLE_CACHE</nowiki> controls the placement of library files downloaded as part of the configure process. If you do not want the library files downloaded as part of the configure process going into your Windows <nowiki>%TEMP%</nowiki> directory define the environment variable to point to some other location you have established:

set AUTOBUILD_INSTALLABLE_CACHE=E:\SSfiles\Libraries

At the command line in the source tree's root directory, presumably in your cloned repository (e.g. <nowiki>C:\linden\VWR-12345\</nowiki>)

If you did not configure for FMOD:
autobuild configure -c [CONFIGURATION]

If you did configure for FMOD:
autobuild configure --config-file my_autobuild.xml -c [CONFIGURATION] -- -DFMOD:BOOL=TRUE

where <code>[CONFIGURATION]</code> is one of those listed at [[Building the Viewer with Autobuild#Build a desired configuration]] (<code>ReleaseOS</code>, <code>RelWithDebInfoOS</code>, <code>DebugOS</code>)

=== Configuration Switches ===
There are a number of switches you can use to modify the configuration process. The name of each switch is followed by its type and then by the value you want to set.

* '''FMOD''' (bool) controls if the Fmod package is incorporated into the viewer. You must have performed the Fmod installation steps in [[Viewer_2_Microsoft_Windows_Builds#Fmod]] for this to work.
* '''LL_TESTS''' (bool) controls if the tests are compiled and run. There are quite a lot of them so excluding them is recommended unless you have some reason to need one or more of them.
* '''PACKAGE''' (bool) controls if the package step is run. You must have installed NSIS described in [[Viewer_2_Microsoft_Windows_Builds#Install_optional_development_tools]] for this to work.

{{KBnote|'''OFF''' and '''NO''' are the same as '''FALSE'''; anything else is considered to be '''TRUE'''.}}

Example without FMOD:
autobuild configure -c ReleaseOS -- -DLL_TESTS:BOOL=FALSE -DPACKAGE:BOOL=FALSE

Example with FMOD:
autobuild configure --config-file my_autobuild.xml -c ReleaseOS -- -DLL_TESTS:BOOL=FALSE -DPACKAGE:BOOL=FALSE -DFMOD:BOOL=TRUE

== Compiling the Viewer ==

{{KBnote|Do not be alarmed if you see groups of messages with '''warning LNK4099: PDB''' in them.}}

=== Compiling the viewer with autobuild ===
You can compile the viewer with either autobuild (the encouraged/supported method) or with the VS IDE.

When compiling with autobuild you will have the best chance of success if you work from within a preconfigured Command Prompt window. Depending on how your computer has been set up there are two possible ways to open this window and you need to find which works in your particular case:
*Method 1
**From '''All Programs''' Navigate into the '''Microsoft Visual Studio 2010''' program menu
**Click on '''Microsoft Visual Studio Command Prompt (2010)'''

*Method 2
**From '''All Programs''' Navigate into the '''Microsoft Windows SDK V7.1''' program menu
**Click on '''Windows SDK 7.1 Command Prompt'''

{{KBcaution|If you are building with Fmod and have followed the previous Fmod setup instructions AND you are now using a new command window you will need to redo the <code>set AUTOBUILD_CONFIG_FILE{{=}}my_autobuild.xml</code>.}}

*Run:

Without FMOD:
autobuild build -c [CONFIGURATION] --no-configure

With FMOD:
autobuild build --config-file my_autobuild.xml -c [CONFIGURATION] --no-configure

There are some useful switches to know about, so your commands may look like this:

Example without FMOD:
autobuild configure -c ReleaseOS -- -DLL_TESTS:BOOL=FALSE -DPACKAGE:BOOL=FALSE
autobuild build -c ReleaseOS --no-configure

Example with FMOD:
autobuild configure --config-file my_autobuild.xml -c ReleaseOS -- -DLL_TESTS:BOOL=FALSE -DPACKAGE:BOOL=FALSE -DFMOD:BOOL=TRUE
autobuild build --config-file my_autobuild.xml -c ReleaseOS --no-configure

{{KBnote|It is possible to use autobuild to do both the configure step (only needed once) and the build step with one command. I find it is clearer and saves a bit of time if these steps are done separately.}}

=== Compiling the viewer with the IDE ===

The autobuild configure step created the <code>\build-vc100</code> directory at the root of the source tree. In here is the <code>SecondLife.sln</code> solution file.

Start the IDE and open this solution.

You might want to change the build type in the drop-down located in the toolbar from '''Debug''' to '''Release''' or '''RelWithDebInfo'''.

[[File:VS2010BuildType.png|100px]]
[[:File:VS2010BuildType.png|Changing build type example image]]

You need to adjust the Platform Toolset setting.
* Select all the projects in the Solution Explorer list on the left of the screen.
** Click on the first project and scroll to the bottom of this list and {{K|shift}}-click on the last project.
* Right click on the selected list
* Navigate to '''Properties''' > '''Configuration Properties''' > '''General''' > '''Platform Toolset'''
* Change this value to <code>Windows7.1SDK</code>

* Push {{K|F7}} to start the compiler.

== Running your newly built viewer ==
=== Running from a desktop shortcut ===
* Make a desktop shortcut for <code>Drive:\your-path\build-vc100\newview\Release\secondlife-bin.exe</code>

* Right-click the shortcut
* Select '''Properties'''
* Set '''Start in:''' to <code>Drive:\your-path\indra\newview</code>

=== Running from within the IDE ===
* In the Solution Explorer pane right click on '''secondlife-bin'''
** Click '''Set as StartUp Project'''
** Pick '''Properties''' > '''Configuration Properties''' > '''Debugging'''
*** Set '''Command''' to <code>Drive:\your-path\build-vc100\newview\Release\secondlife-bin.exe</code> (adjust <code>Release</code> to the type of build you are doing, e.g. <code>RelWithDebInfo</code>)
*** Set '''Working Directory''' to <code>..\..\indra\newview</code>

== Handling Problems ==

If you encounter errors or run into problems following the instructions above, please first check whether someone else already had the same issue. A solution might be known already. See the [[#Common_Issues.2FBugs.2FGlitches_And_Solutions|issue list below]], check [[{{TALKPAGENAME}}|the talk page]] (and report useful experiences there) and search our [[issue tracker]]. Even when no description of your problem has been written down yet, someone might know about it, so get in touch with the community to [[#Getting_help|get help]].

=== Getting help ===
* Subscribe to [[OpenSource-Dev|OpenSource-Dev Mailing List]] ([https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev subscribe]) and post your question there.
* For faster response, join the general open source viewer discussion and development [[IRC]] channel [irc://irc.freenode.org/opensl #opensl on freenode]. Hopefully a helpful person is online when you ask your question.

=== Common Issues/Bugs/Glitches And Solutions ===

==== Not being able to find objidl.h in the Microsoft Windows SDK, when compiling llwindow ====
https://lists.secondlife.com/pipermail/opensource-dev/2011-April/006562.html
* Can be caused by path problems or some installation conflicts with the DirectX SDK.

==== stdint.h typedef conflicts between Quicktime and VS2010 ====
https://lists.secondlife.com/pipermail/opensource-dev/2011-April/006565.html
*: Can be solved by some small edits to header files to make sure the two don't bash on each other.

==== Eliminate deprecated switches, messages, and use memory more efficiently ====

The VS2010 compiler uses a lot of memory while compiling the viewer. If you run out of memory you will start to page heavily and your compile time will become much longer. The /Zm1000 switch affects compiler memory usage.

You may see this message while compiling:
use 'EHsc' instead of 'GX'

Here is how to free up some memory the compiler allocates and to eliminate these messages:

*Edit <code>\CMake 2.8\share\cmake-2.8\Modules\Platform\Windows-cl.cmake</code>

*Replace line 156 with:
IF(MSVC10)
SET(CMAKE_CXX_FLAGS_INIT "/DWIN32 /D_WINDOWS /W3 /EHsc /GR")
ELSEIF(NOT MSVC10)
SET(CMAKE_CXX_FLAGS_INIT "/DWIN32 /D_WINDOWS /W3 /Zm1000 /EHsc /GR")
ENDIF(MSVC10)

*Replace line 172 with:
IF(MSVC10)
SET(CMAKE_CXX_FLAGS_INIT "/DWIN32 /D_WINDOWS /W3 /EHsc /GR")
ELSEIF(NOT MSVC10)
SET(CMAKE_CXX_FLAGS_INIT "/DWIN32 /D_WINDOWS /W3 /Zm1000 /GX /GR")
ENDIF(MSVC10)

*Replace line 184 with:
IF(MSVC10)
SET(CMAKE_CXX_FLAGS_INIT "/DWIN32 /D_WINDOWS /W3 /EHsc /GR")
ELSEIF(NOT MSVC10)
SET(CMAKE_CXX_FLAGS_INIT "/DWIN32 /D_WINDOWS /W3 /Zm1000 /GX /GR")
ENDIF(MSVC10)

== References ==

Tip of the hat to Nicky_Perian for [[User:Nicky_Perian/Visual_Studio_10_Autobuild]]

[[Category:Compiling viewer]]

Stereoscopic Mode

2012-06-26T20:20:19Z

Inusaito Kanya: There are 4, not 3, ways... Since the 20:16, 13 July 2008 change

A desired feature for Second Life is the ability to view the world in Stereoscopic Mode. There are few ways this can be accomplished.

The University of Michigan has submitted patches (see {{jira|VWR-2972}}) to make this work, but changes to the drawing code have since broken the patches.

The patch allows a user to go into '''Preferences''' > '''Advanced Graphics''' and enable stereoscopic mode. Once this is done, there are 4 ways in which it may work:

; Anaglyph : which uses glasses with lenses that are Red and Cyan.
; Passive : Requires either two projectors with polarized filters or page-flipping goggles, like the [http://3dvisor.com Z800] or other Head Mounted Displays (HMD).
; Shutter glasses : requires shutter glasses.
; Cross-eyed auto-stereogram : requires no additional hardware, but just a split screen and some practice.

More information about these modes and where to get the required hardware is here: http://sl.daleglass.net/#stereo

With Second Life running in Stereoscopic mode and the proper device and stereoscopic driver, the user can perceive the actual depth of objects in world, the world should appear as if it is actually in 3D. Without the proper device, this type of rendering looks visibly different and is not possible for use.

[https://wiki.secondlife.com/wiki/Features Back to Features]

LSL Protocol/RestrainedLoveAPI

2012-05-17T02:59:23Z

Inusaito Kanya: /* For your information */ Fix red link

{{LSL Header|ml=*}}
=Restrained Love viewer v2.8.1 Specification=

By [[User:Marine Kelley|Marine Kelley]]

==Audience==

This document is for people who wish to modify or create their own [[LSL]] scripts to use the features of the [http://realrestraint.blogspot.com RestrainedLove viewer]. It does not explain [[LSL]] concepts such as messages and events, nor universal concepts such as [[UUID]]s.

This document contains the specification for RestrainedLove viewer itself. If you need information about the RestrainedLove viewer relay(RLV relay), please see the [[LSL_Protocol/Restrained_Love_Relay/Specification|RLV relay specification]]

==Introduction==

The [http://realrestraint.blogspot.com RestrainedLove viewer] executes certain behaviours when receiving special messages from scripts in-world. These messages are mostly calls to the [[llOwnerSay]]() [[LSL]] function.

==Architecture==

The [http://realrestraint.blogspot.com RestrainedLove viewer] intercepts every [[llOwnerSay]] message sent to the viewer. Lines that begin with an at-sign (''''@'''') are parsed as RLV commands. Other lines are forwarded to the user in the Local Chat window, as usual. For instance, a call to [[llOwnerSay]] ("@detach=n") sends the ''detach'' command with parameter ''n'' to the viewer on behalf of the object running the script.

The syntax of a message is:

: <code>@<command1>[:option1]=<param1>,<command2>[:option2]=<param2>,...,<commandN>[:optionN]=<paramN></code>

Note that there is only one '@' sign, placed at the beginning of the message. The viewer interprets this as "this entire [[llOwnerSay]]() message contains one or more commands to execute". For documentation purposes, commands are always presented with the leading ''''@''''. However, it is an error to put the ''''@'''' in front of each command within a multi-command message, and the subsequent commands will fail.

: Historical Note: Prior to Version '''1.10''', RLV only allowed one command per message. Version '''1.10''' added the ability to include multiple commands in one message, to avoid spamming users who are not using this viewer.

If at least one command fails (e.g. a typo), the viewer says "... fails command : ... " and prints the entire message. However, correct commands are still parsed and executed, only the incorrect ones are ignored.

Many of these commands determine the subsequent ''behaviour'' of the object or avatar. For example, the '''@detach=n''' command locks the given object, making it undetachable. Some commands set ''global behaviours'', which aren't limited to the object sending the command. For example, the '''@sendchat=n''' command will prevent the user from talking in local chat.

'''NOTE''' about commands with exceptions, such as @sendim or @sendchannel... @(rule):(exception)=n actually (and counter-intuitively) '''adds an exception''' for the given rule. @sendchannel:1=n, for example, '''allows''' chat on channel 1. This has been the source of at least two scripters' confusion. =add (which means the same as =n) and =rem (which means =y) exist for the purpose of adding and removing exceptions, respectively. Use them.

{{hint|mode=warning|desc=These behaviours are '''not''' persistent between sessions. Since an object changes its [[UUID]] every time it [[rez]]zes, the object ''must'' resend its status (undetachable, preventing IMs...) in the [[on_rez]]() event as well as whenever it changes its status.}}

==List of commands==

'''Note:''' These commands are not case-sensitive but are spacing-sensitive. In other words, "@detach = n" will '''not''' work.

'''Notation convention:''' Parameters in [square brackets] are optional parameters that can be omitted. The pipe | and slash / signs separate options from which one must be used. <angle brackets> enclose parameters that are mandatory.

===Version Checking===

* '''''Automated version checking''''' : "@version=<channel_number>"
''Implemented in v1.0b''
Makes the viewer automatically say the version of the RLV API it implements, 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.

'''Warning''' : when logging in, the [[on_rez]] event of all the attachments occurs way before the avatar can actually send chat messages (about half the way through the login progress bar). This means the timeout should be long enough, like 30 seconds to one minute in order to receive the automatic reply from the viewer.

'''Warning 2''' : On 02/22/2010, Linden Lab has released their Third Party Viewer policy which forbids using the term "Life" in the name of Third Party Viewers. Therefore "Restrained Life" had to be renamed to "Restrained Love". However, for compatibility purposes, this @version command still works and will keep working, however you are encouraged to '''not''' use it in new scripts, and to '''not''' show the terms "Restrained Life" to the user anywhere. For new scripts, please use @versionnew below instead.

* '''''Automated version checking''''' : "@versionnew=<channel_number>"
''Implemented in v1.23''
Makes the viewer automatically say the version of the RLV API it implements, 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.

This command is the successor of @version and replaces it, although @version is kept for ascending compatibility purposes. It returns "RestrainedLove viewer v... (SL ...)" ("RestrainedLove" is in one word).

'''Warning''' : when logging in, the [[on_rez]] event of all the attachments occurs way before the avatar can actually send chat messages (about half the way through the login progress bar). This means the timeout should be long enough, like 30 seconds to one minute in order to receive the automatic reply from the viewer.

* '''''Automated version number checking''''' : "@versionnum=<channel_number>"
''Implemented in v1.21''
Makes the viewer automatically say the version number of the RLV API it implements (please note that this is different from the version of the viewer, which the scripts should not have to care about), 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. This command is less cumbersome than @version, since the script does not have to parse the response, it gets the version number immediately.

The version number is a mere integer that represents the version of the API. If the version is X.Y.Z.P, then the number will be X.10^6 + Y.10^4 + Z.10^2 + P. For example, 1.21.1 would be 1210100.

* '''''Automated version checking, second way''''' : llGetAgentLanguage (key id) '''''DEPRECATED: DO NOT USE !'''''
''Implemented in v1.16''
When calling this LSL function, the result is obtained immediately (no need to use a listener and a timer), is exactly equal to the one given by "@version" and cannot be hidden by the user. This string takes the place of the language returned by the regular SL viewer, which could answer values like "en-us", "fr", "ko" etc. Or nothing at all, if the user chose to hide their language setting. Being optional in the regular viewer, it cannot be trusted by a script, so "hijacking" this feature for the much more useful synchronous version checking in the RLV makes sense. IMPORTANT NOTE: this feature cannot be implemented in viewers prior to v1.21, even when they do implement RestrainedLove v1.16, so make sure you do fall back to the @version method whenever llGetAgentLanguage() returns an empty string. ALSO NOTE: In RestrainedLove 1.16, llGetAgentLanguage() will return an empty string when called by on_rez during login unless the call is delayed by several seconds (how many seconds may vary). FINAL NOTE: This feature was removed from v1.16.1 (and v1.16b, for the Cool SL Viewer).

* '''''Manual version checking''''' : "@version"
''Implemented in v1.0a''
This command must be sent in IM from an avatar to the user (will not work from objects). The viewer automatically answers its version to the sender in IM, but neither the message nor the answer appears in the user's IM window, so it's totally stealthy.

===Blacklist handling===

The blacklist (implemented in v2.8) is a list of RLV commands that the viewer is meant to ignore. It is modifiable at any time, but a restart is needed to take the changes into account. When a command is issued and it is part of the blacklist, the RLV will simply ignore it. Modifying the blacklist won't clear existing restrictions though, once they are issued, a restart is needed. When a command is received, a positive acknowledgement is sent to the script, whether the command was actually accepted or not. This way scripts that wait for notifications won't break if they can't handle a denial.

* '''''Automated version number checking, followed by the blacklist''''' : "@versionnumbl=<channel_number>"
''Implemented in v2.8''
Makes the viewer automatically say the version number of the RLV API it implements (please note that this is different from the version of the viewer, which the scripts should not have to care about), followed by a comma (",") and the contents of the blacklist, 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. This command is less cumbersome than @version followed by @getblacklist, since the script does not have to parse the response, it gets the version number immediately, and it does not have to send a second asynchronous request after the response to the first.

For example, "@versionnumbl=2222" will answer "2080000,sendim,recvim" if the blacklist is currently "sendim,recvim". LSL allows for casting such a string into an integer without any trouble, it would return 2080000, discarding the first comma and all that is after it.

* '''''Get the contents of the blacklist, with a filter''''' : "@getblacklist[:filter]=<channel_number>"
''Implemented in v2.8''
Makes the viewer automatically reply with the contents of the blacklist (if a filter is present, then only the commands containing that text will be part of the reply), 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.

* '''''Manual blacklist checking''''' : "@getblacklist"
''Implemented in v2.8''
This command must be sent in IM from an avatar to the user (will not work from objects). The viewer automatically answers the contents of its blacklist to the sender in IM, but neither the message nor the answer appears in the user's IM window, so it's totally stealthy.

===Miscellaneous===

* '''''Start/stop notifications on a private channel''''' : "@notify:<channel_number>[;word]=<rem/add>"
''Implemented in v1.20, improved in v2.2 (and v1.24)''
Makes the viewer automatically repeat any restriction it adds or removes on the specified channel, or only the restrictions which name contains the word specified after the semicolon (";") character. The response on the private channel <channel_number> is preceded with a slash ("/") to avoid making the avatar send commands to other scripts without knowing it, and followed by an equal sign ("=") and "n" or "y" according to whether the restriction is applied or lifted respectively. The "@clear" command will not add an equal sign. There is no way to know what object issued the restriction or lifted it, to avoid disclosing too much information about foreign scripts. It does not repeat one-shot commands either (force commands). For example, "@notify:2222;detach=add" will send "/detach=n" whenever an object is locked, and "/detach=y" whenever an object is unlocked, on channel 2222 to which the script will listen to.

Note : Since v2.2 (and v1.24) you can also set a notification for inventory offers. When your object gives an item or a folder, the avatar using a RLV v2.2 (and v1.24) or higher will respond automatically on the given channel one of the following :

- /accepted_in_rlv inv_offer <folder> : The folder has been accepted and is now available under #RLV (don't forget that the viewer renames it, removing the "#RLV/" prefix).

- /accepted_in_inv inv_offer <folder> : The folder has been accepted but is not shared.

- /declined inv_offer <folder> : The folder has been declined and/or the user has pressed "Block" (formerly "Mute").

Where <folder> is the full path of the folder or item given. For example, #RLV/~MyCuffs. There is a space before "inv_offer", which is a token chosen in a way that it is easy to set a notification for it. If you just want to know whether your folder named #RLV/~MyCuffs has been accepted in the #RLV folder, issue a "@notify:2222;accepted_in_rlv inv_offer #RLV/~MyCuffs=add" command. If you just want to know whether the avatar has received something, issue a simple "@notify:2222;inv_offer=add" command.

Note 2 : Since v2.5 the viewer also sends notifications when wearing outfits :

- /worn legally <layer> : The avatar has just worn a piece of clothing on the indicated layer.

- /unworn legally <layer> : The avatar has just removed a piece of clothing from the indicated layer.

- /attached legally <attach_point_name> : The avatar has just attached an object to the indicated attachment point.

- /attached illegally <attach_point_name> : The avatar has just attached an object to the indicated attachment point, but was not allowed to (probably a script attached it automatically), and it will be detached in a few seconds.

- /detached legally <attach_point_name> : The avatar has just detached an object from the indicated attachment point.

- /detached illegally <attach_point_name> : The avatar has just detached an object from the indicated attachment point, but was not allowed to (probably a script kicked it off), and it will be re-attached in a few seconds.

* '''''Allow/deny permissive exceptions''''' : "@permissive=<y/n>"
''Implemented in v1.21''
When denied, all restrictions turn into their "secure" counterparts (if any). This means an exception to a restriction will be ignored if it is not issued by the same object that issued the restriction. Using non-secure restrictions (the original ones, like @sendim, @recvim etc) and not using @permissive allow the avatar to benefit from exceptions issued by different objects.

'''Warning''' : Using this command (or any secure version of the original commands) may silently discard exceptions issued by different objects (it is even its primary purpose), hence some products may appear to cease working while this restriction is in effect. For example, a product that allows the avatar to always be able to send IMs a particular friend will not be able to overcome a @sendim_sec or a @permissive command sent by another object, and will look like it is broken. Therefore, use with caution and make the user aware of how secure your own product is !

* '''''Clear all the rules tied to an object''''' : "@clear"
''Implemented in v1.0a, but working only since v1.04a''
This command clears all the restrictions and exceptions tied to a particular [[UUID]].

'''Warning''' : when triggered on detach by default, this might prevent the automatic reattach when @defaultwear is active, as @clear will also lift @detach=n, thus the viewer thinks the item that gets detached by accident by a default-wear-action is unlocked and will not reattach it.

Possible workarounds:
::* only lift the exact restrictions you added with @clear=<pattern>
::* only trigger @clear on detach when you are sure the attachment is not locked
::* don't trigger @clear on detach at all and wait for the viewer to lift the set restrictions

* '''''Clear a subset of the rules tied to an object''''' : "@clear=<string>"
''Implemented in v1.0a, but working only since v1.04a''
This command clears all the restrictions and exceptions tied to a particular [[UUID]] which name contains <string>. A good example would be "@clear=tp" which clears all the [[teleport]] restrictions and exceptions tied to that object, whereas "@clear=tplure:" would only clear the exceptions to the "teleport-by-friend" restriction

* '''''Get the list of restrictions the avatar is currently submitted to''''' : @getstatus[:<part_of_rule>[;<custom_separator>]]=<channel>
''Implemented in v1.10, slightly tweaked in v1.16 and v2.8''
Makes the viewer automatically answer the list of rules the avatar is currently under, which would only contains the restrictions issued by the object that sends this command, 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 answer is a list of rules, separated by slashes ('/') or by any other separator if specified. Attention : since v1.16 a slash is prepended at the beginning of the string. This does not confuse llParseString2List() calls, but does confuse llParseStringKeepNulls() calls !

Since v2.8, if <custom_separator> is specified, it will replace the slash ('/') with the provided separator. Attention, the option part must be present, therefore there must be a colon (':') before the semicolon (';'), even if <part_of_rule> is absent.

This command is useful for people who write scripts that may conflict with other scripts in the same object (for instance : third-party plugins). Conflicts do not occur in different objects, that's why this command only replies the restrictions issued by the object calling it.

<part_of_rule> is the name of a rule, or a part of it, useful if the script only needs to know about a certain restriction.

Example : If the avatar is under tploc, tplure, tplm and sittp, here is what the script would get :
@getstatus=2222 => /tploc/tplure/tplm/sittp
@getstatus:sittp=2222 => /sittp
@getstatus:tpl=2222 => /tploc/tplure/tplm (because "tpl" is part of "tploc", "tplure" and "tplm" but not "sittp")
@getstatus:tpl;#=2222 => #tploc#tplure#tplm (because "tpl" is part of "tploc", "tplure" and "tplm" but not "sittp", and the specified separator is "#")
@getstatus:;#=2222 => #tploc#tplure#tplm#sittp (because the specified separator is "#")
@getstatus:;=2222 => /tploc/tplure/tplm/sittp (because the specified separator is empty, so it defaults to "/")

* '''''Get the list of all the restrictions the avatar is currently submitted to''''' : @getstatusall[:<part_of_rule>[;<custom_separator>]]=<channel>
''Implemented in v1.15, slightly tweaked in v1.16 and v2.8''
Makes the viewer automatically answer the list of rules the avatar is currently under, for all the objects regardless of their UUID, contrary to @getstatus, 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 answer is a list of rules, separated by slashes ('/') or by any other separator if specified. Attention : since v1.16 a slash is prepended at the beginning of the string. This does not confuse llParseString2List() calls, but does confuse llParseStringKeepNulls() calls !

Since v2.8, if <custom_separator> is specified, it will replace the slash ('/') with the provided separator. Attention, the option part must be present, therefore there must be a colon (':') before the semicolon (';'), even if <part_of_rule> is absent.

===Movement===

* '''''Allow/prevent flying''''' : @fly=<y/n>
''Implemented in v1.12.2''
When prevented, the user is unable to fly.

* '''''Allow/prevent running by double-tapping an arrow key''''' : @temprun=<y/n>
''Implemented in v2.7''
When prevented, the user is unable to run by double-tapping an arrow key. If you want to prevent the user from running at all, you must also use @alwaysrun.

* '''''Allow/prevent always running''''' : @alwaysrun=<y/n>
''Implemented in v2.7''
When prevented, the user is unable to switch running mode on by pressing Ctrl-R. If you want to prevent the user from running at all, you must also use @temprun. This command is useful when you want to force the user to accelerate before running, rather than running all the time, for example during combats or sports games.

* '''''Force rotate the avatar to a set direction''''' : @setrot:<angle_in_radians>=force
''Implemented in v1.17''
Forces the avatar to rotate towards a direction set by an angle in radians from the north. Note that this command is not very precise, nor will do anything if the action attempts to rotate the avatar by less than 10° (experimental value, it has been mentioned somewhere that 6° was the minimum). In other words, it is best to either check with a llGetRot() first, or to make the avatar turn twice, first 180° plus the desired angle, then by the angle we need. It isn't very elegant but it works.

* '''''Change the height of the avatar''''' : @adjustheight:<distance_pelvis_to_foot_in_meters>;<factor>[;delta_in_meters]=force
''Implemented in v2.5''
Forces the avatar to modify its "Z-offset", in other words its altitude. This value can already be changed through a debug setting in most third party viewers, this command allows to automate the change according to the animation.

Rather than explaining it in full here, please go to this link for further info : [http://sldev.free.fr/forum/viewtopic.php?f=7&t=447]

===Chat, Emotes and Instant Messages===
====Chat====
* '''''Allow/prevent sending chat messages''''' : "@sendchat=<y/n>"
''Implemented in v1.0b''
When prevented, everything typed on [[channel]] 0 will be discarded. However, emotes and messages beginning with a slash ('/') will go through, truncated to strings of 30 and 15 characters long respectively (likely to change later). Messages with special signs like ()"-*=_^ are prohibited, and will be discarded. When a period ('.') is present, the rest of the message is discarded.

* '''''Allow/prevent shouting''''' : "@chatshout=<y/n>"
''Implemented in v1.15''
When prevented, the avatar will chat normally even when the user tries to shout. This does not change the message in any way, only its range.

* '''''Allow/prevent chatting at normal volume''''' : "@chatnormal=<y/n>"
''Implemented in v1.15''
When prevented, the avatar will whisper even when the user tries to shout or chat normally. This does not change the message in any way, only its range.

* '''''Allow/prevent whispering''''' : "@chatwhisper=<y/n>"
''Implemented in v1.15''
When prevented, the avatar will chat normally even when the user tries to whisper. This does not change the message in any way, only its range.

* '''''Redirect public chat to private channels''''' : "@redirchat:<channel_number>=<rem/add>"
''Implemented in v1.16''
When active, this restriction redirects whatever the user says on the public channel ("/0") to the private channel provided in the option field. If several redirections are issued, the chat message will be redirected to each channel. It does not apply to emotes, and will not trigger any animation (typing start, typing stop, nodding) when talking. This restriction does not supercede @sendchannel.
'''NOTE:''' As of RLV v1.22.1 / RLVa 1.1.0, it had a bug that @redirchat also truncates emotes on channel 0. An additional @emote=add works around this side-effect. This bug was fixed in the Cool VL Viewer starting with v1.22g (but Marine's RLV v1.23 still had this bug) and RLV v2.0 (it is safe to assume it was fixed in all viewers starting with v1.24 and v2.0).

* '''''Allow/prevent receiving chat messages''''' : "@recvchat=<y/n>"
''Implemented in v1.0b''
When prevented, everything heard in public chat will be discarded except emotes.

* '''''Allow/prevent receiving chat messages, secure way''''' : "@recvchat_sec=<y/n>"
''Implemented in v1.21''
When prevented, everything heard in public chat will be discarded except emotes. This particular command accepts exceptions issued from the same object only, opposed to the non-secure way that accepts exceptions from any object.

* '''''Remove/add exceptions to the chat message receiving prevention''''' : "@recvchat:<UUID>=<rem/add>"
''Implemented in v1.01''
When adding an exception, the user can hear chat messages from the sender whose [[UUID]] is specified in the command. This overrides the prevention for this avatar only (there is no limit to the number of exceptions), don't forget to remove it when it becomes obsolete.

* '''''Allow/prevent receiving chat messages from someone in particular''''' : "@recvchatfrom:<UUID>=<y/n>"
''Implemented in v2.3 and v1.25''
When prevented, everything heard in public chat from the specified avatar will be discarded except emotes.

====Emotes====
* '''''Remove/add an exception to the emote truncation above''''' : "@emote=<rem/add>"
''Implemented in v1.01''
When adding this exception, the emotes are not truncated anymore (however, special signs will still discard the message).

* '''''Redirect public emotes to private channels''''' : "@rediremote:<channel_number>=<rem/add>"
''Implemented in v1.19''
When active, this restriction redirects whatever emote the user says on the public channel ("/0") to the private channel provided in the option field. If several redirections are issued, the emote will be redirected to each channel.

* '''''Allow/prevent seeing emotes''''' : "@recvemote=<y/n>"
''Implemented in v1.19''
When prevented, every emote seen in public chat will be discarded.

* '''''Allow/prevent receiving emotes seen in public chat from someone in particular''''' : "@recvemotefrom:<UUID>=<y/n>"
''Implemented in v2.4''
When prevented, everything emote seen in public chat from the specified avatar will be discarded.

* '''''Allow/prevent seeing emotes, secure way''''' : "@recvemote_sec=<y/n>"
''Implemented in v1.21''
When prevented, every emote seen in public chat will be discarded. This particular command accepts exceptions issued from the same object only, opposed to the non-secure way that accepts exceptions from any object.

* '''''Remove/add exceptions to the emote seeing prevention''''' : "@recvemote:<UUID>=<rem/add>"
''Implemented in v1.19''
When adding an exception, the user can see emotes from the sender whose [[UUID]] is specified in the command. This overrides the prevention for this avatar only (there is no limit to the number of exceptions), don't forget to remove it when it becomes obsolete.

====Private Channels====
* '''''Allow/prevent using any chat channel but certain channels''''' : @sendchannel[:<channel>]=<y/n>
''Implemented in v1.10''
Complimentary of @sendchat, this command prevents the user from sending messages on non-public [[channel]]s. If channel is specified, it becomes an exception to the aforementioned restriction (then it is better to use "rem" or "add" instead of "y" or "n" respectively). It does not prevent the viewer automatic replies like @version=nnnn, @getstatus=nnnn etc.

* '''''Allow/prevent using any chat channel but certain channels, secure way''''' : @sendchannel_sec[:<channel>]=<y/n>
''Implemented in v1.10''
Complimentary of @sendchat, this command prevents the user from sending messages on non-public [[channel]]s. If channel is specified, it becomes an exception to the aforementioned restriction (then it is better to use "rem" or "add" instead of "y" or "n" respectively). It does not prevent the viewer automatic replies like @version=nnnn, @getstatus=nnnn etc. This particular command only accepts exceptions issued from the same object, opposed to its non-secure version which accepts exceptions from any other object.

====Instant Messages====
* '''''Allow/prevent sending instant messages''''' : "@sendim=<y/n>"
''Implemented in v1.0b''
When prevented, everything typed in IM will be discarded and a bogus message will be sent to the receiver instead.

* '''''Allow/prevent sending instant messages, secure way''''' : "@sendim_sec=<y/n>"
''Implemented in v1.21''
When prevented, everything typed in IM will be discarded and a bogus message will be sent to the receiver instead. This particular command accepts exceptions issued from the same object only, opposed to the non-secure way that accepts exceptions from any object.

* '''''Remove/add exceptions to the instant message sending prevention''''' : "@sendim:<UUID>=<rem/add>"
''Implemented in v1.01''
When adding an exception, the user can send IMs to the receiver whose [[UUID]] is specified in the command. This overrides the prevention for this avatar only (there is no limit to the number of exceptions), don't forget to remove it when it becomes obsolete.

* '''''Allow/prevent sending instant messages to someone in particular''''' : "@sendimto:<UUID>=<y/n>"
''Implemented in v2.3 and v1.25''
When prevented, everything typed in IM to the specified avatar will be discarded and a bogus message will be sent instead.

* '''''Allow/prevent starting an IM session with anyone''''' : "@startim=<y/n>"
''Implemented in v2.6''
When prevented, the user is unable to start an IM session with anyone. Sessions that are already open are not impacted though.

* '''''Remove/add exceptions to the IM session start prevention''''' : "@startim:<UUID>=<rem/add>"
''Implemented in v2.6''
When adding an exception, the user can start an IM session with the receiver whose [[UUID]] is specified in the command. This overrides the prevention for this avatar only (there is no limit to the number of exceptions), don't forget to remove it when it becomes obsolete.

* '''''Allow/prevent starting an IM session with someone in particular''''' : "@startimto:<UUID>=<y/n>"
''Implemented in v2.6''
When prevented, the user is unable to start an IM session with that person. Sessions that are already open are not impacted though.

* '''''Allow/prevent receiving instant messages''''' : "@recvim=<y/n>"
''Implemented in v1.0b''
When prevented, every incoming IM will be discarded and the sender will be notified that the user cannot read them.

* '''''Allow/prevent receiving instant messages, secure way''''' : "@recvim_sec=<y/n>"
''Implemented in v1.21''
When prevented, every incoming IM will be discarded and the sender will be notified that the user cannot read them. This particular command accepts exceptions issued from the same object only, opposed to the non-secure way that accepts exceptions from any object.

* '''''Remove/add exceptions to the instant message receiving prevention''''' : "@recvim:<UUID>=<rem/add>"
''Implemented in v1.01''
When adding an exception, the user can read instant messages from the sender whose [[UUID]] is specified in the command. This overrides the prevention for this avatar only (there is no limit to the number of exceptions), don't forget to remove it when it becomes obsolete.

* '''''Allow/prevent receiving instant messages from someone in particular''''' : "@recvimfrom:<UUID>=<y/n>"
''Implemented in v2.3 and v1.25''
When prevented, every IM received from the the specified avatar will be discarded and the sender will be notified that the user cannot read them.

===Teleportation===

* '''''Allow/prevent teleporting to a landmark''''' : "@tplm=<y/n>"
''Implemented in v1.0''
When prevented, the user cannot use a [[landmark]], pick or any other preset location to [[teleport]] there.

* '''''Allow/prevent teleporting to a location''''' : "@tploc=<y/n>"
''Implemented in v1.0''
When prevented, the user cannot use [[teleport]] to a coordinate by using the [[map]] and such.

* '''''Allow/prevent teleporting by a friend''''' : "@tplure=<y/n>"
''Implemented in v1.0''
When prevented, the user automatically discards any [[teleport]] offer, and the avatar who initiated the offer is notified.

* '''''Allow/prevent teleporting by a friend, secure way''''' : "@tplure_sec=<y/n>"
''Implemented in v1.21''
When prevented, the user automatically discards any [[teleport]] offer, and the avatar who initiated the offer is notified. This particular command accepts exceptions issued from the same object only, opposed to the non-secure way that accepts exceptions from any object.

* '''''Remove/add exceptions to the friend teleport prevention''''' : "@tplure:<UUID>=<rem/add>"
''Implemented in v1.0''
When adding an exception, the user can be teleported by the avatar whose [[UUID]] is specified in the command. This overrides the prevention for this avatar only (there is no limit to the number of exceptions), don't forget to remove it when it becomes obsolete.

* '''''Unlimit/limit sit-tp''''' : "@sittp=<y/n>"
''Implemented in v1.0''
When limited, the avatar cannot sit on a [[prim]] unless it is closer than 1.5 m. This allows cages to be secure, preventing the avatar from warping its position through the walls (unless the prim is too close).

* '''''Allow/prevent standing up at a different location than where we sat down''''' : @standtp=<y/n>
''Implemented in v2.1.2 and v1.24''
When this restriction is active and the avatar stands up, it is automatically teleported back to the location where it initially sat down. Please note that the "last standing location" is also stored when the restriction is issued, so this won't be a problem for grabbers and the like, that sit the victim, then move them inside a cell, which issues its restrictions, and then unsits them. In this case the avatar will stay in the cell.

* '''''Force-Teleport the user''''' : @tpto:<X>/<Y>/<Z>=force (*)
''Implemented in v1.12''
This command forces the avatar to teleport to the indicated coordinates. Note that these coordinates are always '''global''', hence the script that calls this command will not be trivial. Moreso, if the destination contains a telehub or a landing point, the user will land there instead of the desired point. This is a SL limitation. Also keep in mind that @tpto is inhibited by @tploc=n, and from v1.15 and above, by @unsit too.

Here is a sample code to call that command properly :

<lsl>

// FORCE TELEPORT EXAMPLE
// Listens on channel 4 for local coordinates and a sim name
// and tells your viewer to teleport you there.
//
// By Marine Kelley 2008-08-26
// RLV version required : 1.12 and above
//
// HOW TO USE :
// * Create a script inside a box
// * Overwrite the contents of the script with this one
// * Wear the box
// * Say the destination coords Region/X/Y/Z on channel 4 :
// Example : /4 Help Island Public/128/128/50

key kRequestHandle; // UUID of the dataserver request
vector vLocalPos; // local position extracted from the

Init () {
kRequestHandle = NULL_KEY;
llListen (4, "", llGetOwner (), "");
}

default
{
state_entry () {
Init ();
}

on_rez(integer start_param) {
Init ();
}

listen(integer channel, string name, key id, string message) {
list tokens = llParseString2List (message, ["/"], []);
integer L = llGetListLength (tokens);

if (L==4) {
// Extract local X, Y and Z
vLocalPos.x = llList2Float (tokens, 1);
vLocalPos.y = llList2Float (tokens, 2);
vLocalPos.z = llList2Float (tokens, 3);

// Request info about the sim
kRequestHandle=llRequestSimulatorData (llList2String (tokens, 0), DATA_SIM_POS);
}
}

dataserver(key queryid, string data) {
if (queryid == kRequestHandle) {
// Parse the dataserver response (it is a vector cast to a string)
list tokens = llParseString2List (data, ["<", ",", ">"], []);
string pos_str = "";
vector global_pos;

// The coordinates given by the dataserver are the ones of the
// South-West corner of this sim
// => offset with the specified local coordinates
global_pos.x = llList2Float (tokens, 0);
global_pos.y = llList2Float (tokens, 1);
global_pos.z = llList2Float (tokens, 2);
global_pos += vLocalPos;

// Build the command
pos_str = (string)((integer)global_pos.x)
+"/"+(string)((integer)global_pos.y)
+"/"+(string)((integer)global_pos.z);
llOwnerSay ("Global position : "+(string)pos_str); // Debug purposes

// Fire !
llOwnerSay ("@tpto:"+pos_str+"=force");
}
}

}

</lsl>

* '''''Remove/add auto-accept teleport offers from a particular avatar''''' : "@accepttp[:<UUID>]=<rem/add>"
''Implemented in v1.15, slightly improved in v1.16''
Adding this rule will make the user automatically accept any teleport offer from the avatar which key is <UUID>, exactly like if that avatar was a Linden (no confirmation box, no message, no Cancel button). This rule does not supercede nor deprecate @tpto because the former teleports to someone, while the latter teleports to an arbitrary location. Attention : in v1.16 the UUID becomes optional, which means that @accepttp=add will force the user to accept teleport offers from anyone ! Use with caution !

===Inventory, Editing and Rezzing===

* '''''Allow/prevent using inventory''''' : @showinv=<y/n>
''Implemented in v1.10''
Forces the [[inventory]] windows to close and stay closed.

* '''''Allow/prevent reading notecards''''' : @viewnote=<y/n>
''Implemented in v1.10''
Prevents from opening [[notecards]] but does not close the ones already open.

* '''''Allow/prevent opening scripts''''' : @viewscript=<y/n>
''Implemented in v1.22''
Prevents from opening [[scripts]] but does not close the ones already open.

* '''''Allow/prevent opening textures''''' : @viewtexture=<y/n>
''Implemented in v1.22''
Prevents from opening [[textures]] (and snapshots) but does not close the ones already open.

* '''''Allow/prevent editing objects''''' : "@edit=<y/n>"
''Implemented in v1.03''
When prevented from editing and opening objects, the Build & Edit window will refuse to open.

* '''''Remove/add exceptions to the edit prevention''''' : "@edit:<UUID>=<rem/add>"
''Implemented in v2.3 and v1.25''
When adding an exception, the user can edit or open this object in particular.

* '''''Allow/prevent rezzing inventory''''' : "@rez=<y/n>"
''Implemented in v1.03''
When prevented from [[rez]]zing stuff, creating and deleting objects, drag-dropping from inventory and dropping attachments will fail.

* '''''Allow/prevent editing particular objects''''' : "@editobj:<UUID>=<y/n>"
''Implemented in v2.3 and v1.25''
When prevented, the Build & Edit window will refuse to open when trying to edit or open the specified object.

===Sitting===

* '''''Allow/prevent standing up''''' : @unsit=<y/n>
''Implemented in v1.10, modified in v1.15 to prevent teleporting as well''
Hides the Stand up button. From v1.15 it also prevents teleporting, which was a way to stand up.

* '''''Force sit on an object''''' : @sit:<UUID>=force (*)
''Implemented in v1.10''
Does not work if the user is prevented from sit-tping and further than 1.5 meters away, or when prevented from unsitting.

* '''''Get the UUID of the object the avatar is sitting on''''' : @getsitid=<channel_number>
''Implemented in v1.12.4 but broken in all versions older than v1.24 and v2.2 (was reporting the UUID of the last object any avatar within draw distance sat upon)''
Makes the viewer automatically answer the UUID of the object the avatar is currently sitting on, or NULL_KEY if they are not sitting.

* '''''Force unsit''''' : @unsit=force (*)
''Implemented in v1.10''
Self-explanatory but for some reason it randomly fails, so don't rely on it for now. Further testing is needed.

* '''''Allow/prevent sitting down''''' : @sit=<y/n>
''Implemented in v1.16.2''
Prevents the user from sitting on anything, including with @sit:UUID=force.

===Clothing and Attachments===

* '''''Render an object detachable/nondetachable''''' : "@detach=<y/n>"
''Implemented in v1.0a''
When called with the "n" option, the object sending this message (which must be an attachment) will be made nondetachable. It can be detached again when the "y" option is called.

* '''''Unlock/Lock an attachment point''''' : "@detach:<attach_point_name>=<y/n>"
''Implemented in v1.20''
When called with the "n" option, the attachment point of name <attach_point_name> will be locked either full (if it is occupied by an object at that time) or empty (if not). Any object that is occupying this point when the restriction is issued will be considered as undetachable, exactly like if it had issued a "@detach=n" command itself. If the point is empty it will stay that way, no item will be able to be attached there, and llAttachToAvatar() calls will fail (the object will be attached, then detached right away).

* '''''Unlock/Lock an attachment point empty''''' : "@addattach[:<attach_point_name>]=<y/n>"
''Implemented in v1.22''
When called with the "n" option, the attachment point of name <attach_point_name> will be locked empty. Any object that is occupying this point when the restriction is issued can be detached, but nothing can be attached there. If the point is empty it will stay that way, no item will be able to be attached there, and llAttachToAvatar() calls will fail (the object will be attached, then detached right away). If <attach_point_name> is not specified, then all the attachment points will be concerned. This command is the counterpart to @addoutfit, for attachments.

* '''''Unlock/Lock an attachment point full''''' : "@remattach[:<attach_point_name>]=<y/n>"
''Implemented in v1.22''
When called with the "n" option, the attachment point of name <attach_point_name> will be locked full. Any object that is occupying this point when the restriction is issued will be rendered undetachable. If the point is empty it will allow the user to wear something, but then that object will become undetachable too, no item will be able to replace it, and llAttachToAvatar() calls will fail (the object will be attached, then detached right away). If <attach_point_name> is not specified, then all the attachment points will be concerned. This command is the counterpart to @remoutfit, for attachments.

* '''''Allow/deny the "Wear" contextual menu''''' : "@defaultwear=<y/n>
''Implemented in v1.21''
When allowed, the user is always able to choose the "Wear"command on the contextual menu of the inventory, even when an object is locked on their avatar. This holds the risk of kicking that locked object, but it will be reattached automatically within 5 seconds (and successive locked objects every second until there is nothing left to reattach). However some objects may be scripted in a way that they drop their restrictions when detached, or simply not take into account the fact that even a locked object can be detached when using the RLV.

Therefore, using this command with the "n" option will suppress this comman, but it will still be available for objects that contain the target attachment point in their name or in the name of their parent folder, exactly like pre-1.21 RLV. This is a little less user-friendly but more secure when it comes to make sure no locked object may be detached accidentally.

* '''''Force removing attachments''''' : @detach[:attachpt]=force (*)
''Implemented in v1.10''
Where part 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|neck|root
If part is not specified, removes everything.

* '''''Force removing attachments (alias)''''' : @remattach[:attachpt]=force (*)
''Implemented in v1.22''
This command is an alias to @detach[:attachpt]=force (to keep things consistent).

* '''''Allow/prevent wearing clothes''''' : @addoutfit[:<part>]=<y/n>
''Implemented in v1.10, added skin hair and eyes in v1.10.1, added physics in 2.6.1''
Where part is :
gloves|jacket|pants|shirt|shoes|skirt|socks|underpants|undershirt|skin|eyes|hair|shape|alpha|tattoo|physics
If part is not specified, prevents from wearing anything beyond what the avatar is already wearing.

'''Note:''' Since the release of Viewer 2.0 there are two new avatar skin layers: Tattoo and Avatar Transparency Mask. The alpha and tattoo layers will only be supported by RLV compliant viewers that implement the new Viewer 2.0 features.

* '''''Allow/prevent removing clothes''''' : @remoutfit[:<part>]=<y/n> (underpants and undershirt are kept for teens)
''Implemented in v1.10, added skin hair and eyes in v1.10.1, added physics in 2.6.1''
Where part is :
gloves|jacket|pants|shirt|shoes|skirt|socks|underpants|undershirt|skin|eyes|hair|shape|alpha|tattoo|physics
If part is not specified, prevents from removing anything in what the avatar is wearing.

'''Note:''' Since the release of Viewer 2.0 there are two new avatar skin layers: Tattoo and Avatar Transparency Mask. The alpha and tattoo layers will only be supported by RLV compliant viewers that implement the new Viewer 2.0 features.

* '''''Force removing clothes''''' : @remoutfit[:<part>]=force (*) (teens can't be forced to remove underpants and undershirt)
''Implemented in v1.10''
Where part is :
gloves|jacket|pants|shirt|shoes|skirt|socks|underpants|undershirt|alpha|tattoo|physics
If part is not specified, removes everything.

'''Note:''' Since the release of Viewer 2.0 there are two new avatar skin layers: Tattoo and Avatar Transparency Mask. The alpha and tattoo layers will only be supported by RLV compliant viewers that implement the new Viewer 2.0 features.

'''Note:''' skin, shape, eyes and hair cannot be removed since they are body parts (and removing any would result in an unrezzed avatar).

* '''''Get the list of worn clothes''''' : @getoutfit[:part]=<channel_number>
''Implemented in v1.10, added skin hair and eyes in v1.10.1, added physics in 2.6.1''
Makes the viewer automatically answer the current occupation of clothes layers as a list of 0s (empty) and 1s (occupied) 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 :
gloves,jacket,pants,shirt,shoes,skirt,socks,underpants,undershirt,skin,eyes,hair,shape
in that order.

If a part is specified, answers a single 0 (empty) or 1 (occupied) corresponding to the part.
Ex 1 : @getoutfit=2222 => "0011000111" => avatar is wearing pants, shirt, underpants and undershirt, and of course a skin.
Ex 2 : @getoutfit:socks=2222 => "0" => the avatar is not wearing socks.

'''Note:''' For viewers that implement the new Viewer 2.0 features, the list is:

gloves,jacket,pants,shirt,shoes,skirt,socks,underpants,undershirt,skin,eyes,hair,shape,alpha,tattoo

* '''''Get the list of worn attachments''''' : @getattach[:attachpt]=<channel_number>
''Implemented in v1.10''
Makes the viewer automatically answer the current occupation of attachment points as a list of 0s (empty) and 1s (occupied) 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 :
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,neck,root
in that order.

If an attachment point is specified, answers a single 0 (empty) or 1 (occupied) corresponding to the point.
Ex 1 : @getattach=2222 => "011000011010000000000000100100000000101" => avatar is wearing attachments on
chest, skull, left and right foot, pelvis, l and r lower leg, HUD bottom left and HUD bottom right.
Ex 2 : @getattach:chest=2222 => "1" => avatar is wearing something on the chest.

''Note'' : The first character ("none") is always '0', so the index of each attach point in the string is '''exactly equal''' to the corresponding ATTACH_* macro in LSL. For instance, the index 9 in the string is ATTACH_BACK (which means "spine"). Remember the indices start at zero.

* '''''Force the viewer to automatically accept attach and take control permission requests''''' : @acceptpermission=<rem/add>
''Implemented in v1.16''
Forces the avatar to automatically accept attach and take control permission requests. The dialog box doesn't even show up. This command does not supercede @denypermission, of course.

* '''''Allow/prevent accepting attach and take control permissions''''' : @denypermission=<rem/add>
''Implemented in v1.16, DEPRECATED in v1.16.2''
When prevented, all attach and take control permission requests are automatically declined, without even showing the dialog box. Due to the extreme annoyance it was making, and because locked objects automatically reattach themselves since v1.16.1, this command is NOW DEPRECATED, DON'T USE IT !

* '''''Force detach an item''''' : @detachme=force (*)
''Implemented in v1.16.2''
This command forces the object that issues it to detach itself from the avatar. It is there as a convenience to avoid a race condition when calling @clear then llDetachFromAvatar(), sometimes the object could detach itself before clearing its restrictions, making it reattach automatically after a while. With this command one can issue a @clear,detachme=force to be sure @clear is executed first.

===Clothing and Attachments (Shared Folders)===

* '''''Allow/prevent wearing clothes and attachments that are not part of the #RLV folder''''' : @unsharedwear=<y/n>
''Implemented in v2.5''
When prevented, no object, piece of clothing or bodypart can be worn unless it is part of the #RLV folder (i.e. "shared").

* '''''Allow/prevent removing clothes and attachments that are not part of the #RLV folder''''' : @unsharedunwear=<y/n>
''Implemented in v2.5''
When prevented, no object, piece of clothing or bodypart can be removed from the avatar unless it is part of the #RLV folder (i.e. "shared").

* '''''Get the list of shared folders in the avatar's inventory''''' : @getinv[:folder1/.../folderN]=<channel_number>
''Implemented in v1.11, added sub-folders in v1.13''
Makes the viewer automatically answer the list of folders contained into the folder named "#RLV" (if it exists), immediately on the chat channel number <channel_number> that the script can listen to. If folders are specified, it will give the list of sub-folders contained into the folder located at that path instead of the shared root (example : "@getinv:Restraints/Leather cuffs/Arms=2222"). Always use a positive integer. Remember that regular viewers do not answer anything at all so remove the listener after a timeout.

The answer is a list of names, separated by commas (","). Folders which names begin with a dot (".") will be ignored.

* '''''Get the list of shared folders in the avatar's inventory, with information about worn items''''' : @getinvworn[:folder1/.../folderN]=<channel_number>
''Implemented in v1.15''
Makes the viewer automatically answer the list of folders contained into the folder named "#RLV" (if it exists), immediately on the chat channel number <channel_number> that the script can listen to. If folders are specified, it will give the list of sub-folders contained into the folder located at that path instead of the shared root (example : "@getinvworn:Restraints/Leather cuffs/Arms=2222"). Always use a positive integer. Remember that regular viewers do not answer anything at all so remove the listener after a timeout.

The answer is a comma-separated list of names, each one followed with a pipe ("|") and two digits. The current folder is put in first position (as opposed to @getinv which does not show the current folder, obviously), but without a name, only the pipe and the two digits.

Object : "@getinvworn:Restraints/Leather cuffs=2222"
Viewer : "|02,Arms|30,Legs|10"

Folders which names begin with a dot (".") will be ignored. The two digits are calculated as follows :

First digit : Proportion of items worn in the corresponding folder (including no-mod items). In this example, the "3" of "30" means "all the items in the "Arms" folder are currently worn, while the "1" of "10" means "no item in the Legs folder is currently worn, but there are items to wear".

Second digit : Proportion of items globally worn in all the folders contained inside the corresponding folder. In this example, the "2" of "02" means "some items are worn in some of the folders contained into "Leather cuffs".

The digits, comprised between 0 and 3 included, have the following meaning :

* 0 : No item is present in that folder
* 1 : Some items are present in that folder, but none of them is worn
* 2 : Some items are present in that folder, and some of them are worn
* 3 : Some items are present in that folder, and all of them are worn

* '''''Get the path to a shared folder by giving a search criterion''''' : @findfolder:part1[&&...&&partN]=<channel_number>
''Implemented in v1.13.1''
Makes the viewer automatically answer the path to the first shared folder which name contains <part1> and <part2> and ... and <partN>, immediately on the chat channel number <channel_number> that the script can listen to. The search is in depth first, notice the separator which is "&&" like "and". Always use a positive integer. Remember that regular viewers do not answer anything at all so remove the listener after a timeout. It does not take disabled folders into account (folders which name begins with a dot "."), nor folders which name begins with a tilde ("~"). The answer is a list of folders, separated by slashes ('/').

* '''''Force attach items contained inside a shared folder''''' : @attach:<folder1/.../folderN>=force (*)
''Implemented in v1.11, added no-mod items in v1.12, added sub-folders in v1.13''
Forces the viewer to attach every object and wear every piece of clothing contained inside the folder located at the specified path (which must be under "#RLV"). Objects names '''must''' contain the name of their target attachment point or they won't be attached. Each no-modify object '''must''' be contained inside a folder (one object per folder), which name contains the name of its target attachment point since it can't be renamed. Names cannot begin with a dot (".") since such folders are invisible to the scripts.

Attachment point names are the same as the ones contained into the "Attach To" submenu : "skull", "chest", "l forearm"...

Note 1 : Folder names '''can''' contain slashes, and will be chosen in priority when able (for instance, if "@attach:Restraints/cuffs=force" is issued, the "Restraints/cuffs" folder will be chosen before a "cuffs" folder contained inside a "Restraints" parent folder.

Note 2 : If the name of a folder begins with a plus sign ("+"), then this command will act exactly like @attachover. This rule can be changed through the use of the "RestrainedLoveStackWhenFolderBeginsWith" debug setting.

'''Attention''' : This command will likely change in the future, to revert back to how it used to behave in version 1.x, i.e. never add an object if the target attachment point is already taken, but rather replace the old object. The current behaviour is intended to be ensured by @attachoverorreplace and its derivatives. For now @attachoverorreplace is a synonym to @attach, but this won't always be the case. In other words, if you intend to make your script always replace existing attachments when attaching new ones, use @attach. If you want your script to always make attachments stack, use @attachover. If you want to give the user the choice through the name of the folder (as indicated above, by prepending the name by a "+" sign by default), use @attachoverorreplace.

* '''''Force attach items contained inside a shared folder, without replacing what is already being worn''''' : @attachover:<folder1/.../folderN>=force (*)
''Implemented in v2.1.2 and v1.24''
This command works exactly like @attach described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.

* '''''Force attach items contained inside a shared folder''''' : @attachoverorreplace:<folder1/.../folderN>=force (*)
''Implemented in v2.5''
This command works exactly like @attach described hereabove, it is a synonym.

* '''''Force attach items contained inside a shared folder, and its children recursively''''' : @attachall:<folder1/.../folderN>=force (*)
''Implemented in v1.15''
This command works exactly like @attach described hereabove, but also attaches whatever is contained into children folders.

* '''''Force attach items contained inside a shared folder, and its children recursively, without replacing what is already being worn''''' : @attachallover:<folder1/.../folderN>=force (*)
''Implemented in v2.1.2 and v1.24''
This command works exactly like @attachall described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.

* '''''Force attach items contained inside a shared folder, and its children recursively''''' : @attachalloverorreplace:<folder1/.../folderN>=force (*)
''Implemented in v2.5''
This command works exactly like @attachall described hereabove, it is a synonym.

* '''''Force detach items contained inside a shared folder''''' : @detach:<folder_name>=force (*)
''Implemented in v1.11''
Forces the viewer to detach every object and unwear every piece of clothing contained inside <folder_name>(which must be directly under "#RLV"). If "@detach" is used with an attachment point name (skull, pelvis... see above), it takes priority over this way of detaching since it is the same command.

* '''''Force detach items contained inside a shared folder, and its children recursively''''' : @detachall:<folder1/.../folderN>=force (*)
''Implemented in v1.15''
This command works exactly like @detach described hereabove, but also detaches whatever is contained into children folders.

* '''''Get the path to the shared folder containing a particular object/clothing worn on a point''''' : @getpath[:<attachpt> or <clothing_layer>]=<channel_number>
''Implemented in v1.16''
Makes the viewer automatically answer the path to the shared folder containing the item that :
** issues this command if no option is set
** is attached on the attach point provided in the option field, ex : @getpath:spine=2222 => "Restraints/Collar"
** is worn on the clothing layer provided in the option field, ex : @getpath:pants=2222 => "Casual/Jeans/Tight"
Always use a positive integer. Remember that regular viewers do not answer anything at all so remove the listener after a timeout. It does not take disabled folders into account (folders which name begins with a dot "."). The answer is a list of folders, separated by slashes ('/').

Please note : As version 1.40.4 is now live on the main grid, wearing several objects on the same attachment point is now possible. Therefore this command does not make much sense anymore since it can only respond with one folder, while the several objects could belong to several folders. Therefore it is better to use @getpathnew, since @getpath will slowly become deprecated as more and more users switch to 2.1 and beyond.

* '''''Get the all paths to the shared folders containing the objects/clothing worn on a point''''' : @getpathnew[:<attachpt> or <clothing_layer>]=<channel_number>
''Implemented in v2.1 and v1.24''
Makes the viewer automatically answer the paths to the shared folders containing the item(s) that :
** issues this command if no option is set
** are attached on the attach point provided in the option field, ex : @getpathnew:spine=2222 => "Restraints/Collar,Jewelry/Cute necklace"
** is worn on the clothing layer provided in the option field, ex : @getpathnew:pants=2222 => "Casual/Jeans/Tight"
Always use a positive integer. Remember that regular viewers do not answer anything at all so remove the listener after a timeout. It does not take disabled folders into account (folders which name begins with a dot "."). The answer is a list of folders, separated by slashes ('/'), if several paths must be returned because several outfits are concerned, they are organized in a list of strings separated by commas (',').

This command has been added to replace @getpath, since in 2.1 several objects can be worn on the same attachment point.

* '''''Force attach items contained into a shared folder that contains a particular object/clothing''''' : @attachthis[:<attachpt> or <clothing_layer>]=force (*)
''Implemented in v1.16''
This command is a shortcut for a @getpath followed with an @attach command (this saves a listener and a timeout).

* '''''Force attach items contained inside a shared folder, without replacing what is already being worn''''' : @attachthisover[:<attachpt> or <clothing_layer>]=force (*)
''Implemented in v2.1.2 and v1.24''
This command works exactly like @attachthis described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.

* '''''Force attach items contained inside a shared folder''''' : @attachthisoverorreplace[:<attachpt> or <clothing_layer>]=force (*)
''Implemented in v2.5''
This command works exactly like @attachthis described hereabove, it is a synonym.

* '''''Force attach items contained into a shared folder that contains a particular object/clothing, and its children folders''''' : @attachallthis[:<attachpt> or <clothing_layer>]=force (*)
''Implemented in v1.16''
This command is a shortcut for a @getpath followed with an @attachall command (this saves a listener and a timeout).

* '''''Force attach items contained inside a shared folder, without replacing what is already being worn''''' : @attachallthisover[:<attachpt> or <clothing_layer>]=force (*)
''Implemented in v2.1.2 and v1.24''
This command works exactly like @attachallthis described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.

* '''''Force attach items contained inside a shared folder''''' : @attachallthisoverorreplace[:<attachpt> or <clothing_layer>]=force (*)
''Implemented in v2.5''
This command works exactly like @attachallthis described hereabove, it is a synonym.

* '''''Force detach items contained into a shared folder that contains a particular object/clothing''''' : @detachthis[:<attachpt> or <clothing_layer>]=force (*)
''Implemented in v1.16''
This command is a shortcut for a @getpath followed with a @detach command (this saves a listener and a timeout).

* '''''Force detach items contained into a shared folder that contains a particular object/clothing, and its children folders''''' : @detachallthis[:<attachpt> or <clothing_layer>]=force (*)
''Implemented in v1.16''
This command is a shortcut for a @getpath followed with a @detachall command (this saves a listener and a timeout).

* '''''Allow/prevent removing some folders''''' : @detachthis[:<layer>|<attachpt>|<path_to_folder>]=<y/n>
''Implemented in v2.3 and v1.25''
When prevented, the user is unable to remove a folder if either of these conditions is filled :
- no option is specified and the folder contains the object that issues this restriction
- the "layer" option is set (shirt, pants...) and the folder contains a piece of clothing that is worn on this layer
- the "attachpt" option is set (l forearm, spine...) and the folder contains an attachment that is worn on this point
- the "path_to_folder" option is set and the folder corresponds to this location

Moreso, this folder or these folders cannot be renamed, moved, deleted or modified.

* '''''Allow/prevent removing some folders and their children''''' : @detachallthis[:<layer>|<attachpt>|<path_to_folder>]=<y/n>
''Implemented in v2.3 and v1.25''
These commands do exactly like @detachthis, but also apply to their children folders recursively.

* '''''Allow/prevent wearing some folders''''' : @attachthis:<layer>|<attachpt>|<path_to_folder>=<y/n>
''Implemented in v2.3 and v1.25''
When prevented, the user is unable to attach a folder if either of these conditions is filled :
- the "layer" option is set (shirt, pants...) and the folder contains a piece of clothing that is meant to be worn on this layer
- the "attachpt" option is set (l forearm, spine...) and the folder contains an attachment that is meant to be worn on this point
- the "path_to_folder" option is set and the folder corresponds to this location

Moreso, this folder or these folders cannot be renamed, moved, deleted or modified.

* '''''Allow/prevent wearing some folders and their children''''' : @attachallthis[:<layer>|<attachpt>|<path_to_folder>]=<y/n>
''Implemented in v2.3 and v1.25''
These commands do exactly like @attachthis, but also apply to their children folders recursively.

* '''''Remove/add exceptions to the detachallthis restriction, for one folder only''''' : "@detachthis_except:<folder>=<rem/add>"
''Implemented in v2.5''
When adding an exception, the user can remove the items contained into the indicated folder.

* '''''Remove/add exceptions to the detachallthis restriction, for one folder and its children''''' : "@detachallthis_except:<folder>=<rem/add>"
''Implemented in v2.5''
When adding an exception, the user can remove the items contained into the indicated folder, or in any of its children.

* '''''Remove/add exceptions to the attachallthis restriction, for one folder only''''' : "@attachthis_except:<folder>=<rem/add>"
''Implemented in v2.5''
When adding an exception, the user can wear the items contained into the indicated folder.

* '''''Remove/add exceptions to the attachallthis restriction, for one folder and its children''''' : "@attachallthis_except:<folder>=<rem/add>"
''Implemented in v2.5''
When adding an exception, the user can wear the items contained into the indicated folder, or in any of its children.

Note : These exceptions will be taken into account only for the restrictions that have been issued by the '''same object''', you cannot put such an exception to a restriction issued by another object.

Note : The viewer checks which exception or restriction is the "closest parent" in the folders hierarchy to the folder that the user is trying to wear or remove. If the closest is an @attach[all]this_except or a @detach[all]this_except exception , then the folder can be worn or removed respectively. If the closest is an @attach[all]this or a @detach[all]this restriction, then the folder is locked, no matter how many exceptions are pointing on the folders that are parent to this one.

Example :
A script issues a @attachallthis:=n restriction, preventing the whole #RLV folder and its children from being attached. It also issues a @detachallthis:=n restriction, preventing the whole #RLV folder and its children from being removed as well.
Therefore the #RLV folder is now completely frozen.

However, the same object issues a @attachallthis:Jewelry/Gold=add exception, then a @detachallthis:Jewelry/Gold=add one, making the Jewelry/Gold folder available for wearing and removing.
Finally, it issues a @attachallthis:Jewelry/Gold/Watch=n restriction followed by a @detachallthis:Jewelry/Gold/Watch=n restriction.
As a result, the user can wear and remove only what is contained inside the Jewelry/Gold folder, except what is in Jewelry/Gold/Watch, and the rest is out of reach.

===Touch===

* '''''Allow/prevent touching objects located further than 1.5 meters away from the avatar''''' : @fartouch=<y/n>
''Implemented in v1.11''
When prevented, the avatar is unable to touch/grab objects from more than 1.5 m away, this command makes restraints more realistic since the avatar litterally has to press against the object in order to click on it.

* '''''Allow/prevent touching objects located further than 1.5 meters away from the avatar''''' : @touchfar=<y/n>
''Implemented in v2.4''
This command is a synonym of @fartouch

* '''''Allow/prevent touching any objects''''' : @touchall=<y/n>
''Implemented in v2.4''
When prevented, the avatar is unable to touch/grab any object and attachment. This does not apply to HUDs.

* '''''Allow/prevent touching objects in-world''''' : @touchworld=<y/n>
''Implemented in v2.4''
When prevented, the avatar is unable to touch/grab objects rezzed in-world, i.e. not attachments and HUDs.

* '''''Remove/add exceptions to the touchworld prevention''''' : "@touchworld:<UUID>=<rem/add>"
''Implemented in v2.5''
When adding an exception, the user can touch this object in particular.

* '''''Allow/prevent touching one object in particular''''' : @touchthis:<UUID>=<rem/add>
''Implemented in v2.5''
When prevented, the avatar is unable to touch/grab the object which UUID corresponds to the one specified in the command.

* '''''Remove/add an exception to the touch* preventions, for one object only''''' : "@touchme=<rem/add>"
''Implemented in v2.6''
When adding such an exception, the user can touch this object in particular.

* '''''Allow/prevent touching attachments''''' : @touchattach=<y/n>
''Implemented in v2.4''
When prevented, the avatar is unable to touch attachments (theirs and other avatars'), but this does not apply to HUDs.

* '''''Allow/prevent touching one's attachments''''' : @touchattachself=<y/n>
''Implemented in v2.4''
When prevented, the avatar is unable to touch their own attachments (theirs but can touch other people's), but this does not apply to HUDs.

* '''''Allow/prevent touching other people's attachments''''' : @touchattachother=<y/n>
''Implemented in v2.4''
When prevented, the avatar is unable to touch other people's attachments (but they can touch their owns). This does not apply to HUDs.

===Location===

* '''''Allow/prevent viewing the world map''''' : @showworldmap=<y/n>
''Implemented in v1.11''
When prevented, the avatar is unable to view the world map, and it closes if it is open when the restriction becomes active.

* '''''Allow/prevent viewing the mini map''''' : @showminimap=<y/n>
''Implemented in v1.11''
When prevented, the avatar is unable to view the mini map, and it closes if it is open when the restriction becomes active.

* '''''Allow/prevent knowing the current location''''' : @showloc=<y/n>
''Implemented in v1.12''
When prevented, the user is unable to know where they are : the world map is hidden, the parcel and region name on the top menubar are hidden, they can't create landmarks, nor buy the land, nor see what land they have just left after a teleport, nor see the location in the About box, and even system and object messages are obfuscated if they contain the name of the region and/or the name of the parcel. However, [[llOwnerSay]] calls are ''not'' obfuscated so radars ''will'' still work (and RL commands as well).

===Name Tags and Hovertext===

* '''''Allow/prevent seeing the names of the people around''''' : @shownames=<y/n>
''Implemented in v1.12.2, added more dummy names in v1.16''
When prevented, the user is unable to know who is around. The names don't show on the screen, the names on the chat are replaced by "dummy" names such as "Someone", "A resident", the tooltips are hidden, the pie menu is almost useless so the user can't get the profile directly etc.

* '''''Allow/prevent seeing all the hovertexts''''' : @showhovertextall=<y/n>
''Implemented in v1.19''
When prevented, the user is unable to read any hovertext (2D text floating above some prims).

* '''''Allow/prevent seeing one hovertext in particular''''' : @showhovertext:<UUID>=<y/n>
''Implemented in v1.19''
When prevented, the user is unable to read the hovertext floating above the prim which id is UUID. This is made that way so that the restriction can be issued on an object, by another one (unlike @detach which can only set this restriction on itself).

* '''''Allow/prevent seeing the hovertexts on the HUD of the user''''' : @showhovertexthud=<y/n>
''Implemented in v1.19''
When prevented, the user is unable to read any hovertext showing over their HUD objects, but will be able to see the ones in-world.

* '''''Allow/prevent seeing the hovertexts in-world''''' : @showhovertextworld=<y/n>
''Implemented in v1.19''
When prevented, the user is unable to read any hovertext showing over their in-world objects, but will be able to see the ones over their HUD.

===Group===

* '''''Force the agent to change the active group''''' : @setgroup:<group_name>=force
''Implemented in v2.5''
Forces the agent to change the active group, to the specified one. Of course, they must already be a member of this group. If <group_name> is "none", then the agent will deactivate the current group and not show any group tag at all.

* '''''Allow/prevent activating a group''''' : @setgroup=<y/n>
''Implemented in v2.5''
When prevented, the user is unable to change the active group.

* '''''Get the name of the active group''''' : @getgroup=<channel_number>
''Implemented in v2.5''
Makes the viewer automatically answer the name of the currently active group, 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 answer will simply be "none" if no group is active at the time. Please note that there is no way to obtain the UUID of the group, only the name.

===Viewer Control===

* '''''Allow/prevent changing some debug settings''''' : @setdebug=<y/n>
''Implemented in v1.16''
When prevented, the user is unable to change some viewer debug settings (Advanced > Debug Settings). As most debug settings are either useless or critical to the user's experience, a whitelist approach is taken : only a few debug settings are locked, the others are always available and untouched. At the time of this writing, the allowed debug settings are :
** AvatarSex (0 : Female, 1 : Male) : gender of the avatar at creation.
** RenderResolutionDivisor (1 -> ...) : "blurriness" of the screen. Combined to clever @setenv commands, can simulate nice effects. Note: renderresolutiondivisor is a Windlight only option (Basic Shaders must be enabled in graphics preferences) and as such, is not available in v1.19.0.5 or older viewers.

* '''''Force change a debug setting''''' : @setdebug_<setting>:<value>=force (*)
''Implemented in v1.16''
Forces the viewer to change a particular debug setting and set it to <value>. This command is actually a package of many sub-commands, that are regrouped under "@setdebug_...", for instance "@setdebug_avatarsex:0=force", "@setdebug_renderresolutiondivisor:64=force" etc.

See the list of allowed debug settings in the @setdebug command hereabove.

* '''''Get the value of a debug setting''''' : @getdebug_<setting>=<channel_number>
''Implemented in v1.16''
Makes the viewer automatically answer the value of a debug setting, 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 answer is the value that has been set with the <setting> part of the matching @setdebug command, or by hand.

See the list of allowed debug settings in the @setdebug command hereabove.

* '''''Allow/prevent changing the environment settings''''' : @setenv=<y/n>
''Implemented in v1.14''
When prevented, the user is unable to change the viewer environment settings (World > Environment Settings > Sunrise/Midday/Sunset/Midnight/Revert to region default/Environment editor are all locked out).

* '''''Force change an environment setting''''' : @setenv_<setting>:<value>=force (*)
''Implemented in v1.14''
Forces the viewer to change a particular environment setting (time of day or Windlight) and set it to <value>. This command is actually a package of many sub-commands, that are regrouped under "@setenv_...", for instance "@setenv_daytime:0.5=force", "@setenv_bluehorizonr:0.21=force" etc.

This command (like any other "force" command) is silently discarded if the corresponding restriction has been set, here "@setenv", but in this case the restriction is ignored if the change is issued from the object that has created it. In other words, a collar can restrict environment changes, yet force a change by itself, while another object could not do it until the collar lifts the restriction.

Although a range is specified for every value, no check is made in the viewer so a script can do what the UI can't do, for interesting effects. Use at your own risk, though. The ranges indicated here are merely the ones available on the sliders on the Environment Editor, for reference.

Each particular sub-command works as follows (the names are chosen to be as close to the Windlight panels of the viewer as possible) :

{| border="1" cellpadding="5"
| '''@setenv_XXX:<value>=force where XXX is...''' || '''<value> range''' || '''Sets...'''
|-
| daytime || 0.0-1.0 and <0 || Time of day (sunrise:0.25, midday:0.567, sunset:0.75, midnight:0.0, set back to region default:<0). '''Attention, resets all other Windlight parameters'''
|-
| preset || String || A Preset environment, e.g. Gelatto, Foggy. '''Attention, loading a Preset is heavy on the viewer and can slow it down for a short while, don't do it every second'''
|-
| ambientr || 0.0-1.0 || Ambient light, Red channel
|-
| ambientg || 0.0-1.0 || Ambient light, Green channel
|-
| ambientb || 0.0-1.0 || Ambient light, Blue channel
|-
| ambienti || 0.0-1.0 || Ambient light, Intensity
|-
| bluedensityr || 0.0-1.0 || Blue Density, Red channel
|-
| bluedensityg || 0.0-1.0 || Blue Density, Green channel
|-
| bluedensityb || 0.0-1.0 || Blue Density, Blue channel
|-
| bluedensityi || 0.0-1.0 || Blue Density, Intensity
|-
| bluehorizonr || 0.0-1.0 || Blue Horizon, Red channel
|-
| bluehorizong || 0.0-1.0 || Blue Horizon, Green channel
|-
| bluehorizonb || 0.0-1.0 || Blue Horizon, Blue channel
|-
| bluehorizoni || 0.0-1.0 || Blue Horizon, Intensity
|-
| cloudcolorr || 0.0-1.0 || Cloud color, Red channel
|-
| cloudcolorg || 0.0-1.0 || Cloud color, Green channel
|-
| cloudcolorb || 0.0-1.0 || Cloud color, Blue channel
|-
| cloudcolori || 0.0-1.0 || Cloud color, Intensity
|-
| cloudcoverage || 0.0-1.0 || Cloud coverage
|-
| cloudx || 0.0-1.0 || Cloud offset X
|-
| cloudy || 0.0-1.0 || Cloud offset Y
|-
| cloudd || 0.0-1.0 || Cloud density
|-
| clouddetailx || 0.0-1.0 || Cloud detail X
|-
| clouddetaily || 0.0-1.0 || Cloud detail Y
|-
| clouddetaild || 0.0-1.0 || Cloud detail density
|-
| cloudscale || 0.0-1.0 || Cloud scale
|-
| cloudscrollx || 0.0-1.0 || Cloud scroll X
|-
| cloudscrolly || 0.0-1.0 || Cloud scroll Y
|-
| densitymultiplier || 0.0-0.9 || Density multiplier of the fog
|-
| distancemultiplier || 0.0-100.0 || Distance multiplier of the fog
|-
| eastangle || 0.0-1.0 || Position of the east, 0.0 is normal
|-
| hazedensity || 0.0-1.0 || Density of the haze
|-
| hazehorizon || 0.0-1.0 || Haze at the horizon
|-
| maxaltitude || 0.0-4000.0 || Maximum altitude of the fog
|-
| scenegamma || 0.0-10.0 || Overall gamma, 1.0 is normal
|-
| starbrightness|| 0.0-2.0 || Brightness of the stars
|-
| sunglowfocus || 0.0-0.5 || Focus of the glow of the sun
|-
| sunglowsize || 1.0-2.0 || Size of the glow of the sun
|-
| sunmooncolorr || 0.0-1.0 || Sun and moon, Red channel
|-
| sunmooncolorg || 0.0-1.0 || Sun and moon, Green channel
|-
| sunmooncolorb || 0.0-1.0 || Sun and moon, Blue channel
|-
| sunmooncolori || 0.0-1.0 || Sun and moon, Intensity
|-
| sunmoonposition || 0.0-1.0 || Position of the sun/moon, different from "daytime", '''use this to set the apparent sunlight after loading a Preset'''
|}

Note: from the above settings, only the "daytime" one is supported by v1.19.0 (or older) viewers implementing RestrainedLove v1.14 and later. The other settings are ignored. This is because these viewers do not implement the Windlight renderer.

(*) Silently discarded if the user is prevented from doing so by the corresponding restriction. This is on purpose.
Ex : Force detach won't work if the object is undetachable. Force undress won't work if the user is prevented from undressing.

* '''''Get the value of an environment setting''''' : @getenv_<setting>=<channel_number>
''Implemented in v1.15''
Makes the viewer automatically answer the value of an environment setting, 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 answer is the value that has been set with the <setting> part of the matching @setenv command, or by hand. See the table hereabove for a list of settings.<br />
Note: only @getenv_daytime is supported by v1.19.0 (or older, i.e. non Windlight) viewers implementing RestrainedLove v1.15 and later.

==Important note about the global behaviours such as sendchat==
Such behaviours are global, which means they don't depend on a particular object. However, they are triggered by objects with a set [[UUID]] which can change, and several objects can add the same behaviour, which will be stored several times as the [[UUID]]s are different.

This has a nice side effect : when wearing 2 locked devices that prevent chat, it is necessary to unlock them both to be able to chat again. But it has a nasty side effect, too : if the item changes [[UUID]] (for instance it was derezzed and rezzed again), and it doesn't allow chat beforehand, then the user will have to wait a short moment because the rule stays "orphaned" (its [[UUID]] is defunct) until the '''garbage collector''' kicks in.

Please note : Since 1.16.1 any locked object that is kicked off by any mean (llAttachToAvatar for example) will be reattached automatically by the viewer after a few seconds. This means that calling @clear on detaching will actually unlock the object, which will have to be relocked after being reattached. It is therefore not recommended anymore to call @clear on detach, as opposed to pre-1.16.1 versions.

==Shared Folders==

Since v1.11, the viewer can "share" some of your items with scripts in world in order to let them force you to attach, detach and list what you have shared.

"Share" does NOT mean they will be taken by other people if they want to (some of the items may be no-transfer anyway), but only that they can force YOU to wear/unwear them at will through the use of a script YOUR restraints contain. They will remain in your inventory. In fact, this feature would be best named "Exposed folder".

To do this :
* Create a folder named "#RLV" (without the quotes) directly under "My Inventory" (right-click on "My Inventory", select "New Folder"). We'll call this folder the "shared root".
* Move a folder containing restraints or other attachments directly into this new folder.
* Wear the contents of that folder, that's it !

So it would look like this :

My Inventory
|- #RLV
| |- cuffs
| | |- left cuff (l forearm) (no copy)
| | \- right cuff (r forearm) (no copy)
| \- gag
| \- gag (mouth) (no copy)
|- Animations
|- Body Parts
.
.
.

For example : If you're owning a set of RR Straps and want to share them, just move the folder "Straps BOXED" under the shared root.

Either wear all the items of the folders you have just moved (one folder at a time !) or rename your items yourself, so that each item name contains the name of the target attachment point. For example : "left cuff (l forearm)", "right ankle cuff (r lower leg)". Please note that no-modify items are a bit more complex to share, because they cannot be renamed either by you or by the viewer. More on that below.

The attachment point name is the same as the one you find in the "Attach To" menu of your inventory, and is case insensitive (for example : "chest", "skull", "stomach", "left ear", "r upper arm"...). If you wear the item without renaming it first it will be renamed automatically, but only if it is in a shared folder, and does not contain any attachment point name already, and is mod. If you want to wear it on another attachment point, you'll need to rename it by hand first.

Pieces of clothing are treated exactly the same way (in fact they can even be put in the folder of a set of restraints and be worn with the same command). Shoes, for instance, are a good example of mixed outfits : some attachments and the Shoes layer. Clothes are NOT renamed automatically when worn, since their very type decides where they are to be worn (skirt, jacket, undershirt...).

HOW TO SHARE NO-MODIFY ITEMS :
As you already know, no-mod items cannot be renamed so the technique is a bit more complex. Create a sub-folder inside the outfit folder (such as "cuffs" in the example above), put ONE no-modify item in it. When wearing the object, you'll see the folder itself be renamed (that's why you must not put more than one object inside it). So if your outfit contains several no-mod objects, you'll need to create as many folders and put the no-mod objects in them, one in each folder.

Example with no-modify shoes :

My Inventory
|- #RLV
| \- shoes
| |- left shoe (left foot)
| | \- left shoe (no modify) (no transfer) <-- no-mod object
| |- right shoe (right foot)
| | \- right shoe (no modify) (no transfer) <-- no-mod object
| \- shoe base (no modify) (no transfer) <-- this is not an object
|- Animations
|- Body Parts
.
.
.

GOTCHAS :
* Do NOT put a comma (',') in the name of the folders under the shared root or it would screw the list up.
* Don't forget to rename the items in the shared folders (or to wear these items at least once to have them be renamed automatically) or the force attach command will appear to do nothing at all.
* Avoid cluttering the shared root with many folders, since some scripts may rely on the list they got with the @getinv command and chat messages are limited to 1023 characters. Choose wisely, and use short names. But with 9 characters per folder name average, you can expect to have about 100 folders available.
* Remember to put no-modify items in sub-folders, one each, so their names can be used by the viewer do find out where to attach them. They can't be shared like modify items since they can't be renamed, and the outfit folder itself will not be renamed (since it contains several items).

'''''Accept sub-folders given via llGiveInventoryList() into the shared folder''''' :

Starting with RestrainedLove v1.16.2, you may give a list of items to a victim and have them stored as a sub-folder inside the #RLV folder (thus allowing you to @attach the given items later).

Issuing a llGiveInventoryList(victim_id, "#RLV/~subfolder_name", list_of_stuff) command in a script makes a standard Keep/Discard/Mute dialog appear in the viewer of the victim (the avatar which key is victim_id).

Should the victim accept the offer, the list_of_stuff items are put into a new sub-folder of the #RLV folder. The name of this sub-folder is "~subfolder_name" (it is the scripter's responsibility to use unique sub-folder names: if the name is the same as an existing sub-folder, two sub-folders with the same name will appear in the #RLV folder).

Note that the tilde character *must* be used as the first character for the name of the sub-folder (this is so that the victim can easily spot any sub-folder given to them in this way, and so that such sub-folder names appear last in the #RLV folder).

Note also that this feature may be disabled by the user, (by setting the RestrainedLoveForbidGiveToRLV debug setting to TRUE): in this case the given items are put into a folder named "#RLV/~subfolder_name" at the root of the inventory instead of inside the #RLV folder.

Since the user may either refuse the offer or have the feature disabled in their viewer, and since SL may take quite some time to perform the actual transfer of the objects on laggy days, you must check that the given folder is present (with @getinv), before attempting to @attach the given objects.

==For your information==
Here is how it works internally, for a better understanding of the gotchas you may encounter :
* Each command is parsed into a '''Behaviour''' (ex: "remoutfit"), an '''Option''' (ex: "shirt") and a '''Param''' (ex: "force") and comes from an [[UUID]] (the unique identifier of the emitting object).

* There are two types of commands : '''one-shot''' commands (those which Param is "force" and those which Param is a number such as the channel number of a "version" call) and '''rules''' (those which Param is "y", "n", "add" or "rem"). "clear" is special but can be seen as a one-shot command.

* When the command takes a channel number, this number may be either strictly positive or (for RestrainedLove v1.23a (@versionnum = 1230001) and above) strictly negative. Using channel 0 is not allowed. Note that RestrainedLove can send a maximum of 255 characters on negative channels, while it can send up to 1023 characters on positive channels. Negative channels are useful to prevent the user from cheating, for example when asking for the @versionnum (since the user could use a non-RestrainedLove viewer and make the RestrainedLove devices believe they run within a RestrainedLove viewer by spoofing the reply to the version command on a positive channel, which they can't do on negative channels). Positive channels are best used for commands that may return large reply strings (@getpath, for example).

* Parameters "n" and "add" are '''exactly equal''' and are treated '''exactly the same way''', they are just '''synonyms'''. Same goes for "y" and "rem". The only purpose is to distinguish rules ("sendchannel=n") from exceptions ("sendchannel:8=add") in a script for clarity.

* Rules are stored inside a table linking the [[UUID]] of the emitter to the rule itself. They are '''added''' when receiving a "n"/"add" Param, and '''removed''' when receiving a "y"/"rem" Param.
If '''''UUID1''''' is a collar and '''''UUID2''''' is a gag :

'''''UUID1''''' => detach, tploc, tplm, tplure, sittp

'''''UUID2''''' => detach, sendim, sendim:(keyholder)

Those two rules mean that the user cannot send IMs except to their keyholder, and cannot TP at all. Those two items are not detachable. Now if the collar sends "@sendim=n", the table becomes :

'''''UUID1''''' => detach, tploc, tplm, tplure, sittp, sendim

'''''UUID2''''' => detach, sendim, sendim:(keyholder)

If it sends "@sendim=n" a second time nothing changes, as there is a check for its existence prior to adding it. If the gag is unlocked and detached, either it sends a "@clear" or the garbage collector kicks in so the rules linked to '''''UUID2''''' disappear. However, the avatar is still unable to send IMs even to their keyholder, as the exception has disappeared as well. This is because rules linked to one object don't conflict with rules linked to another one.

* One-shot commands, on the other hand, are executed on-the-fly and are not stored.

* When logging on, the avatar stays non-operational (cannot chat, cannot move) for some time, while the user sees the progress bar. However, worn scripted objects [[rez]] in the meantime and start sending rules and commands before the viewer can execute them. Therefore it stores them in a buffer and executes them only when the user is given controls (when the progress bar disappears).

* The viewer periodically (every N seconds) checks all its rules and removes the ones linked to an [[UUID]] that does not exist around anymore ("garbage collector"). This means that rules issued by an '''unworn''' owned object will be discarded as soon as the avatar [[teleport|teleports]] elsewhere.

[[Category:Third Party Client]]
[[Category:RestrainedLove]]