https://wiki.secondlife.com/w/api.php?action=feedcontributions&user=Tonya+Souther&feedformat=atomSecond Life Wiki - User contributions [en]2024-03-28T18:11:27ZUser contributionsMediaWiki 1.36.1https://wiki.secondlife.com/w/index.php?title=LSL_Protocol/RestrainedLoveAPI&diff=1179201LSL Protocol/RestrainedLoveAPI2013-06-14T04:56:24Z<p>Tonya Souther: /* Movement */ SSA breaks @adjustheight</p>
<hr />
<div>{{LSL Header|ml=*}}<br />
=Restrained Love viewer v2.8.1 Specification=<br />
<br />
By [[User:Marine Kelley|Marine Kelley]]<br />
<br />
==Audience==<br />
<br />
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.<br />
<br />
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]]<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Architecture==<br />
<br />
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.<br />
<br />
The syntax of a message is:<br />
<br />
: <code>@<command1>[:option1]=<param1>,<command2>[:option2]=<param2>,...,<commandN>[:optionN]=<paramN></code><br />
<br />
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.<br />
<br />
: 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
{{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.}}<br />
<br />
==List of commands==<br />
<br />
'''Note:''' These commands are not case-sensitive but are spacing-sensitive. In other words, "@detach = n" will '''not''' work.<br />
<br />
'''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.<br />
<br />
'''Footnotes:''' "(*)" are footnotes and will be explained at the end of the list<br />
<br />
===Version Checking===<br />
<br />
* '''''Automated version checking''''' : "@version=<channel_number>"<br />
''Implemented in v1.0b''<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
* '''''Automated version checking''''' : "@versionnew=<channel_number>"<br />
''Implemented in v1.23''<br />
<br />
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.<br />
<br />
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).<br />
<br />
'''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.<br />
<br />
<br />
* '''''Automated version number checking''''' : "@versionnum=<channel_number>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
* '''''Automated version checking, second way''''' : llGetAgentLanguage (key id) '''''DEPRECATED: DO NOT USE !'''''<br />
''Implemented in v1.16''<br />
<br />
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).<br />
<br />
<br />
* '''''Manual version checking''''' : "@version"<br />
''Implemented in v1.0a''<br />
<br />
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 usually totally stealthy. However, some viewers, such as Firestorm, have the ability to send an autoreply message when someone begins typing an IM to the user. If the user has that option enabled, an IM window will open and display the auto response as soon as the @ is typed by the sender, but nothing else.<br />
<br />
===Blacklist handling===<br />
<br />
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.<br />
<br />
<br />
* '''''Automated version number checking, followed by the blacklist''''' : "@versionnumbl=<channel_number>"<br />
''Implemented in v2.8''<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
* '''''Get the contents of the blacklist, with a filter''''' : "@getblacklist[:filter]=<channel_number>"<br />
''Implemented in v2.8''<br />
<br />
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.<br />
<br />
<br />
* '''''Manual blacklist checking''''' : "@getblacklist"<br />
''Implemented in v2.8''<br />
<br />
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 usually totally stealthy, with the same caveat mentioned above under @version.<br />
<br />
===Miscellaneous===<br />
<br />
* '''''Start/stop notifications on a private channel''''' : "@notify:<channel_number>[;word]=<rem/add>"<br />
''Implemented in v1.20, improved in v2.2 (and v1.24)''<br />
<br />
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.<br />
<br />
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 :<br />
<br />
:* /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).<br />
<br />
:* /accepted_in_inv inv_offer <folder> : The folder has been accepted but is not shared.<br />
<br />
:* /declined inv_offer <folder> : The folder has been declined and/or the user has pressed "Block" (formerly "Mute").<br />
<br />
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.<br />
<br />
Note 2 : Since v2.5 the viewer also sends notifications when wearing outfits :<br />
<br />
:* /worn legally <layer> : The avatar has just worn a piece of clothing on the indicated layer.<br />
<br />
:* /unworn legally <layer> : The avatar has just removed a piece of clothing from the indicated layer.<br />
<br />
:* /attached legally <attach_point_name> : The avatar has just attached an object to the indicated attachment point.<br />
<br />
:* /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.<br />
<br />
:* /detached legally <attach_point_name> : The avatar has just detached an object from the indicated attachment point.<br />
<br />
:* /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.<br />
<br />
<br />
* '''''Allow/deny permissive exceptions''''' : "@permissive=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
'''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 !<br />
<br />
<br />
* '''''Clear all the rules tied to an object''''' : "@clear"<br />
''Implemented in v1.0a, but working only since v1.04a''<br />
<br />
This command clears all the restrictions and exceptions tied to a particular [[UUID]].<br />
<br />
'''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.<br />
<br />
Possible workarounds:<br />
:* only lift the exact restrictions you added with @clear=<pattern> <br />
:* only trigger @clear on detach when you are sure the attachment is not locked<br />
:* don't trigger @clear on detach at all and wait for the viewer to lift the set restrictions<br />
<br />
<br />
* '''''Clear a subset of the rules tied to an object''''' : "@clear=<string>"<br />
''Implemented in v1.0a, but working only since v1.04a''<br />
<br />
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<br />
<br />
<br />
* '''''Get the list of restrictions the avatar is currently submitted to''''' : @getstatus[:<part_of_rule>[;<custom_separator>]]=<channel><br />
''Implemented in v1.10, slightly tweaked in v1.16 and v2.8''<br />
<br />
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 !<br />
<br />
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.<br />
<br />
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.<br />
<br />
<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.<br />
<br />
Example : If the avatar is under tploc, tplure, tplm and sittp, here is what the script would get :<br />
@getstatus=2222 => /tploc/tplure/tplm/sittp<br />
@getstatus:sittp=2222 => /sittp<br />
@getstatus:tpl=2222 => /tploc/tplure/tplm (because "tpl" is part of "tploc", "tplure" and "tplm" but not "sittp")<br />
@getstatus:tpl;#=2222 => #tploc#tplure#tplm (because "tpl" is part of "tploc", "tplure" and "tplm" but not "sittp", and the<br />
specified separator is "#")<br />
@getstatus:;#=2222 => #tploc#tplure#tplm#sittp (because the specified separator is "#")<br />
@getstatus:;=2222 => /tploc/tplure/tplm/sittp (because the specified separator is empty, so it defaults to "/")<br />
<br />
<br />
* '''''Get the list of all the restrictions the avatar is currently submitted to''''' : @getstatusall[:<part_of_rule>[;<custom_separator>]]=<channel><br />
''Implemented in v1.15, slightly tweaked in v1.16 and v2.8''<br />
<br />
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 !<br />
<br />
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.<br />
<br />
===Movement===<br />
<br />
* '''''Allow/prevent flying''''' : @fly=<y/n><br />
''Implemented in v1.12.2''<br />
<br />
When prevented, the user is unable to fly.<br />
<br />
<br />
* '''''Allow/prevent running by double-tapping an arrow key''''' : @temprun=<y/n><br />
''Implemented in v2.7''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent always running''''' : @alwaysrun=<y/n><br />
''Implemented in v2.7''<br />
<br />
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.<br />
<br />
<br />
* '''''Force rotate the avatar to a set direction''''' : @setrot:<angle_in_radians>=force<br />
''Implemented in v1.17''<br />
<br />
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.<br />
<br />
<br />
* '''''Change the height of the avatar''''' : @adjustheight:<distance_pelvis_to_foot_in_meters>;<factor>[;delta_in_meters]=force<br />
''Implemented in v2.5''<br />
<br />
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.<br />
<br />
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]<br />
<br />
This function has been broken by Linden Lab as part of the Project Sunshine (server-side appearance/server-side baking) changes to Second Life, and will not function as expected in a SSA-capable viewer.<br />
<br />
===Chat, Emotes and Instant Messages===<br />
====Chat====<br />
* '''''Allow/prevent sending chat messages''''' : "@sendchat=<y/n>"<br />
''Implemented in v1.0b''<br />
<br />
When prevented, everything typed on [[Chat channel|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.<br />
<br />
<br />
* '''''Allow/prevent shouting''''' : "@chatshout=<y/n>"<br />
''Implemented in v1.15''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent chatting at normal volume''''' : "@chatnormal=<y/n>"<br />
''Implemented in v1.15''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent whispering''''' : "@chatwhisper=<y/n>"<br />
''Implemented in v1.15''<br />
<br />
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.<br />
<br />
<br />
* '''''Redirect public chat to private channels''''' : "@redirchat:<channel_number>=<rem/add>"<br />
''Implemented in v1.16''<br />
<br />
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.<br />
'''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).<br />
<br />
<br />
* '''''Allow/prevent receiving chat messages''''' : "@recvchat=<y/n>"<br />
''Implemented in v1.0b''<br />
<br />
When prevented, everything heard in public chat will be discarded except emotes.<br />
<br />
<br />
* '''''Allow/prevent receiving chat messages, secure way''''' : "@recvchat_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the chat message receiving prevention''''' : "@recvchat:<UUID>=<rem/add>"<br />
''Implemented in v1.01''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent receiving chat messages from someone in particular''''' : "@recvchatfrom:<UUID>=<y/n>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, everything heard in public chat from the specified avatar will be discarded except emotes.<br />
<br />
<br />
====Emotes====<br />
* '''''Remove/add an exception to the emote truncation above''''' : "@emote=<rem/add>"<br />
''Implemented in v1.01''<br />
<br />
When adding this exception, the emotes are not truncated anymore (however, special signs will still discard the message).<br />
<br />
<br />
* '''''Redirect public emotes to private channels''''' : "@rediremote:<channel_number>=<rem/add>"<br />
''Implemented in v1.19''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent seeing emotes''''' : "@recvemote=<y/n>"<br />
''Implemented in v1.19''<br />
<br />
When prevented, every emote seen in public chat will be discarded.<br />
<br />
<br />
* '''''Allow/prevent receiving emotes seen in public chat from someone in particular''''' : "@recvemotefrom:<UUID>=<y/n>"<br />
''Implemented in v2.4''<br />
<br />
When prevented, everything emote seen in public chat from the specified avatar will be discarded.<br />
<br />
<br />
* '''''Allow/prevent seeing emotes, secure way''''' : "@recvemote_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the emote seeing prevention''''' : "@recvemote:<UUID>=<rem/add>"<br />
''Implemented in v1.19''<br />
<br />
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.<br />
<br />
<br />
====Private Channels====<br />
* '''''Allow/prevent using any chat channel but certain channels''''' : @sendchannel[:<channel>]=<y/n><br />
''Implemented in v1.10''<br />
<br />
Complimentary of @sendchat, this command prevents the user from sending messages on non-public Chat channels. 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. <br />
<br />
<br />
* '''''Allow/prevent using any chat channel but certain channels, secure way''''' : @sendchannel_sec[:<channel>]=<y/n><br />
''Implemented in v1.10''<br />
<br />
Complimentary of @sendchat, this command prevents the user from sending messages on non-public channels. 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.<br />
<br />
<br />
====Instant Messages====<br />
* '''''Allow/prevent sending instant messages''''' : "@sendim=<y/n>"<br />
''Implemented in v1.0b''<br />
<br />
When prevented, everything typed in IM will be discarded and a bogus message will be sent to the receiver instead.<br />
<br />
<br />
* '''''Allow/prevent sending instant messages, secure way''''' : "@sendim_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the instant message sending prevention''''' : "@sendim:<UUID>=<rem/add>"<br />
''Implemented in v1.01''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent sending instant messages to someone in particular''''' : "@sendimto:<UUID>=<y/n>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, everything typed in IM to the specified avatar will be discarded and a bogus message will be sent instead.<br />
<br />
<br />
* '''''Allow/prevent starting an IM session with anyone''''' : "@startim=<y/n>"<br />
''Implemented in v2.6''<br />
<br />
When prevented, the user is unable to start an IM session with anyone. Sessions that are already open are not impacted though.<br />
<br />
<br />
* '''''Remove/add exceptions to the IM session start prevention''''' : "@startim:<UUID>=<rem/add>"<br />
''Implemented in v2.6''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent starting an IM session with someone in particular''''' : "@startimto:<UUID>=<y/n>"<br />
''Implemented in v2.6''<br />
<br />
When prevented, the user is unable to start an IM session with that person. Sessions that are already open are not impacted though.<br />
<br />
<br />
* '''''Allow/prevent receiving instant messages''''' : "@recvim=<y/n>"<br />
''Implemented in v1.0b''<br />
<br />
When prevented, every incoming IM will be discarded and the sender will be notified that the user cannot read them.<br />
<br />
<br />
* '''''Allow/prevent receiving instant messages, secure way''''' : "@recvim_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the instant message receiving prevention''''' : "@recvim:<UUID>=<rem/add>"<br />
''Implemented in v1.01''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent receiving instant messages from someone in particular''''' : "@recvimfrom:<UUID>=<y/n>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
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.<br />
<br />
===Teleportation===<br />
<br />
* '''''Allow/prevent teleporting to a landmark''''' : "@tplm=<y/n>"<br />
''Implemented in v1.0''<br />
<br />
When prevented, the user cannot use a [[landmark]], pick or any other preset location to [[teleport]] there.<br />
<br />
<br />
* '''''Allow/prevent teleporting to a location''''' : "@tploc=<y/n>"<br />
''Implemented in v1.0''<br />
<br />
When prevented, the user cannot use [[teleport]] to a coordinate by using the [[map]] and such.<br />
<br />
<br />
* '''''Allow/prevent teleporting by a friend''''' : "@tplure=<y/n>"<br />
''Implemented in v1.0''<br />
<br />
When prevented, the user automatically discards any [[teleport]] offer, and the avatar who initiated the offer is notified.<br />
<br />
<br />
* '''''Allow/prevent teleporting by a friend, secure way''''' : "@tplure_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the friend teleport prevention''''' : "@tplure:<UUID>=<rem/add>"<br />
''Implemented in v1.0''<br />
<br />
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.<br />
<br />
<br />
* '''''Unlimit/limit sit-tp''''' : "@sittp=<y/n>"<br />
''Implemented in v1.0''<br />
<br />
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).<br />
<br />
<br />
* '''''Allow/prevent standing up at a different location than where we sat down''''' : @standtp=<y/n><br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
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.<br />
<br />
<br />
* '''''Force-Teleport the user''''' : @tpto:<X>/<Y>/<Z>=force (*)<br />
''Implemented in v1.12''<br />
<br />
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.<br />
<br />
Here is a sample code to call that command properly :<br />
<br />
<lsl><br />
<br />
// FORCE TELEPORT EXAMPLE<br />
// Listens on channel 4 for local coordinates and a sim name<br />
// and tells your viewer to teleport you there.<br />
//<br />
// By Marine Kelley 2008-08-26<br />
// RLV version required : 1.12 and above<br />
//<br />
// HOW TO USE :<br />
// * Create a script inside a box<br />
// * Overwrite the contents of the script with this one<br />
// * Wear the box<br />
// * Say the destination coords Region/X/Y/Z on channel 4 :<br />
// Example : /4 Help Island Public/128/128/50<br />
<br />
key kRequestHandle; // UUID of the dataserver request<br />
vector vLocalPos; // local position extracted from the<br />
<br />
Init () {<br />
kRequestHandle = NULL_KEY;<br />
llListen (4, "", llGetOwner (), "");<br />
}<br />
<br />
<br />
default<br />
{<br />
state_entry () {<br />
Init ();<br />
}<br />
<br />
on_rez(integer start_param) {<br />
Init ();<br />
}<br />
<br />
listen(integer channel, string name, key id, string message) {<br />
list tokens = llParseString2List (message, ["/"], []);<br />
integer L = llGetListLength (tokens);<br />
<br />
if (L==4) {<br />
// Extract local X, Y and Z<br />
vLocalPos.x = llList2Float (tokens, 1);<br />
vLocalPos.y = llList2Float (tokens, 2);<br />
vLocalPos.z = llList2Float (tokens, 3);<br />
<br />
// Request info about the sim<br />
kRequestHandle=llRequestSimulatorData (llList2String (tokens, 0), DATA_SIM_POS);<br />
}<br />
}<br />
<br />
dataserver(key queryid, string data) {<br />
if (queryid == kRequestHandle) {<br />
// Parse the dataserver response (it is a vector cast to a string)<br />
list tokens = llParseString2List (data, ["<", ",", ">"], []);<br />
string pos_str = "";<br />
vector global_pos;<br />
<br />
// The coordinates given by the dataserver are the ones of the<br />
// South-West corner of this sim<br />
// => offset with the specified local coordinates<br />
global_pos.x = llList2Float (tokens, 0);<br />
global_pos.y = llList2Float (tokens, 1);<br />
global_pos.z = llList2Float (tokens, 2);<br />
global_pos += vLocalPos;<br />
<br />
// Build the command<br />
pos_str = (string)((integer)global_pos.x)<br />
+"/"+(string)((integer)global_pos.y)<br />
+"/"+(string)((integer)global_pos.z);<br />
llOwnerSay ("Global position : "+(string)pos_str); // Debug purposes<br />
<br />
// Fire !<br />
llOwnerSay ("@tpto:"+pos_str+"=force");<br />
}<br />
}<br />
<br />
}<br />
<br />
</lsl><br />
<br />
<br />
<br />
* '''''Remove/add auto-accept teleport offers from a particular avatar''''' : "@accepttp[:<UUID>]=<rem/add>"<br />
''Implemented in v1.15, slightly improved in v1.16''<br />
<br />
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 !<br />
<br />
===Inventory, Editing and Rezzing===<br />
<br />
* '''''Allow/prevent using inventory''''' : @showinv=<y/n><br />
''Implemented in v1.10''<br />
<br />
Forces the [[inventory]] windows to close and stay closed.<br />
<br />
<br />
* '''''Allow/prevent reading notecards''''' : @viewnote=<y/n><br />
''Implemented in v1.10''<br />
<br />
Prevents from opening [[notecards]] but does not close the ones already open.<br />
<br />
<br />
* '''''Allow/prevent opening scripts''''' : @viewscript=<y/n><br />
''Implemented in v1.22''<br />
<br />
Prevents from opening [[scripts]] but does not close the ones already open.<br />
<br />
<br />
* '''''Allow/prevent opening textures''''' : @viewtexture=<y/n><br />
''Implemented in v1.22''<br />
<br />
Prevents from opening [[textures]] (and snapshots) but does not close the ones already open.<br />
<br />
<br />
* '''''Allow/prevent editing objects''''' : "@edit=<y/n>"<br />
''Implemented in v1.03''<br />
<br />
When prevented from editing and opening objects, the Build & Edit window will refuse to open.<br />
<br />
<br />
* '''''Remove/add exceptions to the edit prevention''''' : "@edit:<UUID>=<rem/add>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
When adding an exception, the user can edit or open this object in particular.<br />
<br />
<br />
* '''''Allow/prevent rezzing inventory''''' : "@rez=<y/n>"<br />
''Implemented in v1.03''<br />
<br />
When prevented from [[rez]]zing stuff, creating and deleting objects, drag-dropping from inventory and dropping attachments will fail.<br />
<br />
<br />
* '''''Allow/prevent editing particular objects''''' : "@editobj:<UUID>=<y/n>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, the Build & Edit window will refuse to open when trying to edit or open the specified object.<br />
<br />
===Sitting===<br />
<br />
* '''''Allow/prevent standing up''''' : @unsit=<y/n><br />
''Implemented in v1.10, modified in v1.15 to prevent teleporting as well''<br />
<br />
Hides the Stand up button. From v1.15 it also prevents teleporting, which was a way to stand up.<br />
<br />
<br />
* '''''Force sit on an object''''' : @sit:<UUID>=force (*)<br />
''Implemented in v1.10''<br />
<br />
Does not work if the user is prevented from sit-tping and further than 1.5 meters away, or when prevented from unsitting.<br />
<br />
<br />
* '''''Get the UUID of the object the avatar is sitting on''''' : @getsitid=<channel_number><br />
''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)''<br />
<br />
Makes the viewer automatically answer the UUID of the object the avatar is currently sitting on, or NULL_KEY if they are not sitting.<br />
<br />
<br />
* '''''Force unsit''''' : @unsit=force (*)<br />
''Implemented in v1.10''<br />
<br />
Self-explanatory but for some reason it randomly fails, so don't rely on it for now. Further testing is needed.<br />
<br />
<br />
* '''''Allow/prevent sitting down''''' : @sit=<y/n><br />
''Implemented in v1.16.2''<br />
<br />
Prevents the user from sitting on anything, including with @sit:<UUID>=force.<br />
<br />
===Clothing and Attachments===<br />
<br />
* '''''Render an object detachable/nondetachable''''' : "@detach=<y/n>"<br />
''Implemented in v1.0a''<br />
<br />
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.<br />
<br />
<br />
* '''''Unlock/Lock an attachment point''''' : "@detach:<attach_point_name>=<y/n>"<br />
''Implemented in v1.20''<br />
<br />
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).<br />
<br />
<br />
* '''''Unlock/Lock an attachment point empty''''' : "@addattach[:<attach_point_name>]=<y/n>"<br />
''Implemented in v1.22''<br />
<br />
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.<br />
<br />
<br />
* '''''Unlock/Lock an attachment point full''''' : "@remattach[:<attach_point_name>]=<y/n>"<br />
''Implemented in v1.22''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/deny the "Wear" contextual menu''''' : "@defaultwear=<y/n><br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
* '''''Force removing attachments''''' : @detach[:attachpt]=force (*) <br />
''Implemented in v1.10''<br />
<br />
Where part is :<br />
chest|skull|left shoulder|right shoulder|left hand|right hand|left foot|right foot|spine|<br />
pelvis|mouth|chin|left ear|right ear|left eyeball|right eyeball|nose|r upper arm|r forearm|<br />
l upper arm|l forearm|right hip|r upper leg|r lower leg|left hip|l upper leg|l lower leg|stomach|left pec|<br />
right pec|center 2|top right|top|top left|center|bottom left|bottom|bottom right|neck|root<br />
If part is not specified, removes everything.<br />
<br />
<br />
* '''''Force removing attachments (alias)''''' : @remattach[:attachpt]=force (*) <br />
''Implemented in v1.22''<br />
<br />
This command is an alias to @detach[:attachpt]=force (to keep things consistent).<br />
<br />
<br />
* '''''Allow/prevent wearing clothes''''' : @addoutfit[:<part>]=<y/n><br />
''Implemented in v1.10, added skin hair and eyes in v1.10.1, added physics in 2.6.1''<br />
<br />
Where part is :<br />
gloves|jacket|pants|shirt|shoes|skirt|socks|underpants|undershirt|skin|eyes|hair|shape|alpha|tattoo|physics<br />
If part is not specified, prevents from wearing anything beyond what the avatar is already wearing.<br />
<br />
'''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.<br />
<br />
<br />
* '''''Allow/prevent removing clothes''''' : @remoutfit[:<part>]=<y/n> (underpants and undershirt are kept for teens)<br />
''Implemented in v1.10, added skin hair and eyes in v1.10.1, added physics in 2.6.1''<br />
<br />
Where part is :<br />
gloves|jacket|pants|shirt|shoes|skirt|socks|underpants|undershirt|skin|eyes|hair|shape|alpha|tattoo|physics<br />
If part is not specified, prevents from removing anything in what the avatar is wearing.<br />
<br />
'''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.<br />
<br />
<br />
* '''''Force removing clothes''''' : @remoutfit[:<part>]=force (*) (teens can't be forced to remove underpants and undershirt)<br />
''Implemented in v1.10''<br />
<br />
Where part is :<br />
gloves|jacket|pants|shirt|shoes|skirt|socks|underpants|undershirt|alpha|tattoo|physics<br />
If part is not specified, removes everything.<br />
<br />
'''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.<br />
<br />
'''Note:''' skin, shape, eyes and hair cannot be removed since they are body parts (and removing any would result in an unrezzed avatar).<br />
<br />
<br />
* '''''Get the list of worn clothes''''' : @getoutfit[:part]=<channel_number><br />
''Implemented in v1.10, added skin hair and eyes in v1.10.1, added physics in 2.6.1''<br />
<br />
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.<br />
<br />
The list of 0s and 1s corresponds to :<br />
gloves,jacket,pants,shirt,shoes,skirt,socks,underpants,undershirt,skin,eyes,hair,shape<br />
in that order.<br />
<br />
If a part is specified, answers a single 0 (empty) or 1 (occupied) corresponding to the part.<br />
Ex 1 : @getoutfit=2222 => "0011000111" => avatar is wearing pants, shirt, underpants and undershirt, and of course a skin.<br />
Ex 2 : @getoutfit:socks=2222 => "0" => the avatar is not wearing socks.<br />
<br />
'''Note:''' For viewers that implement the new Viewer 2.0 features, the list is:<br />
<br />
gloves,jacket,pants,shirt,shoes,skirt,socks,underpants,undershirt,skin,eyes,hair,shape,alpha,tattoo<br />
<br />
<br />
* '''''Get the list of worn attachments''''' : @getattach[:attachpt]=<channel_number><br />
''Implemented in v1.10''<br />
<br />
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.<br />
<br />
The list of 0s and 1s corresponds to :<br />
none,chest,skull,left shoulder,right shoulder,left hand,right hand,left foot,right foot,spine,<br />
pelvis,mouth,chin,left ear,right ear,left eyeball,right eyeball,nose,r upper arm,r forearm,<br />
l upper arm,l forearm,right hip,r upper leg,r lower leg,left hip,l upper leg,l lower leg,stomach,left pec,<br />
right pec,center 2,top right,top,top left,center,bottom left,bottom,bottom right,neck,root<br />
in that order.<br />
<br />
If an attachment point is specified, answers a single 0 (empty) or 1 (occupied) corresponding to the point.<br />
Ex 1 : @getattach=2222 => "011000011010000000000000100100000000101" => avatar is wearing attachments on <br />
chest, skull, left and right foot, pelvis, l and r lower leg, HUD bottom left and HUD bottom right.<br />
Ex 2 : @getattach:chest=2222 => "1" => avatar is wearing something on the chest.<br />
<br />
''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.<br />
<br />
<br />
* '''''Force the viewer to automatically accept attach and take control permission requests''''' : @acceptpermission=<rem/add><br />
''Implemented in v1.16''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent accepting attach and take control permissions''''' : @denypermission=<rem/add><br />
''Implemented in v1.16, DEPRECATED in v1.16.2''<br />
<br />
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 !<br />
<br />
<br />
* '''''Force detach an item''''' : @detachme=force (*)<br />
''Implemented in v1.16.2''<br />
<br />
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.<br />
<br />
===Clothing and Attachments (Shared Folders)===<br />
<br />
* '''''Allow/prevent wearing clothes and attachments that are not part of the #RLV folder''''' : @unsharedwear=<y/n><br />
''Implemented in v2.5''<br />
<br />
When prevented, no object, piece of clothing or bodypart can be worn unless it is part of the #RLV folder (i.e. "shared").<br />
<br />
<br />
* '''''Allow/prevent removing clothes and attachments that are not part of the #RLV folder''''' : @unsharedunwear=<y/n><br />
''Implemented in v2.5''<br />
<br />
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").<br />
<br />
<br />
* '''''Get the list of shared folders in the avatar's inventory''''' : @getinv[:folder1/.../folderN]=<channel_number><br />
''Implemented in v1.11, added sub-folders in v1.13''<br />
<br />
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.<br />
<br />
The answer is a list of names, separated by commas (","). Folders which names begin with a dot (".") will be ignored.<br />
<br />
<br />
* '''''Get the list of shared folders in the avatar's inventory, with information about worn items''''' : @getinvworn[:folder1/.../folderN]=<channel_number><br />
''Implemented in v1.15''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Object : "@getinvworn:Restraints/Leather cuffs=2222"<br />
Viewer : "|02,Arms|30,Legs|10"<br />
<br />
Folders which names begin with a dot (".") will be ignored. The two digits are calculated as follows :<br />
<br />
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".<br />
<br />
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".<br />
<br />
The digits, comprised between 0 and 3 included, have the following meaning :<br />
<br />
:* 0 : No item is present in that folder<br />
:* 1 : Some items are present in that folder, but none of them is worn<br />
:* 2 : Some items are present in that folder, and some of them are worn<br />
:* 3 : Some items are present in that folder, and all of them are worn<br />
<br />
<br />
* '''''Get the path to a shared folder by giving a search criterion''''' : @findfolder:part1[&&...&&partN]=<channel_number><br />
''Implemented in v1.13.1''<br />
<br />
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 ('/').<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder''''' : @attach:<folder1/.../folderN>=force (*)<br />
''Implemented in v1.11, added no-mod items in v1.12, added sub-folders in v1.13''<br />
<br />
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.<br />
<br />
Attachment point names are the same as the ones contained into the "Attach To" submenu : "skull", "chest", "l forearm"...<br />
<br />
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.<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, without replacing what is already being worn''''' : @attachover:<folder1/.../folderN>=force (*)<br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
This command works exactly like @attach described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder''''' : @attachoverorreplace:<folder1/.../folderN>=force (*)<br />
''Implemented in v2.5''<br />
<br />
This command works exactly like @attach described hereabove, it is a synonym.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, and its children recursively''''' : @attachall:<folder1/.../folderN>=force (*)<br />
''Implemented in v1.15''<br />
<br />
This command works exactly like @attach described hereabove, but also attaches whatever is contained into children folders.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, and its children recursively, without replacing what is already being worn''''' : @attachallover:<folder1/.../folderN>=force (*)<br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
This command works exactly like @attachall described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, and its children recursively''''' : @attachalloverorreplace:<folder1/.../folderN>=force (*)<br />
''Implemented in v2.5''<br />
<br />
This command works exactly like @attachall described hereabove, it is a synonym.<br />
<br />
<br />
* '''''Force detach items contained inside a shared folder''''' : @detach:<folder_name>=force (*)<br />
''Implemented in v1.11''<br />
<br />
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.<br />
<br />
<br />
* '''''Force detach items contained inside a shared folder, and its children recursively''''' : @detachall:<folder1/.../folderN>=force (*)<br />
''Implemented in v1.15''<br />
<br />
This command works exactly like @detach described hereabove, but also detaches whatever is contained into children folders.<br />
<br />
<br />
* '''''Get the path to the shared folder containing a particular object/clothing worn on a point''''' : @getpath[:<attachpt> or <clothing_layer>]=<channel_number><br />
''Implemented in v1.16''<br />
<br />
Makes the viewer automatically answer the path to the shared folder containing the item that :<br />
:* issues this command if no option is set<br />
:* is attached on the attach point provided in the option field, ex : @getpath:spine=2222 => "Restraints/Collar"<br />
:* is worn on the clothing layer provided in the option field, ex : @getpath:pants=2222 => "Casual/Jeans/Tight"<br />
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 ('/').<br />
<br />
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.<br />
<br />
<br />
* '''''Get the all paths to the shared folders containing the objects/clothing worn on a point''''' : @getpathnew[:<attachpt> or <clothing_layer>]=<channel_number><br />
''Implemented in v2.1 and v1.24''<br />
<br />
Makes the viewer automatically answer the paths to the shared folders containing the item(s) that :<br />
:* issues this command if no option is set<br />
:* are attached on the attach point provided in the option field, ex : @getpathnew:spine=2222 => "Restraints/Collar,Jewelry/Cute necklace"<br />
:* is worn on the clothing layer provided in the option field, ex : @getpathnew:pants=2222 => "Casual/Jeans/Tight"<br />
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 (',').<br />
<br />
This command has been added to replace @getpath, since in 2.1 several objects can be worn on the same attachment point.<br />
<br />
<br />
* '''''Force attach items contained into a shared folder that contains a particular object/clothing''''' : @attachthis[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v1.16''<br />
<br />
This command is a shortcut for a @getpath followed with an @attach command (this saves a listener and a timeout).<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, without replacing what is already being worn''''' : @attachthisover[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
This command works exactly like @attachthis described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder''''' : @attachthisoverorreplace[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v2.5''<br />
<br />
This command works exactly like @attachthis described hereabove, it is a synonym.<br />
<br />
<br />
* '''''Force attach items contained into a shared folder that contains a particular object/clothing, and its children folders''''' : @attachallthis[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v1.16''<br />
<br />
This command is a shortcut for a @getpath followed with an @attachall command (this saves a listener and a timeout).<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, without replacing what is already being worn''''' : @attachallthisover[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
This command works exactly like @attachallthis described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder''''' : @attachallthisoverorreplace[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v2.5''<br />
<br />
This command works exactly like @attachallthis described hereabove, it is a synonym.<br />
<br />
<br />
* '''''Force detach items contained into a shared folder that contains a particular object/clothing''''' : @detachthis[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v1.16''<br />
<br />
This command is a shortcut for a @getpath followed with a @detach command (this saves a listener and a timeout).<br />
<br />
<br />
* '''''Force detach items contained into a shared folder that contains a particular object/clothing, and its children folders''''' : @detachallthis[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v1.16''<br />
<br />
This command is a shortcut for a @getpath followed with a @detachall command (this saves a listener and a timeout).<br />
<br />
<br />
* '''''Allow/prevent removing some folders''''' : @detachthis[:<layer>|<attachpt>|<path_to_folder>]=<y/n><br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, the user is unable to remove a folder if either of these conditions is filled :<br />
:* no option is specified and the folder contains the object that issues this restriction<br />
:* the "layer" option is set (shirt, pants...) and the folder contains a piece of clothing that is worn on this layer<br />
:* the "attachpt" option is set (l forearm, spine...) and the folder contains an attachment that is worn on this point<br />
:* the "path_to_folder" option is set and the folder corresponds to this location<br />
<br />
Moreso, this folder or these folders cannot be renamed, moved, deleted or modified.<br />
<br />
<br />
* '''''Allow/prevent removing some folders and their children''''' : @detachallthis[:<layer>|<attachpt>|<path_to_folder>]=<y/n><br />
''Implemented in v2.3 and v1.25''<br />
<br />
These commands do exactly like @detachthis, but also apply to their children folders recursively.<br />
<br />
<br />
* '''''Allow/prevent wearing some folders''''' : @attachthis:<layer>|<attachpt>|<path_to_folder>=<y/n><br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, the user is unable to attach a folder if either of these conditions is filled :<br />
:* the "layer" option is set (shirt, pants...) and the folder contains a piece of clothing that is meant to be worn on this layer<br />
:* the "attachpt" option is set (l forearm, spine...) and the folder contains an attachment that is meant to be worn on this point<br />
:* the "path_to_folder" option is set and the folder corresponds to this location<br />
<br />
Moreso, this folder or these folders cannot be renamed, moved, deleted or modified.<br />
<br />
<br />
* '''''Allow/prevent wearing some folders and their children''''' : @attachallthis[:<layer>|<attachpt>|<path_to_folder>]=<y/n><br />
''Implemented in v2.3 and v1.25''<br />
<br />
These commands do exactly like @attachthis, but also apply to their children folders recursively.<br />
<br />
<br />
* '''''Remove/add exceptions to the detachallthis restriction, for one folder only''''' : "@detachthis_except:<folder>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can remove the items contained into the indicated folder.<br />
<br />
<br />
* '''''Remove/add exceptions to the detachallthis restriction, for one folder and its children''''' : "@detachallthis_except:<folder>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can remove the items contained into the indicated folder, or in any of its children.<br />
<br />
<br />
* '''''Remove/add exceptions to the attachallthis restriction, for one folder only''''' : "@attachthis_except:<folder>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can wear the items contained into the indicated folder.<br />
<br />
<br />
* '''''Remove/add exceptions to the attachallthis restriction, for one folder and its children''''' : "@attachallthis_except:<folder>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can wear the items contained into the indicated folder, or in any of its children.<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Example :<br />
A script issues a @attachallthis:=n restriction, preventing the whole #RLV folder and its children from being attached. It also issues a<br />
@detachallthis:=n restriction, preventing the whole #RLV folder and its children from being removed as well.<br />
Therefore the #RLV folder is now completely frozen.<br />
<br />
However, the same object issues a @attachallthis:Jewelry/Gold=add exception, then a @detachallthis:Jewelry/Gold=add one, making the Jewelry/Gold<br />
folder available for wearing and removing.<br />
Finally, it issues a @attachallthis:Jewelry/Gold/Watch=n restriction followed by a @detachallthis:Jewelry/Gold/Watch=n restriction.<br />
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<br />
rest is out of reach.<br />
<br />
===Touch===<br />
<br />
* '''''Allow/prevent touching objects located further than 1.5 meters away from the avatar''''' : @fartouch=<y/n><br />
''Implemented in v1.11''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent touching objects located further than 1.5 meters away from the avatar''''' : @touchfar=<y/n><br />
''Implemented in v2.4''<br />
<br />
This command is a synonym of @fartouch<br />
<br />
<br />
* '''''Allow/prevent touching any objects''''' : @touchall=<y/n><br />
''Implemented in v2.4''<br />
<br />
When prevented, the avatar is unable to touch/grab any object and attachment. This does not apply to HUDs.<br />
<br />
<br />
* '''''Allow/prevent touching objects in-world''''' : @touchworld=<y/n><br />
''Implemented in v2.4''<br />
<br />
When prevented, the avatar is unable to touch/grab objects rezzed in-world, i.e. not attachments and HUDs.<br />
<br />
<br />
* '''''Remove/add exceptions to the touchworld prevention''''' : "@touchworld:<UUID>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can touch this object in particular.<br />
<br />
<br />
* '''''Allow/prevent touching one object in particular''''' : @touchthis:<UUID>=<rem/add><br />
''Implemented in v2.5''<br />
<br />
When prevented, the avatar is unable to touch/grab the object which UUID corresponds to the one specified in the command.<br />
<br />
<br />
* '''''Remove/add an exception to the touch* preventions, for one object only''''' : "@touchme=<rem/add>"<br />
''Implemented in v2.6''<br />
<br />
When adding such an exception, the user can touch this object in particular.<br />
<br />
<br />
* '''''Allow/prevent touching attachments''''' : @touchattach=<y/n><br />
''Implemented in v2.4''<br />
<br />
When prevented, the avatar is unable to touch attachments (theirs and other avatars'), but this does not apply to HUDs.<br />
<br />
<br />
* '''''Allow/prevent touching one's attachments''''' : @touchattachself=<y/n><br />
''Implemented in v2.4''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent touching other people's attachments''''' : @touchattachother=<y/n><br />
''Implemented in v2.4''<br />
<br />
When prevented, the avatar is unable to touch other people's attachments (but they can touch their owns). This does not apply to HUDs.<br />
<br />
===Location===<br />
<br />
* '''''Allow/prevent viewing the world map''''' : @showworldmap=<y/n><br />
''Implemented in v1.11''<br />
<br />
When prevented, the avatar is unable to view the world map, and it closes if it is open when the restriction becomes active.<br />
<br />
<br />
* '''''Allow/prevent viewing the mini map''''' : @showminimap=<y/n><br />
''Implemented in v1.11''<br />
<br />
When prevented, the avatar is unable to view the mini map, and it closes if it is open when the restriction becomes active.<br />
<br />
<br />
* '''''Allow/prevent knowing the current location''''' : @showloc=<y/n><br />
''Implemented in v1.12''<br />
<br />
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).<br />
<br />
===Name Tags and Hovertext===<br />
<br />
* '''''Allow/prevent seeing the names of the people around''''' : @shownames=<y/n><br />
''Implemented in v1.12.2, added more dummy names in v1.16''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent seeing all the hovertexts''''' : @showhovertextall=<y/n><br />
''Implemented in v1.19''<br />
<br />
When prevented, the user is unable to read any hovertext (2D text floating above some prims).<br />
<br />
<br />
* '''''Allow/prevent seeing one hovertext in particular''''' : @showhovertext:<UUID>=<y/n><br />
''Implemented in v1.19''<br />
<br />
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).<br />
<br />
<br />
* '''''Allow/prevent seeing the hovertexts on the HUD of the user''''' : @showhovertexthud=<y/n><br />
''Implemented in v1.19''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent seeing the hovertexts in-world''''' : @showhovertextworld=<y/n><br />
''Implemented in v1.19''<br />
<br />
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.<br />
<br />
===Group===<br />
<br />
* '''''Force the agent to change the active group''''' : @setgroup:<group_name>=force<br />
''Implemented in v2.5''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent activating a group''''' : @setgroup=<y/n><br />
''Implemented in v2.5''<br />
<br />
When prevented, the user is unable to change the active group.<br />
<br />
<br />
* '''''Get the name of the active group''''' : @getgroup=<channel_number><br />
''Implemented in v2.5''<br />
<br />
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.<br />
<br />
<br />
===Viewer Control===<br />
<br />
* '''''Allow/prevent changing some debug settings''''' : @setdebug=<y/n><br />
''Implemented in v1.16''<br />
<br />
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 :<br />
:* AvatarSex (0 : Female, 1 : Male) : gender of the avatar at creation.<br />
:* 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.<br />
<br />
* '''''Force change a debug setting''''' : @setdebug_<setting>:<value>=force (*)<br />
''Implemented in v1.16''<br />
<br />
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.<br />
<br />
See the list of allowed debug settings in the @setdebug command hereabove.<br />
<br />
<br />
* '''''Get the value of a debug setting''''' : @getdebug_<setting>=<channel_number><br />
''Implemented in v1.16''<br />
<br />
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.<br />
<br />
See the list of allowed debug settings in the @setdebug command hereabove.<br />
<br />
<br />
* '''''Allow/prevent changing the environment settings''''' : @setenv=<y/n><br />
''Implemented in v1.14''<br />
<br />
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).<br />
<br />
<br />
* '''''Force change an environment setting''''' : @setenv_<setting>:<value>=force (*)<br />
''Implemented in v1.14''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Each particular sub-command works as follows (the names are chosen to be as close to the Windlight panels of the viewer as possible) :<br />
<br />
{| border="1" cellpadding="5"<br />
| '''@setenv_XXX:<value>=force where XXX is...''' || '''<value> range''' || '''Sets...'''<br />
|-<br />
| 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'''<br />
|-<br />
| 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'''<br />
|-<br />
| ambientr || 0.0-1.0 || Ambient light, Red channel<br />
|-<br />
| ambientg || 0.0-1.0 || Ambient light, Green channel<br />
|-<br />
| ambientb || 0.0-1.0 || Ambient light, Blue channel<br />
|-<br />
| ambienti || 0.0-1.0 || Ambient light, Intensity<br />
|-<br />
| bluedensityr || 0.0-1.0 || Blue Density, Red channel<br />
|-<br />
| bluedensityg || 0.0-1.0 || Blue Density, Green channel<br />
|-<br />
| bluedensityb || 0.0-1.0 || Blue Density, Blue channel<br />
|-<br />
| bluedensityi || 0.0-1.0 || Blue Density, Intensity<br />
|-<br />
| bluehorizonr || 0.0-1.0 || Blue Horizon, Red channel<br />
|-<br />
| bluehorizong || 0.0-1.0 || Blue Horizon, Green channel<br />
|-<br />
| bluehorizonb || 0.0-1.0 || Blue Horizon, Blue channel<br />
|-<br />
| bluehorizoni || 0.0-1.0 || Blue Horizon, Intensity<br />
|-<br />
| cloudcolorr || 0.0-1.0 || Cloud color, Red channel<br />
|-<br />
| cloudcolorg || 0.0-1.0 || Cloud color, Green channel<br />
|-<br />
| cloudcolorb || 0.0-1.0 || Cloud color, Blue channel<br />
|-<br />
| cloudcolori || 0.0-1.0 || Cloud color, Intensity<br />
|-<br />
| cloudcoverage || 0.0-1.0 || Cloud coverage<br />
|-<br />
| cloudx || 0.0-1.0 || Cloud offset X<br />
|-<br />
| cloudy || 0.0-1.0 || Cloud offset Y<br />
|-<br />
| cloudd || 0.0-1.0 || Cloud density<br />
|-<br />
| clouddetailx || 0.0-1.0 || Cloud detail X<br />
|-<br />
| clouddetaily || 0.0-1.0 || Cloud detail Y<br />
|-<br />
| clouddetaild || 0.0-1.0 || Cloud detail density<br />
|-<br />
| cloudscale || 0.0-1.0 || Cloud scale<br />
|-<br />
| cloudscrollx || 0.0-1.0 || Cloud scroll X<br />
|-<br />
| cloudscrolly || 0.0-1.0 || Cloud scroll Y<br />
|-<br />
| densitymultiplier || 0.0-0.9 || Density multiplier of the fog<br />
|-<br />
| distancemultiplier || 0.0-100.0 || Distance multiplier of the fog<br />
|-<br />
| eastangle || 0.0-1.0 || Position of the east, 0.0 is normal<br />
|-<br />
| hazedensity || 0.0-1.0 || Density of the haze<br />
|-<br />
| hazehorizon || 0.0-1.0 || Haze at the horizon<br />
|-<br />
| maxaltitude || 0.0-4000.0 || Maximum altitude of the fog<br />
|-<br />
| scenegamma || 0.0-10.0 || Overall gamma, 1.0 is normal<br />
|-<br />
| starbrightness|| 0.0-2.0 || Brightness of the stars<br />
|-<br />
| sunglowfocus || 0.0-0.5 || Focus of the glow of the sun<br />
|-<br />
| sunglowsize || 1.0-2.0 || Size of the glow of the sun<br />
|-<br />
| sunmooncolorr || 0.0-1.0 || Sun and moon, Red channel<br />
|-<br />
| sunmooncolorg || 0.0-1.0 || Sun and moon, Green channel<br />
|-<br />
| sunmooncolorb || 0.0-1.0 || Sun and moon, Blue channel<br />
|-<br />
| sunmooncolori || 0.0-1.0 || Sun and moon, Intensity<br />
|-<br />
| sunmoonposition || 0.0-1.0 || Position of the sun/moon, different from "daytime", '''use this to set the apparent sunlight after loading a Preset'''<br />
|}<br />
<br />
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.<br />
<br />
* '''''Get the value of an environment setting''''' : @getenv_<setting>=<channel_number><br />
''Implemented in v1.15''<br />
<br />
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 /><br />
Note: only @getenv_daytime is supported by v1.19.0 (or older, i.e. non Windlight) viewers implementing RestrainedLove v1.15 and later.<br />
<br />
===Footnotes===<br />
<br />
(*) Silently discarded if the user is prevented from doing so by the corresponding restriction. This is on purpose.<br />
Ex : Force detach won't work if the object is undetachable. Force undress won't work if the user is prevented from undressing.<br />
<br />
==Important note about the global behaviours such as sendchat==<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Shared Folders==<br />
<br />
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.<br />
<br />
"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".<br />
<br />
To do this :<br />
* 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".<br />
* Move a folder containing restraints or other attachments directly into this new folder.<br />
* Wear the contents of that folder, that's it !<br />
<br />
So it would look like this :<br />
<br />
My Inventory<br />
|- #RLV<br />
| |- cuffs<br />
| | |- left cuff (l forearm) (no copy)<br />
| | \- right cuff (r forearm) (no copy)<br />
| \- gag<br />
| \- gag (mouth) (no copy)<br />
|- Animations<br />
|- Body Parts<br />
.<br />
.<br />
.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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...).<br />
<br />
HOW TO SHARE NO-MODIFY ITEMS :<br />
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.<br />
<br />
Example with no-modify shoes :<br />
<br />
My Inventory<br />
|- #RLV<br />
| \- shoes<br />
| |- left shoe (left foot)<br />
| | \- left shoe (no modify) (no transfer) <-- no-mod object<br />
| |- right shoe (right foot)<br />
| | \- right shoe (no modify) (no transfer) <-- no-mod object<br />
| \- shoe base (no modify) (no transfer) <-- this is not an object<br />
|- Animations<br />
|- Body Parts<br />
.<br />
.<br />
.<br />
<br />
GOTCHAS :<br />
* Do NOT put a comma (',') in the name of the folders under the shared root or it would screw the list up.<br />
* 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.<br />
* 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.<br />
* 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).<br />
<br />
<br />
'''''Accept sub-folders given via llGiveInventoryList() into the shared folder''''' :<br />
<br />
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).<br />
<br />
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).<br />
<br />
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).<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
==For your information==<br />
Here is how it works internally, for a better understanding of the gotchas you may encounter :<br />
* 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).<br />
<br />
* 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.<br />
<br />
* 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).<br />
<br />
* 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.<br />
<br />
* 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.<br />
If '''''UUID1''''' is a collar and '''''UUID2''''' is a gag :<br />
<br />
'''''UUID1''''' => detach, tploc, tplm, tplure, sittp<br />
<br />
'''''UUID2''''' => detach, sendim, sendim:(keyholder)<br />
<br />
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 :<br />
<br />
'''''UUID1''''' => detach, tploc, tplm, tplure, sittp, sendim<br />
<br />
'''''UUID2''''' => detach, sendim, sendim:(keyholder)<br />
<br />
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.<br />
<br />
* One-shot commands, on the other hand, are executed on-the-fly and are not stored.<br />
<br />
* 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).<br />
<br />
* 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.<br />
<br />
[[Category:Third Party Client]]<br />
[[Category:RestrainedLove]]</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=LSL_Protocol/RestrainedLoveAPI&diff=1179200LSL Protocol/RestrainedLoveAPI2013-06-14T04:51:58Z<p>Tonya Souther: /* Blacklist handling */ adding caveat</p>
<hr />
<div>{{LSL Header|ml=*}}<br />
=Restrained Love viewer v2.8.1 Specification=<br />
<br />
By [[User:Marine Kelley|Marine Kelley]]<br />
<br />
==Audience==<br />
<br />
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.<br />
<br />
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]]<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Architecture==<br />
<br />
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.<br />
<br />
The syntax of a message is:<br />
<br />
: <code>@<command1>[:option1]=<param1>,<command2>[:option2]=<param2>,...,<commandN>[:optionN]=<paramN></code><br />
<br />
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.<br />
<br />
: 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
{{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.}}<br />
<br />
==List of commands==<br />
<br />
'''Note:''' These commands are not case-sensitive but are spacing-sensitive. In other words, "@detach = n" will '''not''' work.<br />
<br />
'''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.<br />
<br />
'''Footnotes:''' "(*)" are footnotes and will be explained at the end of the list<br />
<br />
===Version Checking===<br />
<br />
* '''''Automated version checking''''' : "@version=<channel_number>"<br />
''Implemented in v1.0b''<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
* '''''Automated version checking''''' : "@versionnew=<channel_number>"<br />
''Implemented in v1.23''<br />
<br />
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.<br />
<br />
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).<br />
<br />
'''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.<br />
<br />
<br />
* '''''Automated version number checking''''' : "@versionnum=<channel_number>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
* '''''Automated version checking, second way''''' : llGetAgentLanguage (key id) '''''DEPRECATED: DO NOT USE !'''''<br />
''Implemented in v1.16''<br />
<br />
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).<br />
<br />
<br />
* '''''Manual version checking''''' : "@version"<br />
''Implemented in v1.0a''<br />
<br />
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 usually totally stealthy. However, some viewers, such as Firestorm, have the ability to send an autoreply message when someone begins typing an IM to the user. If the user has that option enabled, an IM window will open and display the auto response as soon as the @ is typed by the sender, but nothing else.<br />
<br />
===Blacklist handling===<br />
<br />
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.<br />
<br />
<br />
* '''''Automated version number checking, followed by the blacklist''''' : "@versionnumbl=<channel_number>"<br />
''Implemented in v2.8''<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
* '''''Get the contents of the blacklist, with a filter''''' : "@getblacklist[:filter]=<channel_number>"<br />
''Implemented in v2.8''<br />
<br />
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.<br />
<br />
<br />
* '''''Manual blacklist checking''''' : "@getblacklist"<br />
''Implemented in v2.8''<br />
<br />
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 usually totally stealthy, with the same caveat mentioned above under @version.<br />
<br />
===Miscellaneous===<br />
<br />
* '''''Start/stop notifications on a private channel''''' : "@notify:<channel_number>[;word]=<rem/add>"<br />
''Implemented in v1.20, improved in v2.2 (and v1.24)''<br />
<br />
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.<br />
<br />
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 :<br />
<br />
:* /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).<br />
<br />
:* /accepted_in_inv inv_offer <folder> : The folder has been accepted but is not shared.<br />
<br />
:* /declined inv_offer <folder> : The folder has been declined and/or the user has pressed "Block" (formerly "Mute").<br />
<br />
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.<br />
<br />
Note 2 : Since v2.5 the viewer also sends notifications when wearing outfits :<br />
<br />
:* /worn legally <layer> : The avatar has just worn a piece of clothing on the indicated layer.<br />
<br />
:* /unworn legally <layer> : The avatar has just removed a piece of clothing from the indicated layer.<br />
<br />
:* /attached legally <attach_point_name> : The avatar has just attached an object to the indicated attachment point.<br />
<br />
:* /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.<br />
<br />
:* /detached legally <attach_point_name> : The avatar has just detached an object from the indicated attachment point.<br />
<br />
:* /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.<br />
<br />
<br />
* '''''Allow/deny permissive exceptions''''' : "@permissive=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
'''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 !<br />
<br />
<br />
* '''''Clear all the rules tied to an object''''' : "@clear"<br />
''Implemented in v1.0a, but working only since v1.04a''<br />
<br />
This command clears all the restrictions and exceptions tied to a particular [[UUID]].<br />
<br />
'''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.<br />
<br />
Possible workarounds:<br />
:* only lift the exact restrictions you added with @clear=<pattern> <br />
:* only trigger @clear on detach when you are sure the attachment is not locked<br />
:* don't trigger @clear on detach at all and wait for the viewer to lift the set restrictions<br />
<br />
<br />
* '''''Clear a subset of the rules tied to an object''''' : "@clear=<string>"<br />
''Implemented in v1.0a, but working only since v1.04a''<br />
<br />
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<br />
<br />
<br />
* '''''Get the list of restrictions the avatar is currently submitted to''''' : @getstatus[:<part_of_rule>[;<custom_separator>]]=<channel><br />
''Implemented in v1.10, slightly tweaked in v1.16 and v2.8''<br />
<br />
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 !<br />
<br />
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.<br />
<br />
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.<br />
<br />
<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.<br />
<br />
Example : If the avatar is under tploc, tplure, tplm and sittp, here is what the script would get :<br />
@getstatus=2222 => /tploc/tplure/tplm/sittp<br />
@getstatus:sittp=2222 => /sittp<br />
@getstatus:tpl=2222 => /tploc/tplure/tplm (because "tpl" is part of "tploc", "tplure" and "tplm" but not "sittp")<br />
@getstatus:tpl;#=2222 => #tploc#tplure#tplm (because "tpl" is part of "tploc", "tplure" and "tplm" but not "sittp", and the<br />
specified separator is "#")<br />
@getstatus:;#=2222 => #tploc#tplure#tplm#sittp (because the specified separator is "#")<br />
@getstatus:;=2222 => /tploc/tplure/tplm/sittp (because the specified separator is empty, so it defaults to "/")<br />
<br />
<br />
* '''''Get the list of all the restrictions the avatar is currently submitted to''''' : @getstatusall[:<part_of_rule>[;<custom_separator>]]=<channel><br />
''Implemented in v1.15, slightly tweaked in v1.16 and v2.8''<br />
<br />
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 !<br />
<br />
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.<br />
<br />
===Movement===<br />
<br />
* '''''Allow/prevent flying''''' : @fly=<y/n><br />
''Implemented in v1.12.2''<br />
<br />
When prevented, the user is unable to fly.<br />
<br />
<br />
* '''''Allow/prevent running by double-tapping an arrow key''''' : @temprun=<y/n><br />
''Implemented in v2.7''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent always running''''' : @alwaysrun=<y/n><br />
''Implemented in v2.7''<br />
<br />
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.<br />
<br />
<br />
* '''''Force rotate the avatar to a set direction''''' : @setrot:<angle_in_radians>=force<br />
''Implemented in v1.17''<br />
<br />
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.<br />
<br />
<br />
* '''''Change the height of the avatar''''' : @adjustheight:<distance_pelvis_to_foot_in_meters>;<factor>[;delta_in_meters]=force<br />
''Implemented in v2.5''<br />
<br />
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.<br />
<br />
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]<br />
<br />
===Chat, Emotes and Instant Messages===<br />
====Chat====<br />
* '''''Allow/prevent sending chat messages''''' : "@sendchat=<y/n>"<br />
''Implemented in v1.0b''<br />
<br />
When prevented, everything typed on [[Chat channel|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.<br />
<br />
<br />
* '''''Allow/prevent shouting''''' : "@chatshout=<y/n>"<br />
''Implemented in v1.15''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent chatting at normal volume''''' : "@chatnormal=<y/n>"<br />
''Implemented in v1.15''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent whispering''''' : "@chatwhisper=<y/n>"<br />
''Implemented in v1.15''<br />
<br />
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.<br />
<br />
<br />
* '''''Redirect public chat to private channels''''' : "@redirchat:<channel_number>=<rem/add>"<br />
''Implemented in v1.16''<br />
<br />
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.<br />
'''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).<br />
<br />
<br />
* '''''Allow/prevent receiving chat messages''''' : "@recvchat=<y/n>"<br />
''Implemented in v1.0b''<br />
<br />
When prevented, everything heard in public chat will be discarded except emotes.<br />
<br />
<br />
* '''''Allow/prevent receiving chat messages, secure way''''' : "@recvchat_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the chat message receiving prevention''''' : "@recvchat:<UUID>=<rem/add>"<br />
''Implemented in v1.01''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent receiving chat messages from someone in particular''''' : "@recvchatfrom:<UUID>=<y/n>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, everything heard in public chat from the specified avatar will be discarded except emotes.<br />
<br />
<br />
====Emotes====<br />
* '''''Remove/add an exception to the emote truncation above''''' : "@emote=<rem/add>"<br />
''Implemented in v1.01''<br />
<br />
When adding this exception, the emotes are not truncated anymore (however, special signs will still discard the message).<br />
<br />
<br />
* '''''Redirect public emotes to private channels''''' : "@rediremote:<channel_number>=<rem/add>"<br />
''Implemented in v1.19''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent seeing emotes''''' : "@recvemote=<y/n>"<br />
''Implemented in v1.19''<br />
<br />
When prevented, every emote seen in public chat will be discarded.<br />
<br />
<br />
* '''''Allow/prevent receiving emotes seen in public chat from someone in particular''''' : "@recvemotefrom:<UUID>=<y/n>"<br />
''Implemented in v2.4''<br />
<br />
When prevented, everything emote seen in public chat from the specified avatar will be discarded.<br />
<br />
<br />
* '''''Allow/prevent seeing emotes, secure way''''' : "@recvemote_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the emote seeing prevention''''' : "@recvemote:<UUID>=<rem/add>"<br />
''Implemented in v1.19''<br />
<br />
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.<br />
<br />
<br />
====Private Channels====<br />
* '''''Allow/prevent using any chat channel but certain channels''''' : @sendchannel[:<channel>]=<y/n><br />
''Implemented in v1.10''<br />
<br />
Complimentary of @sendchat, this command prevents the user from sending messages on non-public Chat channels. 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. <br />
<br />
<br />
* '''''Allow/prevent using any chat channel but certain channels, secure way''''' : @sendchannel_sec[:<channel>]=<y/n><br />
''Implemented in v1.10''<br />
<br />
Complimentary of @sendchat, this command prevents the user from sending messages on non-public channels. 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.<br />
<br />
<br />
====Instant Messages====<br />
* '''''Allow/prevent sending instant messages''''' : "@sendim=<y/n>"<br />
''Implemented in v1.0b''<br />
<br />
When prevented, everything typed in IM will be discarded and a bogus message will be sent to the receiver instead.<br />
<br />
<br />
* '''''Allow/prevent sending instant messages, secure way''''' : "@sendim_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the instant message sending prevention''''' : "@sendim:<UUID>=<rem/add>"<br />
''Implemented in v1.01''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent sending instant messages to someone in particular''''' : "@sendimto:<UUID>=<y/n>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, everything typed in IM to the specified avatar will be discarded and a bogus message will be sent instead.<br />
<br />
<br />
* '''''Allow/prevent starting an IM session with anyone''''' : "@startim=<y/n>"<br />
''Implemented in v2.6''<br />
<br />
When prevented, the user is unable to start an IM session with anyone. Sessions that are already open are not impacted though.<br />
<br />
<br />
* '''''Remove/add exceptions to the IM session start prevention''''' : "@startim:<UUID>=<rem/add>"<br />
''Implemented in v2.6''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent starting an IM session with someone in particular''''' : "@startimto:<UUID>=<y/n>"<br />
''Implemented in v2.6''<br />
<br />
When prevented, the user is unable to start an IM session with that person. Sessions that are already open are not impacted though.<br />
<br />
<br />
* '''''Allow/prevent receiving instant messages''''' : "@recvim=<y/n>"<br />
''Implemented in v1.0b''<br />
<br />
When prevented, every incoming IM will be discarded and the sender will be notified that the user cannot read them.<br />
<br />
<br />
* '''''Allow/prevent receiving instant messages, secure way''''' : "@recvim_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the instant message receiving prevention''''' : "@recvim:<UUID>=<rem/add>"<br />
''Implemented in v1.01''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent receiving instant messages from someone in particular''''' : "@recvimfrom:<UUID>=<y/n>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
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.<br />
<br />
===Teleportation===<br />
<br />
* '''''Allow/prevent teleporting to a landmark''''' : "@tplm=<y/n>"<br />
''Implemented in v1.0''<br />
<br />
When prevented, the user cannot use a [[landmark]], pick or any other preset location to [[teleport]] there.<br />
<br />
<br />
* '''''Allow/prevent teleporting to a location''''' : "@tploc=<y/n>"<br />
''Implemented in v1.0''<br />
<br />
When prevented, the user cannot use [[teleport]] to a coordinate by using the [[map]] and such.<br />
<br />
<br />
* '''''Allow/prevent teleporting by a friend''''' : "@tplure=<y/n>"<br />
''Implemented in v1.0''<br />
<br />
When prevented, the user automatically discards any [[teleport]] offer, and the avatar who initiated the offer is notified.<br />
<br />
<br />
* '''''Allow/prevent teleporting by a friend, secure way''''' : "@tplure_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the friend teleport prevention''''' : "@tplure:<UUID>=<rem/add>"<br />
''Implemented in v1.0''<br />
<br />
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.<br />
<br />
<br />
* '''''Unlimit/limit sit-tp''''' : "@sittp=<y/n>"<br />
''Implemented in v1.0''<br />
<br />
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).<br />
<br />
<br />
* '''''Allow/prevent standing up at a different location than where we sat down''''' : @standtp=<y/n><br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
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.<br />
<br />
<br />
* '''''Force-Teleport the user''''' : @tpto:<X>/<Y>/<Z>=force (*)<br />
''Implemented in v1.12''<br />
<br />
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.<br />
<br />
Here is a sample code to call that command properly :<br />
<br />
<lsl><br />
<br />
// FORCE TELEPORT EXAMPLE<br />
// Listens on channel 4 for local coordinates and a sim name<br />
// and tells your viewer to teleport you there.<br />
//<br />
// By Marine Kelley 2008-08-26<br />
// RLV version required : 1.12 and above<br />
//<br />
// HOW TO USE :<br />
// * Create a script inside a box<br />
// * Overwrite the contents of the script with this one<br />
// * Wear the box<br />
// * Say the destination coords Region/X/Y/Z on channel 4 :<br />
// Example : /4 Help Island Public/128/128/50<br />
<br />
key kRequestHandle; // UUID of the dataserver request<br />
vector vLocalPos; // local position extracted from the<br />
<br />
Init () {<br />
kRequestHandle = NULL_KEY;<br />
llListen (4, "", llGetOwner (), "");<br />
}<br />
<br />
<br />
default<br />
{<br />
state_entry () {<br />
Init ();<br />
}<br />
<br />
on_rez(integer start_param) {<br />
Init ();<br />
}<br />
<br />
listen(integer channel, string name, key id, string message) {<br />
list tokens = llParseString2List (message, ["/"], []);<br />
integer L = llGetListLength (tokens);<br />
<br />
if (L==4) {<br />
// Extract local X, Y and Z<br />
vLocalPos.x = llList2Float (tokens, 1);<br />
vLocalPos.y = llList2Float (tokens, 2);<br />
vLocalPos.z = llList2Float (tokens, 3);<br />
<br />
// Request info about the sim<br />
kRequestHandle=llRequestSimulatorData (llList2String (tokens, 0), DATA_SIM_POS);<br />
}<br />
}<br />
<br />
dataserver(key queryid, string data) {<br />
if (queryid == kRequestHandle) {<br />
// Parse the dataserver response (it is a vector cast to a string)<br />
list tokens = llParseString2List (data, ["<", ",", ">"], []);<br />
string pos_str = "";<br />
vector global_pos;<br />
<br />
// The coordinates given by the dataserver are the ones of the<br />
// South-West corner of this sim<br />
// => offset with the specified local coordinates<br />
global_pos.x = llList2Float (tokens, 0);<br />
global_pos.y = llList2Float (tokens, 1);<br />
global_pos.z = llList2Float (tokens, 2);<br />
global_pos += vLocalPos;<br />
<br />
// Build the command<br />
pos_str = (string)((integer)global_pos.x)<br />
+"/"+(string)((integer)global_pos.y)<br />
+"/"+(string)((integer)global_pos.z);<br />
llOwnerSay ("Global position : "+(string)pos_str); // Debug purposes<br />
<br />
// Fire !<br />
llOwnerSay ("@tpto:"+pos_str+"=force");<br />
}<br />
}<br />
<br />
}<br />
<br />
</lsl><br />
<br />
<br />
<br />
* '''''Remove/add auto-accept teleport offers from a particular avatar''''' : "@accepttp[:<UUID>]=<rem/add>"<br />
''Implemented in v1.15, slightly improved in v1.16''<br />
<br />
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 !<br />
<br />
===Inventory, Editing and Rezzing===<br />
<br />
* '''''Allow/prevent using inventory''''' : @showinv=<y/n><br />
''Implemented in v1.10''<br />
<br />
Forces the [[inventory]] windows to close and stay closed.<br />
<br />
<br />
* '''''Allow/prevent reading notecards''''' : @viewnote=<y/n><br />
''Implemented in v1.10''<br />
<br />
Prevents from opening [[notecards]] but does not close the ones already open.<br />
<br />
<br />
* '''''Allow/prevent opening scripts''''' : @viewscript=<y/n><br />
''Implemented in v1.22''<br />
<br />
Prevents from opening [[scripts]] but does not close the ones already open.<br />
<br />
<br />
* '''''Allow/prevent opening textures''''' : @viewtexture=<y/n><br />
''Implemented in v1.22''<br />
<br />
Prevents from opening [[textures]] (and snapshots) but does not close the ones already open.<br />
<br />
<br />
* '''''Allow/prevent editing objects''''' : "@edit=<y/n>"<br />
''Implemented in v1.03''<br />
<br />
When prevented from editing and opening objects, the Build & Edit window will refuse to open.<br />
<br />
<br />
* '''''Remove/add exceptions to the edit prevention''''' : "@edit:<UUID>=<rem/add>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
When adding an exception, the user can edit or open this object in particular.<br />
<br />
<br />
* '''''Allow/prevent rezzing inventory''''' : "@rez=<y/n>"<br />
''Implemented in v1.03''<br />
<br />
When prevented from [[rez]]zing stuff, creating and deleting objects, drag-dropping from inventory and dropping attachments will fail.<br />
<br />
<br />
* '''''Allow/prevent editing particular objects''''' : "@editobj:<UUID>=<y/n>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, the Build & Edit window will refuse to open when trying to edit or open the specified object.<br />
<br />
===Sitting===<br />
<br />
* '''''Allow/prevent standing up''''' : @unsit=<y/n><br />
''Implemented in v1.10, modified in v1.15 to prevent teleporting as well''<br />
<br />
Hides the Stand up button. From v1.15 it also prevents teleporting, which was a way to stand up.<br />
<br />
<br />
* '''''Force sit on an object''''' : @sit:<UUID>=force (*)<br />
''Implemented in v1.10''<br />
<br />
Does not work if the user is prevented from sit-tping and further than 1.5 meters away, or when prevented from unsitting.<br />
<br />
<br />
* '''''Get the UUID of the object the avatar is sitting on''''' : @getsitid=<channel_number><br />
''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)''<br />
<br />
Makes the viewer automatically answer the UUID of the object the avatar is currently sitting on, or NULL_KEY if they are not sitting.<br />
<br />
<br />
* '''''Force unsit''''' : @unsit=force (*)<br />
''Implemented in v1.10''<br />
<br />
Self-explanatory but for some reason it randomly fails, so don't rely on it for now. Further testing is needed.<br />
<br />
<br />
* '''''Allow/prevent sitting down''''' : @sit=<y/n><br />
''Implemented in v1.16.2''<br />
<br />
Prevents the user from sitting on anything, including with @sit:<UUID>=force.<br />
<br />
===Clothing and Attachments===<br />
<br />
* '''''Render an object detachable/nondetachable''''' : "@detach=<y/n>"<br />
''Implemented in v1.0a''<br />
<br />
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.<br />
<br />
<br />
* '''''Unlock/Lock an attachment point''''' : "@detach:<attach_point_name>=<y/n>"<br />
''Implemented in v1.20''<br />
<br />
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).<br />
<br />
<br />
* '''''Unlock/Lock an attachment point empty''''' : "@addattach[:<attach_point_name>]=<y/n>"<br />
''Implemented in v1.22''<br />
<br />
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.<br />
<br />
<br />
* '''''Unlock/Lock an attachment point full''''' : "@remattach[:<attach_point_name>]=<y/n>"<br />
''Implemented in v1.22''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/deny the "Wear" contextual menu''''' : "@defaultwear=<y/n><br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
* '''''Force removing attachments''''' : @detach[:attachpt]=force (*) <br />
''Implemented in v1.10''<br />
<br />
Where part is :<br />
chest|skull|left shoulder|right shoulder|left hand|right hand|left foot|right foot|spine|<br />
pelvis|mouth|chin|left ear|right ear|left eyeball|right eyeball|nose|r upper arm|r forearm|<br />
l upper arm|l forearm|right hip|r upper leg|r lower leg|left hip|l upper leg|l lower leg|stomach|left pec|<br />
right pec|center 2|top right|top|top left|center|bottom left|bottom|bottom right|neck|root<br />
If part is not specified, removes everything.<br />
<br />
<br />
* '''''Force removing attachments (alias)''''' : @remattach[:attachpt]=force (*) <br />
''Implemented in v1.22''<br />
<br />
This command is an alias to @detach[:attachpt]=force (to keep things consistent).<br />
<br />
<br />
* '''''Allow/prevent wearing clothes''''' : @addoutfit[:<part>]=<y/n><br />
''Implemented in v1.10, added skin hair and eyes in v1.10.1, added physics in 2.6.1''<br />
<br />
Where part is :<br />
gloves|jacket|pants|shirt|shoes|skirt|socks|underpants|undershirt|skin|eyes|hair|shape|alpha|tattoo|physics<br />
If part is not specified, prevents from wearing anything beyond what the avatar is already wearing.<br />
<br />
'''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.<br />
<br />
<br />
* '''''Allow/prevent removing clothes''''' : @remoutfit[:<part>]=<y/n> (underpants and undershirt are kept for teens)<br />
''Implemented in v1.10, added skin hair and eyes in v1.10.1, added physics in 2.6.1''<br />
<br />
Where part is :<br />
gloves|jacket|pants|shirt|shoes|skirt|socks|underpants|undershirt|skin|eyes|hair|shape|alpha|tattoo|physics<br />
If part is not specified, prevents from removing anything in what the avatar is wearing.<br />
<br />
'''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.<br />
<br />
<br />
* '''''Force removing clothes''''' : @remoutfit[:<part>]=force (*) (teens can't be forced to remove underpants and undershirt)<br />
''Implemented in v1.10''<br />
<br />
Where part is :<br />
gloves|jacket|pants|shirt|shoes|skirt|socks|underpants|undershirt|alpha|tattoo|physics<br />
If part is not specified, removes everything.<br />
<br />
'''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.<br />
<br />
'''Note:''' skin, shape, eyes and hair cannot be removed since they are body parts (and removing any would result in an unrezzed avatar).<br />
<br />
<br />
* '''''Get the list of worn clothes''''' : @getoutfit[:part]=<channel_number><br />
''Implemented in v1.10, added skin hair and eyes in v1.10.1, added physics in 2.6.1''<br />
<br />
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.<br />
<br />
The list of 0s and 1s corresponds to :<br />
gloves,jacket,pants,shirt,shoes,skirt,socks,underpants,undershirt,skin,eyes,hair,shape<br />
in that order.<br />
<br />
If a part is specified, answers a single 0 (empty) or 1 (occupied) corresponding to the part.<br />
Ex 1 : @getoutfit=2222 => "0011000111" => avatar is wearing pants, shirt, underpants and undershirt, and of course a skin.<br />
Ex 2 : @getoutfit:socks=2222 => "0" => the avatar is not wearing socks.<br />
<br />
'''Note:''' For viewers that implement the new Viewer 2.0 features, the list is:<br />
<br />
gloves,jacket,pants,shirt,shoes,skirt,socks,underpants,undershirt,skin,eyes,hair,shape,alpha,tattoo<br />
<br />
<br />
* '''''Get the list of worn attachments''''' : @getattach[:attachpt]=<channel_number><br />
''Implemented in v1.10''<br />
<br />
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.<br />
<br />
The list of 0s and 1s corresponds to :<br />
none,chest,skull,left shoulder,right shoulder,left hand,right hand,left foot,right foot,spine,<br />
pelvis,mouth,chin,left ear,right ear,left eyeball,right eyeball,nose,r upper arm,r forearm,<br />
l upper arm,l forearm,right hip,r upper leg,r lower leg,left hip,l upper leg,l lower leg,stomach,left pec,<br />
right pec,center 2,top right,top,top left,center,bottom left,bottom,bottom right,neck,root<br />
in that order.<br />
<br />
If an attachment point is specified, answers a single 0 (empty) or 1 (occupied) corresponding to the point.<br />
Ex 1 : @getattach=2222 => "011000011010000000000000100100000000101" => avatar is wearing attachments on <br />
chest, skull, left and right foot, pelvis, l and r lower leg, HUD bottom left and HUD bottom right.<br />
Ex 2 : @getattach:chest=2222 => "1" => avatar is wearing something on the chest.<br />
<br />
''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.<br />
<br />
<br />
* '''''Force the viewer to automatically accept attach and take control permission requests''''' : @acceptpermission=<rem/add><br />
''Implemented in v1.16''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent accepting attach and take control permissions''''' : @denypermission=<rem/add><br />
''Implemented in v1.16, DEPRECATED in v1.16.2''<br />
<br />
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 !<br />
<br />
<br />
* '''''Force detach an item''''' : @detachme=force (*)<br />
''Implemented in v1.16.2''<br />
<br />
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.<br />
<br />
===Clothing and Attachments (Shared Folders)===<br />
<br />
* '''''Allow/prevent wearing clothes and attachments that are not part of the #RLV folder''''' : @unsharedwear=<y/n><br />
''Implemented in v2.5''<br />
<br />
When prevented, no object, piece of clothing or bodypart can be worn unless it is part of the #RLV folder (i.e. "shared").<br />
<br />
<br />
* '''''Allow/prevent removing clothes and attachments that are not part of the #RLV folder''''' : @unsharedunwear=<y/n><br />
''Implemented in v2.5''<br />
<br />
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").<br />
<br />
<br />
* '''''Get the list of shared folders in the avatar's inventory''''' : @getinv[:folder1/.../folderN]=<channel_number><br />
''Implemented in v1.11, added sub-folders in v1.13''<br />
<br />
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.<br />
<br />
The answer is a list of names, separated by commas (","). Folders which names begin with a dot (".") will be ignored.<br />
<br />
<br />
* '''''Get the list of shared folders in the avatar's inventory, with information about worn items''''' : @getinvworn[:folder1/.../folderN]=<channel_number><br />
''Implemented in v1.15''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Object : "@getinvworn:Restraints/Leather cuffs=2222"<br />
Viewer : "|02,Arms|30,Legs|10"<br />
<br />
Folders which names begin with a dot (".") will be ignored. The two digits are calculated as follows :<br />
<br />
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".<br />
<br />
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".<br />
<br />
The digits, comprised between 0 and 3 included, have the following meaning :<br />
<br />
:* 0 : No item is present in that folder<br />
:* 1 : Some items are present in that folder, but none of them is worn<br />
:* 2 : Some items are present in that folder, and some of them are worn<br />
:* 3 : Some items are present in that folder, and all of them are worn<br />
<br />
<br />
* '''''Get the path to a shared folder by giving a search criterion''''' : @findfolder:part1[&&...&&partN]=<channel_number><br />
''Implemented in v1.13.1''<br />
<br />
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 ('/').<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder''''' : @attach:<folder1/.../folderN>=force (*)<br />
''Implemented in v1.11, added no-mod items in v1.12, added sub-folders in v1.13''<br />
<br />
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.<br />
<br />
Attachment point names are the same as the ones contained into the "Attach To" submenu : "skull", "chest", "l forearm"...<br />
<br />
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.<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, without replacing what is already being worn''''' : @attachover:<folder1/.../folderN>=force (*)<br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
This command works exactly like @attach described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder''''' : @attachoverorreplace:<folder1/.../folderN>=force (*)<br />
''Implemented in v2.5''<br />
<br />
This command works exactly like @attach described hereabove, it is a synonym.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, and its children recursively''''' : @attachall:<folder1/.../folderN>=force (*)<br />
''Implemented in v1.15''<br />
<br />
This command works exactly like @attach described hereabove, but also attaches whatever is contained into children folders.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, and its children recursively, without replacing what is already being worn''''' : @attachallover:<folder1/.../folderN>=force (*)<br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
This command works exactly like @attachall described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, and its children recursively''''' : @attachalloverorreplace:<folder1/.../folderN>=force (*)<br />
''Implemented in v2.5''<br />
<br />
This command works exactly like @attachall described hereabove, it is a synonym.<br />
<br />
<br />
* '''''Force detach items contained inside a shared folder''''' : @detach:<folder_name>=force (*)<br />
''Implemented in v1.11''<br />
<br />
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.<br />
<br />
<br />
* '''''Force detach items contained inside a shared folder, and its children recursively''''' : @detachall:<folder1/.../folderN>=force (*)<br />
''Implemented in v1.15''<br />
<br />
This command works exactly like @detach described hereabove, but also detaches whatever is contained into children folders.<br />
<br />
<br />
* '''''Get the path to the shared folder containing a particular object/clothing worn on a point''''' : @getpath[:<attachpt> or <clothing_layer>]=<channel_number><br />
''Implemented in v1.16''<br />
<br />
Makes the viewer automatically answer the path to the shared folder containing the item that :<br />
:* issues this command if no option is set<br />
:* is attached on the attach point provided in the option field, ex : @getpath:spine=2222 => "Restraints/Collar"<br />
:* is worn on the clothing layer provided in the option field, ex : @getpath:pants=2222 => "Casual/Jeans/Tight"<br />
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 ('/').<br />
<br />
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.<br />
<br />
<br />
* '''''Get the all paths to the shared folders containing the objects/clothing worn on a point''''' : @getpathnew[:<attachpt> or <clothing_layer>]=<channel_number><br />
''Implemented in v2.1 and v1.24''<br />
<br />
Makes the viewer automatically answer the paths to the shared folders containing the item(s) that :<br />
:* issues this command if no option is set<br />
:* are attached on the attach point provided in the option field, ex : @getpathnew:spine=2222 => "Restraints/Collar,Jewelry/Cute necklace"<br />
:* is worn on the clothing layer provided in the option field, ex : @getpathnew:pants=2222 => "Casual/Jeans/Tight"<br />
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 (',').<br />
<br />
This command has been added to replace @getpath, since in 2.1 several objects can be worn on the same attachment point.<br />
<br />
<br />
* '''''Force attach items contained into a shared folder that contains a particular object/clothing''''' : @attachthis[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v1.16''<br />
<br />
This command is a shortcut for a @getpath followed with an @attach command (this saves a listener and a timeout).<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, without replacing what is already being worn''''' : @attachthisover[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
This command works exactly like @attachthis described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder''''' : @attachthisoverorreplace[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v2.5''<br />
<br />
This command works exactly like @attachthis described hereabove, it is a synonym.<br />
<br />
<br />
* '''''Force attach items contained into a shared folder that contains a particular object/clothing, and its children folders''''' : @attachallthis[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v1.16''<br />
<br />
This command is a shortcut for a @getpath followed with an @attachall command (this saves a listener and a timeout).<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, without replacing what is already being worn''''' : @attachallthisover[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
This command works exactly like @attachallthis described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder''''' : @attachallthisoverorreplace[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v2.5''<br />
<br />
This command works exactly like @attachallthis described hereabove, it is a synonym.<br />
<br />
<br />
* '''''Force detach items contained into a shared folder that contains a particular object/clothing''''' : @detachthis[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v1.16''<br />
<br />
This command is a shortcut for a @getpath followed with a @detach command (this saves a listener and a timeout).<br />
<br />
<br />
* '''''Force detach items contained into a shared folder that contains a particular object/clothing, and its children folders''''' : @detachallthis[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v1.16''<br />
<br />
This command is a shortcut for a @getpath followed with a @detachall command (this saves a listener and a timeout).<br />
<br />
<br />
* '''''Allow/prevent removing some folders''''' : @detachthis[:<layer>|<attachpt>|<path_to_folder>]=<y/n><br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, the user is unable to remove a folder if either of these conditions is filled :<br />
:* no option is specified and the folder contains the object that issues this restriction<br />
:* the "layer" option is set (shirt, pants...) and the folder contains a piece of clothing that is worn on this layer<br />
:* the "attachpt" option is set (l forearm, spine...) and the folder contains an attachment that is worn on this point<br />
:* the "path_to_folder" option is set and the folder corresponds to this location<br />
<br />
Moreso, this folder or these folders cannot be renamed, moved, deleted or modified.<br />
<br />
<br />
* '''''Allow/prevent removing some folders and their children''''' : @detachallthis[:<layer>|<attachpt>|<path_to_folder>]=<y/n><br />
''Implemented in v2.3 and v1.25''<br />
<br />
These commands do exactly like @detachthis, but also apply to their children folders recursively.<br />
<br />
<br />
* '''''Allow/prevent wearing some folders''''' : @attachthis:<layer>|<attachpt>|<path_to_folder>=<y/n><br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, the user is unable to attach a folder if either of these conditions is filled :<br />
:* the "layer" option is set (shirt, pants...) and the folder contains a piece of clothing that is meant to be worn on this layer<br />
:* the "attachpt" option is set (l forearm, spine...) and the folder contains an attachment that is meant to be worn on this point<br />
:* the "path_to_folder" option is set and the folder corresponds to this location<br />
<br />
Moreso, this folder or these folders cannot be renamed, moved, deleted or modified.<br />
<br />
<br />
* '''''Allow/prevent wearing some folders and their children''''' : @attachallthis[:<layer>|<attachpt>|<path_to_folder>]=<y/n><br />
''Implemented in v2.3 and v1.25''<br />
<br />
These commands do exactly like @attachthis, but also apply to their children folders recursively.<br />
<br />
<br />
* '''''Remove/add exceptions to the detachallthis restriction, for one folder only''''' : "@detachthis_except:<folder>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can remove the items contained into the indicated folder.<br />
<br />
<br />
* '''''Remove/add exceptions to the detachallthis restriction, for one folder and its children''''' : "@detachallthis_except:<folder>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can remove the items contained into the indicated folder, or in any of its children.<br />
<br />
<br />
* '''''Remove/add exceptions to the attachallthis restriction, for one folder only''''' : "@attachthis_except:<folder>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can wear the items contained into the indicated folder.<br />
<br />
<br />
* '''''Remove/add exceptions to the attachallthis restriction, for one folder and its children''''' : "@attachallthis_except:<folder>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can wear the items contained into the indicated folder, or in any of its children.<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Example :<br />
A script issues a @attachallthis:=n restriction, preventing the whole #RLV folder and its children from being attached. It also issues a<br />
@detachallthis:=n restriction, preventing the whole #RLV folder and its children from being removed as well.<br />
Therefore the #RLV folder is now completely frozen.<br />
<br />
However, the same object issues a @attachallthis:Jewelry/Gold=add exception, then a @detachallthis:Jewelry/Gold=add one, making the Jewelry/Gold<br />
folder available for wearing and removing.<br />
Finally, it issues a @attachallthis:Jewelry/Gold/Watch=n restriction followed by a @detachallthis:Jewelry/Gold/Watch=n restriction.<br />
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<br />
rest is out of reach.<br />
<br />
===Touch===<br />
<br />
* '''''Allow/prevent touching objects located further than 1.5 meters away from the avatar''''' : @fartouch=<y/n><br />
''Implemented in v1.11''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent touching objects located further than 1.5 meters away from the avatar''''' : @touchfar=<y/n><br />
''Implemented in v2.4''<br />
<br />
This command is a synonym of @fartouch<br />
<br />
<br />
* '''''Allow/prevent touching any objects''''' : @touchall=<y/n><br />
''Implemented in v2.4''<br />
<br />
When prevented, the avatar is unable to touch/grab any object and attachment. This does not apply to HUDs.<br />
<br />
<br />
* '''''Allow/prevent touching objects in-world''''' : @touchworld=<y/n><br />
''Implemented in v2.4''<br />
<br />
When prevented, the avatar is unable to touch/grab objects rezzed in-world, i.e. not attachments and HUDs.<br />
<br />
<br />
* '''''Remove/add exceptions to the touchworld prevention''''' : "@touchworld:<UUID>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can touch this object in particular.<br />
<br />
<br />
* '''''Allow/prevent touching one object in particular''''' : @touchthis:<UUID>=<rem/add><br />
''Implemented in v2.5''<br />
<br />
When prevented, the avatar is unable to touch/grab the object which UUID corresponds to the one specified in the command.<br />
<br />
<br />
* '''''Remove/add an exception to the touch* preventions, for one object only''''' : "@touchme=<rem/add>"<br />
''Implemented in v2.6''<br />
<br />
When adding such an exception, the user can touch this object in particular.<br />
<br />
<br />
* '''''Allow/prevent touching attachments''''' : @touchattach=<y/n><br />
''Implemented in v2.4''<br />
<br />
When prevented, the avatar is unable to touch attachments (theirs and other avatars'), but this does not apply to HUDs.<br />
<br />
<br />
* '''''Allow/prevent touching one's attachments''''' : @touchattachself=<y/n><br />
''Implemented in v2.4''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent touching other people's attachments''''' : @touchattachother=<y/n><br />
''Implemented in v2.4''<br />
<br />
When prevented, the avatar is unable to touch other people's attachments (but they can touch their owns). This does not apply to HUDs.<br />
<br />
===Location===<br />
<br />
* '''''Allow/prevent viewing the world map''''' : @showworldmap=<y/n><br />
''Implemented in v1.11''<br />
<br />
When prevented, the avatar is unable to view the world map, and it closes if it is open when the restriction becomes active.<br />
<br />
<br />
* '''''Allow/prevent viewing the mini map''''' : @showminimap=<y/n><br />
''Implemented in v1.11''<br />
<br />
When prevented, the avatar is unable to view the mini map, and it closes if it is open when the restriction becomes active.<br />
<br />
<br />
* '''''Allow/prevent knowing the current location''''' : @showloc=<y/n><br />
''Implemented in v1.12''<br />
<br />
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).<br />
<br />
===Name Tags and Hovertext===<br />
<br />
* '''''Allow/prevent seeing the names of the people around''''' : @shownames=<y/n><br />
''Implemented in v1.12.2, added more dummy names in v1.16''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent seeing all the hovertexts''''' : @showhovertextall=<y/n><br />
''Implemented in v1.19''<br />
<br />
When prevented, the user is unable to read any hovertext (2D text floating above some prims).<br />
<br />
<br />
* '''''Allow/prevent seeing one hovertext in particular''''' : @showhovertext:<UUID>=<y/n><br />
''Implemented in v1.19''<br />
<br />
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).<br />
<br />
<br />
* '''''Allow/prevent seeing the hovertexts on the HUD of the user''''' : @showhovertexthud=<y/n><br />
''Implemented in v1.19''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent seeing the hovertexts in-world''''' : @showhovertextworld=<y/n><br />
''Implemented in v1.19''<br />
<br />
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.<br />
<br />
===Group===<br />
<br />
* '''''Force the agent to change the active group''''' : @setgroup:<group_name>=force<br />
''Implemented in v2.5''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent activating a group''''' : @setgroup=<y/n><br />
''Implemented in v2.5''<br />
<br />
When prevented, the user is unable to change the active group.<br />
<br />
<br />
* '''''Get the name of the active group''''' : @getgroup=<channel_number><br />
''Implemented in v2.5''<br />
<br />
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.<br />
<br />
<br />
===Viewer Control===<br />
<br />
* '''''Allow/prevent changing some debug settings''''' : @setdebug=<y/n><br />
''Implemented in v1.16''<br />
<br />
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 :<br />
:* AvatarSex (0 : Female, 1 : Male) : gender of the avatar at creation.<br />
:* 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.<br />
<br />
* '''''Force change a debug setting''''' : @setdebug_<setting>:<value>=force (*)<br />
''Implemented in v1.16''<br />
<br />
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.<br />
<br />
See the list of allowed debug settings in the @setdebug command hereabove.<br />
<br />
<br />
* '''''Get the value of a debug setting''''' : @getdebug_<setting>=<channel_number><br />
''Implemented in v1.16''<br />
<br />
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.<br />
<br />
See the list of allowed debug settings in the @setdebug command hereabove.<br />
<br />
<br />
* '''''Allow/prevent changing the environment settings''''' : @setenv=<y/n><br />
''Implemented in v1.14''<br />
<br />
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).<br />
<br />
<br />
* '''''Force change an environment setting''''' : @setenv_<setting>:<value>=force (*)<br />
''Implemented in v1.14''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Each particular sub-command works as follows (the names are chosen to be as close to the Windlight panels of the viewer as possible) :<br />
<br />
{| border="1" cellpadding="5"<br />
| '''@setenv_XXX:<value>=force where XXX is...''' || '''<value> range''' || '''Sets...'''<br />
|-<br />
| 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'''<br />
|-<br />
| 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'''<br />
|-<br />
| ambientr || 0.0-1.0 || Ambient light, Red channel<br />
|-<br />
| ambientg || 0.0-1.0 || Ambient light, Green channel<br />
|-<br />
| ambientb || 0.0-1.0 || Ambient light, Blue channel<br />
|-<br />
| ambienti || 0.0-1.0 || Ambient light, Intensity<br />
|-<br />
| bluedensityr || 0.0-1.0 || Blue Density, Red channel<br />
|-<br />
| bluedensityg || 0.0-1.0 || Blue Density, Green channel<br />
|-<br />
| bluedensityb || 0.0-1.0 || Blue Density, Blue channel<br />
|-<br />
| bluedensityi || 0.0-1.0 || Blue Density, Intensity<br />
|-<br />
| bluehorizonr || 0.0-1.0 || Blue Horizon, Red channel<br />
|-<br />
| bluehorizong || 0.0-1.0 || Blue Horizon, Green channel<br />
|-<br />
| bluehorizonb || 0.0-1.0 || Blue Horizon, Blue channel<br />
|-<br />
| bluehorizoni || 0.0-1.0 || Blue Horizon, Intensity<br />
|-<br />
| cloudcolorr || 0.0-1.0 || Cloud color, Red channel<br />
|-<br />
| cloudcolorg || 0.0-1.0 || Cloud color, Green channel<br />
|-<br />
| cloudcolorb || 0.0-1.0 || Cloud color, Blue channel<br />
|-<br />
| cloudcolori || 0.0-1.0 || Cloud color, Intensity<br />
|-<br />
| cloudcoverage || 0.0-1.0 || Cloud coverage<br />
|-<br />
| cloudx || 0.0-1.0 || Cloud offset X<br />
|-<br />
| cloudy || 0.0-1.0 || Cloud offset Y<br />
|-<br />
| cloudd || 0.0-1.0 || Cloud density<br />
|-<br />
| clouddetailx || 0.0-1.0 || Cloud detail X<br />
|-<br />
| clouddetaily || 0.0-1.0 || Cloud detail Y<br />
|-<br />
| clouddetaild || 0.0-1.0 || Cloud detail density<br />
|-<br />
| cloudscale || 0.0-1.0 || Cloud scale<br />
|-<br />
| cloudscrollx || 0.0-1.0 || Cloud scroll X<br />
|-<br />
| cloudscrolly || 0.0-1.0 || Cloud scroll Y<br />
|-<br />
| densitymultiplier || 0.0-0.9 || Density multiplier of the fog<br />
|-<br />
| distancemultiplier || 0.0-100.0 || Distance multiplier of the fog<br />
|-<br />
| eastangle || 0.0-1.0 || Position of the east, 0.0 is normal<br />
|-<br />
| hazedensity || 0.0-1.0 || Density of the haze<br />
|-<br />
| hazehorizon || 0.0-1.0 || Haze at the horizon<br />
|-<br />
| maxaltitude || 0.0-4000.0 || Maximum altitude of the fog<br />
|-<br />
| scenegamma || 0.0-10.0 || Overall gamma, 1.0 is normal<br />
|-<br />
| starbrightness|| 0.0-2.0 || Brightness of the stars<br />
|-<br />
| sunglowfocus || 0.0-0.5 || Focus of the glow of the sun<br />
|-<br />
| sunglowsize || 1.0-2.0 || Size of the glow of the sun<br />
|-<br />
| sunmooncolorr || 0.0-1.0 || Sun and moon, Red channel<br />
|-<br />
| sunmooncolorg || 0.0-1.0 || Sun and moon, Green channel<br />
|-<br />
| sunmooncolorb || 0.0-1.0 || Sun and moon, Blue channel<br />
|-<br />
| sunmooncolori || 0.0-1.0 || Sun and moon, Intensity<br />
|-<br />
| sunmoonposition || 0.0-1.0 || Position of the sun/moon, different from "daytime", '''use this to set the apparent sunlight after loading a Preset'''<br />
|}<br />
<br />
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.<br />
<br />
* '''''Get the value of an environment setting''''' : @getenv_<setting>=<channel_number><br />
''Implemented in v1.15''<br />
<br />
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 /><br />
Note: only @getenv_daytime is supported by v1.19.0 (or older, i.e. non Windlight) viewers implementing RestrainedLove v1.15 and later.<br />
<br />
===Footnotes===<br />
<br />
(*) Silently discarded if the user is prevented from doing so by the corresponding restriction. This is on purpose.<br />
Ex : Force detach won't work if the object is undetachable. Force undress won't work if the user is prevented from undressing.<br />
<br />
==Important note about the global behaviours such as sendchat==<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Shared Folders==<br />
<br />
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.<br />
<br />
"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".<br />
<br />
To do this :<br />
* 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".<br />
* Move a folder containing restraints or other attachments directly into this new folder.<br />
* Wear the contents of that folder, that's it !<br />
<br />
So it would look like this :<br />
<br />
My Inventory<br />
|- #RLV<br />
| |- cuffs<br />
| | |- left cuff (l forearm) (no copy)<br />
| | \- right cuff (r forearm) (no copy)<br />
| \- gag<br />
| \- gag (mouth) (no copy)<br />
|- Animations<br />
|- Body Parts<br />
.<br />
.<br />
.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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...).<br />
<br />
HOW TO SHARE NO-MODIFY ITEMS :<br />
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.<br />
<br />
Example with no-modify shoes :<br />
<br />
My Inventory<br />
|- #RLV<br />
| \- shoes<br />
| |- left shoe (left foot)<br />
| | \- left shoe (no modify) (no transfer) <-- no-mod object<br />
| |- right shoe (right foot)<br />
| | \- right shoe (no modify) (no transfer) <-- no-mod object<br />
| \- shoe base (no modify) (no transfer) <-- this is not an object<br />
|- Animations<br />
|- Body Parts<br />
.<br />
.<br />
.<br />
<br />
GOTCHAS :<br />
* Do NOT put a comma (',') in the name of the folders under the shared root or it would screw the list up.<br />
* 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.<br />
* 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.<br />
* 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).<br />
<br />
<br />
'''''Accept sub-folders given via llGiveInventoryList() into the shared folder''''' :<br />
<br />
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).<br />
<br />
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).<br />
<br />
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).<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
==For your information==<br />
Here is how it works internally, for a better understanding of the gotchas you may encounter :<br />
* 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).<br />
<br />
* 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.<br />
<br />
* 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).<br />
<br />
* 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.<br />
<br />
* 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.<br />
If '''''UUID1''''' is a collar and '''''UUID2''''' is a gag :<br />
<br />
'''''UUID1''''' => detach, tploc, tplm, tplure, sittp<br />
<br />
'''''UUID2''''' => detach, sendim, sendim:(keyholder)<br />
<br />
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 :<br />
<br />
'''''UUID1''''' => detach, tploc, tplm, tplure, sittp, sendim<br />
<br />
'''''UUID2''''' => detach, sendim, sendim:(keyholder)<br />
<br />
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.<br />
<br />
* One-shot commands, on the other hand, are executed on-the-fly and are not stored.<br />
<br />
* 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).<br />
<br />
* 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.<br />
<br />
[[Category:Third Party Client]]<br />
[[Category:RestrainedLove]]</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=LSL_Protocol/RestrainedLoveAPI&diff=1179199LSL Protocol/RestrainedLoveAPI2013-06-14T04:50:03Z<p>Tonya Souther: /* Version Checking */ @version in an IM is not always totally stealthy</p>
<hr />
<div>{{LSL Header|ml=*}}<br />
=Restrained Love viewer v2.8.1 Specification=<br />
<br />
By [[User:Marine Kelley|Marine Kelley]]<br />
<br />
==Audience==<br />
<br />
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.<br />
<br />
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]]<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Architecture==<br />
<br />
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.<br />
<br />
The syntax of a message is:<br />
<br />
: <code>@<command1>[:option1]=<param1>,<command2>[:option2]=<param2>,...,<commandN>[:optionN]=<paramN></code><br />
<br />
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.<br />
<br />
: 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
{{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.}}<br />
<br />
==List of commands==<br />
<br />
'''Note:''' These commands are not case-sensitive but are spacing-sensitive. In other words, "@detach = n" will '''not''' work.<br />
<br />
'''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.<br />
<br />
'''Footnotes:''' "(*)" are footnotes and will be explained at the end of the list<br />
<br />
===Version Checking===<br />
<br />
* '''''Automated version checking''''' : "@version=<channel_number>"<br />
''Implemented in v1.0b''<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
* '''''Automated version checking''''' : "@versionnew=<channel_number>"<br />
''Implemented in v1.23''<br />
<br />
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.<br />
<br />
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).<br />
<br />
'''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.<br />
<br />
<br />
* '''''Automated version number checking''''' : "@versionnum=<channel_number>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
* '''''Automated version checking, second way''''' : llGetAgentLanguage (key id) '''''DEPRECATED: DO NOT USE !'''''<br />
''Implemented in v1.16''<br />
<br />
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).<br />
<br />
<br />
* '''''Manual version checking''''' : "@version"<br />
''Implemented in v1.0a''<br />
<br />
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 usually totally stealthy. However, some viewers, such as Firestorm, have the ability to send an autoreply message when someone begins typing an IM to the user. If the user has that option enabled, an IM window will open and display the auto response as soon as the @ is typed by the sender, but nothing else.<br />
<br />
===Blacklist handling===<br />
<br />
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.<br />
<br />
<br />
* '''''Automated version number checking, followed by the blacklist''''' : "@versionnumbl=<channel_number>"<br />
''Implemented in v2.8''<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
* '''''Get the contents of the blacklist, with a filter''''' : "@getblacklist[:filter]=<channel_number>"<br />
''Implemented in v2.8''<br />
<br />
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.<br />
<br />
<br />
* '''''Manual blacklist checking''''' : "@getblacklist"<br />
''Implemented in v2.8''<br />
<br />
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.<br />
<br />
===Miscellaneous===<br />
<br />
* '''''Start/stop notifications on a private channel''''' : "@notify:<channel_number>[;word]=<rem/add>"<br />
''Implemented in v1.20, improved in v2.2 (and v1.24)''<br />
<br />
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.<br />
<br />
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 :<br />
<br />
:* /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).<br />
<br />
:* /accepted_in_inv inv_offer <folder> : The folder has been accepted but is not shared.<br />
<br />
:* /declined inv_offer <folder> : The folder has been declined and/or the user has pressed "Block" (formerly "Mute").<br />
<br />
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.<br />
<br />
Note 2 : Since v2.5 the viewer also sends notifications when wearing outfits :<br />
<br />
:* /worn legally <layer> : The avatar has just worn a piece of clothing on the indicated layer.<br />
<br />
:* /unworn legally <layer> : The avatar has just removed a piece of clothing from the indicated layer.<br />
<br />
:* /attached legally <attach_point_name> : The avatar has just attached an object to the indicated attachment point.<br />
<br />
:* /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.<br />
<br />
:* /detached legally <attach_point_name> : The avatar has just detached an object from the indicated attachment point.<br />
<br />
:* /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.<br />
<br />
<br />
* '''''Allow/deny permissive exceptions''''' : "@permissive=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
'''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 !<br />
<br />
<br />
* '''''Clear all the rules tied to an object''''' : "@clear"<br />
''Implemented in v1.0a, but working only since v1.04a''<br />
<br />
This command clears all the restrictions and exceptions tied to a particular [[UUID]].<br />
<br />
'''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.<br />
<br />
Possible workarounds:<br />
:* only lift the exact restrictions you added with @clear=<pattern> <br />
:* only trigger @clear on detach when you are sure the attachment is not locked<br />
:* don't trigger @clear on detach at all and wait for the viewer to lift the set restrictions<br />
<br />
<br />
* '''''Clear a subset of the rules tied to an object''''' : "@clear=<string>"<br />
''Implemented in v1.0a, but working only since v1.04a''<br />
<br />
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<br />
<br />
<br />
* '''''Get the list of restrictions the avatar is currently submitted to''''' : @getstatus[:<part_of_rule>[;<custom_separator>]]=<channel><br />
''Implemented in v1.10, slightly tweaked in v1.16 and v2.8''<br />
<br />
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 !<br />
<br />
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.<br />
<br />
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.<br />
<br />
<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.<br />
<br />
Example : If the avatar is under tploc, tplure, tplm and sittp, here is what the script would get :<br />
@getstatus=2222 => /tploc/tplure/tplm/sittp<br />
@getstatus:sittp=2222 => /sittp<br />
@getstatus:tpl=2222 => /tploc/tplure/tplm (because "tpl" is part of "tploc", "tplure" and "tplm" but not "sittp")<br />
@getstatus:tpl;#=2222 => #tploc#tplure#tplm (because "tpl" is part of "tploc", "tplure" and "tplm" but not "sittp", and the<br />
specified separator is "#")<br />
@getstatus:;#=2222 => #tploc#tplure#tplm#sittp (because the specified separator is "#")<br />
@getstatus:;=2222 => /tploc/tplure/tplm/sittp (because the specified separator is empty, so it defaults to "/")<br />
<br />
<br />
* '''''Get the list of all the restrictions the avatar is currently submitted to''''' : @getstatusall[:<part_of_rule>[;<custom_separator>]]=<channel><br />
''Implemented in v1.15, slightly tweaked in v1.16 and v2.8''<br />
<br />
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 !<br />
<br />
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.<br />
<br />
===Movement===<br />
<br />
* '''''Allow/prevent flying''''' : @fly=<y/n><br />
''Implemented in v1.12.2''<br />
<br />
When prevented, the user is unable to fly.<br />
<br />
<br />
* '''''Allow/prevent running by double-tapping an arrow key''''' : @temprun=<y/n><br />
''Implemented in v2.7''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent always running''''' : @alwaysrun=<y/n><br />
''Implemented in v2.7''<br />
<br />
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.<br />
<br />
<br />
* '''''Force rotate the avatar to a set direction''''' : @setrot:<angle_in_radians>=force<br />
''Implemented in v1.17''<br />
<br />
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.<br />
<br />
<br />
* '''''Change the height of the avatar''''' : @adjustheight:<distance_pelvis_to_foot_in_meters>;<factor>[;delta_in_meters]=force<br />
''Implemented in v2.5''<br />
<br />
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.<br />
<br />
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]<br />
<br />
===Chat, Emotes and Instant Messages===<br />
====Chat====<br />
* '''''Allow/prevent sending chat messages''''' : "@sendchat=<y/n>"<br />
''Implemented in v1.0b''<br />
<br />
When prevented, everything typed on [[Chat channel|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.<br />
<br />
<br />
* '''''Allow/prevent shouting''''' : "@chatshout=<y/n>"<br />
''Implemented in v1.15''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent chatting at normal volume''''' : "@chatnormal=<y/n>"<br />
''Implemented in v1.15''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent whispering''''' : "@chatwhisper=<y/n>"<br />
''Implemented in v1.15''<br />
<br />
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.<br />
<br />
<br />
* '''''Redirect public chat to private channels''''' : "@redirchat:<channel_number>=<rem/add>"<br />
''Implemented in v1.16''<br />
<br />
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.<br />
'''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).<br />
<br />
<br />
* '''''Allow/prevent receiving chat messages''''' : "@recvchat=<y/n>"<br />
''Implemented in v1.0b''<br />
<br />
When prevented, everything heard in public chat will be discarded except emotes.<br />
<br />
<br />
* '''''Allow/prevent receiving chat messages, secure way''''' : "@recvchat_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the chat message receiving prevention''''' : "@recvchat:<UUID>=<rem/add>"<br />
''Implemented in v1.01''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent receiving chat messages from someone in particular''''' : "@recvchatfrom:<UUID>=<y/n>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, everything heard in public chat from the specified avatar will be discarded except emotes.<br />
<br />
<br />
====Emotes====<br />
* '''''Remove/add an exception to the emote truncation above''''' : "@emote=<rem/add>"<br />
''Implemented in v1.01''<br />
<br />
When adding this exception, the emotes are not truncated anymore (however, special signs will still discard the message).<br />
<br />
<br />
* '''''Redirect public emotes to private channels''''' : "@rediremote:<channel_number>=<rem/add>"<br />
''Implemented in v1.19''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent seeing emotes''''' : "@recvemote=<y/n>"<br />
''Implemented in v1.19''<br />
<br />
When prevented, every emote seen in public chat will be discarded.<br />
<br />
<br />
* '''''Allow/prevent receiving emotes seen in public chat from someone in particular''''' : "@recvemotefrom:<UUID>=<y/n>"<br />
''Implemented in v2.4''<br />
<br />
When prevented, everything emote seen in public chat from the specified avatar will be discarded.<br />
<br />
<br />
* '''''Allow/prevent seeing emotes, secure way''''' : "@recvemote_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the emote seeing prevention''''' : "@recvemote:<UUID>=<rem/add>"<br />
''Implemented in v1.19''<br />
<br />
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.<br />
<br />
<br />
====Private Channels====<br />
* '''''Allow/prevent using any chat channel but certain channels''''' : @sendchannel[:<channel>]=<y/n><br />
''Implemented in v1.10''<br />
<br />
Complimentary of @sendchat, this command prevents the user from sending messages on non-public Chat channels. 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. <br />
<br />
<br />
* '''''Allow/prevent using any chat channel but certain channels, secure way''''' : @sendchannel_sec[:<channel>]=<y/n><br />
''Implemented in v1.10''<br />
<br />
Complimentary of @sendchat, this command prevents the user from sending messages on non-public channels. 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.<br />
<br />
<br />
====Instant Messages====<br />
* '''''Allow/prevent sending instant messages''''' : "@sendim=<y/n>"<br />
''Implemented in v1.0b''<br />
<br />
When prevented, everything typed in IM will be discarded and a bogus message will be sent to the receiver instead.<br />
<br />
<br />
* '''''Allow/prevent sending instant messages, secure way''''' : "@sendim_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the instant message sending prevention''''' : "@sendim:<UUID>=<rem/add>"<br />
''Implemented in v1.01''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent sending instant messages to someone in particular''''' : "@sendimto:<UUID>=<y/n>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, everything typed in IM to the specified avatar will be discarded and a bogus message will be sent instead.<br />
<br />
<br />
* '''''Allow/prevent starting an IM session with anyone''''' : "@startim=<y/n>"<br />
''Implemented in v2.6''<br />
<br />
When prevented, the user is unable to start an IM session with anyone. Sessions that are already open are not impacted though.<br />
<br />
<br />
* '''''Remove/add exceptions to the IM session start prevention''''' : "@startim:<UUID>=<rem/add>"<br />
''Implemented in v2.6''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent starting an IM session with someone in particular''''' : "@startimto:<UUID>=<y/n>"<br />
''Implemented in v2.6''<br />
<br />
When prevented, the user is unable to start an IM session with that person. Sessions that are already open are not impacted though.<br />
<br />
<br />
* '''''Allow/prevent receiving instant messages''''' : "@recvim=<y/n>"<br />
''Implemented in v1.0b''<br />
<br />
When prevented, every incoming IM will be discarded and the sender will be notified that the user cannot read them.<br />
<br />
<br />
* '''''Allow/prevent receiving instant messages, secure way''''' : "@recvim_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the instant message receiving prevention''''' : "@recvim:<UUID>=<rem/add>"<br />
''Implemented in v1.01''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent receiving instant messages from someone in particular''''' : "@recvimfrom:<UUID>=<y/n>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
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.<br />
<br />
===Teleportation===<br />
<br />
* '''''Allow/prevent teleporting to a landmark''''' : "@tplm=<y/n>"<br />
''Implemented in v1.0''<br />
<br />
When prevented, the user cannot use a [[landmark]], pick or any other preset location to [[teleport]] there.<br />
<br />
<br />
* '''''Allow/prevent teleporting to a location''''' : "@tploc=<y/n>"<br />
''Implemented in v1.0''<br />
<br />
When prevented, the user cannot use [[teleport]] to a coordinate by using the [[map]] and such.<br />
<br />
<br />
* '''''Allow/prevent teleporting by a friend''''' : "@tplure=<y/n>"<br />
''Implemented in v1.0''<br />
<br />
When prevented, the user automatically discards any [[teleport]] offer, and the avatar who initiated the offer is notified.<br />
<br />
<br />
* '''''Allow/prevent teleporting by a friend, secure way''''' : "@tplure_sec=<y/n>"<br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
<br />
* '''''Remove/add exceptions to the friend teleport prevention''''' : "@tplure:<UUID>=<rem/add>"<br />
''Implemented in v1.0''<br />
<br />
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.<br />
<br />
<br />
* '''''Unlimit/limit sit-tp''''' : "@sittp=<y/n>"<br />
''Implemented in v1.0''<br />
<br />
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).<br />
<br />
<br />
* '''''Allow/prevent standing up at a different location than where we sat down''''' : @standtp=<y/n><br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
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.<br />
<br />
<br />
* '''''Force-Teleport the user''''' : @tpto:<X>/<Y>/<Z>=force (*)<br />
''Implemented in v1.12''<br />
<br />
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.<br />
<br />
Here is a sample code to call that command properly :<br />
<br />
<lsl><br />
<br />
// FORCE TELEPORT EXAMPLE<br />
// Listens on channel 4 for local coordinates and a sim name<br />
// and tells your viewer to teleport you there.<br />
//<br />
// By Marine Kelley 2008-08-26<br />
// RLV version required : 1.12 and above<br />
//<br />
// HOW TO USE :<br />
// * Create a script inside a box<br />
// * Overwrite the contents of the script with this one<br />
// * Wear the box<br />
// * Say the destination coords Region/X/Y/Z on channel 4 :<br />
// Example : /4 Help Island Public/128/128/50<br />
<br />
key kRequestHandle; // UUID of the dataserver request<br />
vector vLocalPos; // local position extracted from the<br />
<br />
Init () {<br />
kRequestHandle = NULL_KEY;<br />
llListen (4, "", llGetOwner (), "");<br />
}<br />
<br />
<br />
default<br />
{<br />
state_entry () {<br />
Init ();<br />
}<br />
<br />
on_rez(integer start_param) {<br />
Init ();<br />
}<br />
<br />
listen(integer channel, string name, key id, string message) {<br />
list tokens = llParseString2List (message, ["/"], []);<br />
integer L = llGetListLength (tokens);<br />
<br />
if (L==4) {<br />
// Extract local X, Y and Z<br />
vLocalPos.x = llList2Float (tokens, 1);<br />
vLocalPos.y = llList2Float (tokens, 2);<br />
vLocalPos.z = llList2Float (tokens, 3);<br />
<br />
// Request info about the sim<br />
kRequestHandle=llRequestSimulatorData (llList2String (tokens, 0), DATA_SIM_POS);<br />
}<br />
}<br />
<br />
dataserver(key queryid, string data) {<br />
if (queryid == kRequestHandle) {<br />
// Parse the dataserver response (it is a vector cast to a string)<br />
list tokens = llParseString2List (data, ["<", ",", ">"], []);<br />
string pos_str = "";<br />
vector global_pos;<br />
<br />
// The coordinates given by the dataserver are the ones of the<br />
// South-West corner of this sim<br />
// => offset with the specified local coordinates<br />
global_pos.x = llList2Float (tokens, 0);<br />
global_pos.y = llList2Float (tokens, 1);<br />
global_pos.z = llList2Float (tokens, 2);<br />
global_pos += vLocalPos;<br />
<br />
// Build the command<br />
pos_str = (string)((integer)global_pos.x)<br />
+"/"+(string)((integer)global_pos.y)<br />
+"/"+(string)((integer)global_pos.z);<br />
llOwnerSay ("Global position : "+(string)pos_str); // Debug purposes<br />
<br />
// Fire !<br />
llOwnerSay ("@tpto:"+pos_str+"=force");<br />
}<br />
}<br />
<br />
}<br />
<br />
</lsl><br />
<br />
<br />
<br />
* '''''Remove/add auto-accept teleport offers from a particular avatar''''' : "@accepttp[:<UUID>]=<rem/add>"<br />
''Implemented in v1.15, slightly improved in v1.16''<br />
<br />
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 !<br />
<br />
===Inventory, Editing and Rezzing===<br />
<br />
* '''''Allow/prevent using inventory''''' : @showinv=<y/n><br />
''Implemented in v1.10''<br />
<br />
Forces the [[inventory]] windows to close and stay closed.<br />
<br />
<br />
* '''''Allow/prevent reading notecards''''' : @viewnote=<y/n><br />
''Implemented in v1.10''<br />
<br />
Prevents from opening [[notecards]] but does not close the ones already open.<br />
<br />
<br />
* '''''Allow/prevent opening scripts''''' : @viewscript=<y/n><br />
''Implemented in v1.22''<br />
<br />
Prevents from opening [[scripts]] but does not close the ones already open.<br />
<br />
<br />
* '''''Allow/prevent opening textures''''' : @viewtexture=<y/n><br />
''Implemented in v1.22''<br />
<br />
Prevents from opening [[textures]] (and snapshots) but does not close the ones already open.<br />
<br />
<br />
* '''''Allow/prevent editing objects''''' : "@edit=<y/n>"<br />
''Implemented in v1.03''<br />
<br />
When prevented from editing and opening objects, the Build & Edit window will refuse to open.<br />
<br />
<br />
* '''''Remove/add exceptions to the edit prevention''''' : "@edit:<UUID>=<rem/add>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
When adding an exception, the user can edit or open this object in particular.<br />
<br />
<br />
* '''''Allow/prevent rezzing inventory''''' : "@rez=<y/n>"<br />
''Implemented in v1.03''<br />
<br />
When prevented from [[rez]]zing stuff, creating and deleting objects, drag-dropping from inventory and dropping attachments will fail.<br />
<br />
<br />
* '''''Allow/prevent editing particular objects''''' : "@editobj:<UUID>=<y/n>"<br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, the Build & Edit window will refuse to open when trying to edit or open the specified object.<br />
<br />
===Sitting===<br />
<br />
* '''''Allow/prevent standing up''''' : @unsit=<y/n><br />
''Implemented in v1.10, modified in v1.15 to prevent teleporting as well''<br />
<br />
Hides the Stand up button. From v1.15 it also prevents teleporting, which was a way to stand up.<br />
<br />
<br />
* '''''Force sit on an object''''' : @sit:<UUID>=force (*)<br />
''Implemented in v1.10''<br />
<br />
Does not work if the user is prevented from sit-tping and further than 1.5 meters away, or when prevented from unsitting.<br />
<br />
<br />
* '''''Get the UUID of the object the avatar is sitting on''''' : @getsitid=<channel_number><br />
''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)''<br />
<br />
Makes the viewer automatically answer the UUID of the object the avatar is currently sitting on, or NULL_KEY if they are not sitting.<br />
<br />
<br />
* '''''Force unsit''''' : @unsit=force (*)<br />
''Implemented in v1.10''<br />
<br />
Self-explanatory but for some reason it randomly fails, so don't rely on it for now. Further testing is needed.<br />
<br />
<br />
* '''''Allow/prevent sitting down''''' : @sit=<y/n><br />
''Implemented in v1.16.2''<br />
<br />
Prevents the user from sitting on anything, including with @sit:<UUID>=force.<br />
<br />
===Clothing and Attachments===<br />
<br />
* '''''Render an object detachable/nondetachable''''' : "@detach=<y/n>"<br />
''Implemented in v1.0a''<br />
<br />
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.<br />
<br />
<br />
* '''''Unlock/Lock an attachment point''''' : "@detach:<attach_point_name>=<y/n>"<br />
''Implemented in v1.20''<br />
<br />
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).<br />
<br />
<br />
* '''''Unlock/Lock an attachment point empty''''' : "@addattach[:<attach_point_name>]=<y/n>"<br />
''Implemented in v1.22''<br />
<br />
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.<br />
<br />
<br />
* '''''Unlock/Lock an attachment point full''''' : "@remattach[:<attach_point_name>]=<y/n>"<br />
''Implemented in v1.22''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/deny the "Wear" contextual menu''''' : "@defaultwear=<y/n><br />
''Implemented in v1.21''<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
* '''''Force removing attachments''''' : @detach[:attachpt]=force (*) <br />
''Implemented in v1.10''<br />
<br />
Where part is :<br />
chest|skull|left shoulder|right shoulder|left hand|right hand|left foot|right foot|spine|<br />
pelvis|mouth|chin|left ear|right ear|left eyeball|right eyeball|nose|r upper arm|r forearm|<br />
l upper arm|l forearm|right hip|r upper leg|r lower leg|left hip|l upper leg|l lower leg|stomach|left pec|<br />
right pec|center 2|top right|top|top left|center|bottom left|bottom|bottom right|neck|root<br />
If part is not specified, removes everything.<br />
<br />
<br />
* '''''Force removing attachments (alias)''''' : @remattach[:attachpt]=force (*) <br />
''Implemented in v1.22''<br />
<br />
This command is an alias to @detach[:attachpt]=force (to keep things consistent).<br />
<br />
<br />
* '''''Allow/prevent wearing clothes''''' : @addoutfit[:<part>]=<y/n><br />
''Implemented in v1.10, added skin hair and eyes in v1.10.1, added physics in 2.6.1''<br />
<br />
Where part is :<br />
gloves|jacket|pants|shirt|shoes|skirt|socks|underpants|undershirt|skin|eyes|hair|shape|alpha|tattoo|physics<br />
If part is not specified, prevents from wearing anything beyond what the avatar is already wearing.<br />
<br />
'''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.<br />
<br />
<br />
* '''''Allow/prevent removing clothes''''' : @remoutfit[:<part>]=<y/n> (underpants and undershirt are kept for teens)<br />
''Implemented in v1.10, added skin hair and eyes in v1.10.1, added physics in 2.6.1''<br />
<br />
Where part is :<br />
gloves|jacket|pants|shirt|shoes|skirt|socks|underpants|undershirt|skin|eyes|hair|shape|alpha|tattoo|physics<br />
If part is not specified, prevents from removing anything in what the avatar is wearing.<br />
<br />
'''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.<br />
<br />
<br />
* '''''Force removing clothes''''' : @remoutfit[:<part>]=force (*) (teens can't be forced to remove underpants and undershirt)<br />
''Implemented in v1.10''<br />
<br />
Where part is :<br />
gloves|jacket|pants|shirt|shoes|skirt|socks|underpants|undershirt|alpha|tattoo|physics<br />
If part is not specified, removes everything.<br />
<br />
'''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.<br />
<br />
'''Note:''' skin, shape, eyes and hair cannot be removed since they are body parts (and removing any would result in an unrezzed avatar).<br />
<br />
<br />
* '''''Get the list of worn clothes''''' : @getoutfit[:part]=<channel_number><br />
''Implemented in v1.10, added skin hair and eyes in v1.10.1, added physics in 2.6.1''<br />
<br />
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.<br />
<br />
The list of 0s and 1s corresponds to :<br />
gloves,jacket,pants,shirt,shoes,skirt,socks,underpants,undershirt,skin,eyes,hair,shape<br />
in that order.<br />
<br />
If a part is specified, answers a single 0 (empty) or 1 (occupied) corresponding to the part.<br />
Ex 1 : @getoutfit=2222 => "0011000111" => avatar is wearing pants, shirt, underpants and undershirt, and of course a skin.<br />
Ex 2 : @getoutfit:socks=2222 => "0" => the avatar is not wearing socks.<br />
<br />
'''Note:''' For viewers that implement the new Viewer 2.0 features, the list is:<br />
<br />
gloves,jacket,pants,shirt,shoes,skirt,socks,underpants,undershirt,skin,eyes,hair,shape,alpha,tattoo<br />
<br />
<br />
* '''''Get the list of worn attachments''''' : @getattach[:attachpt]=<channel_number><br />
''Implemented in v1.10''<br />
<br />
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.<br />
<br />
The list of 0s and 1s corresponds to :<br />
none,chest,skull,left shoulder,right shoulder,left hand,right hand,left foot,right foot,spine,<br />
pelvis,mouth,chin,left ear,right ear,left eyeball,right eyeball,nose,r upper arm,r forearm,<br />
l upper arm,l forearm,right hip,r upper leg,r lower leg,left hip,l upper leg,l lower leg,stomach,left pec,<br />
right pec,center 2,top right,top,top left,center,bottom left,bottom,bottom right,neck,root<br />
in that order.<br />
<br />
If an attachment point is specified, answers a single 0 (empty) or 1 (occupied) corresponding to the point.<br />
Ex 1 : @getattach=2222 => "011000011010000000000000100100000000101" => avatar is wearing attachments on <br />
chest, skull, left and right foot, pelvis, l and r lower leg, HUD bottom left and HUD bottom right.<br />
Ex 2 : @getattach:chest=2222 => "1" => avatar is wearing something on the chest.<br />
<br />
''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.<br />
<br />
<br />
* '''''Force the viewer to automatically accept attach and take control permission requests''''' : @acceptpermission=<rem/add><br />
''Implemented in v1.16''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent accepting attach and take control permissions''''' : @denypermission=<rem/add><br />
''Implemented in v1.16, DEPRECATED in v1.16.2''<br />
<br />
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 !<br />
<br />
<br />
* '''''Force detach an item''''' : @detachme=force (*)<br />
''Implemented in v1.16.2''<br />
<br />
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.<br />
<br />
===Clothing and Attachments (Shared Folders)===<br />
<br />
* '''''Allow/prevent wearing clothes and attachments that are not part of the #RLV folder''''' : @unsharedwear=<y/n><br />
''Implemented in v2.5''<br />
<br />
When prevented, no object, piece of clothing or bodypart can be worn unless it is part of the #RLV folder (i.e. "shared").<br />
<br />
<br />
* '''''Allow/prevent removing clothes and attachments that are not part of the #RLV folder''''' : @unsharedunwear=<y/n><br />
''Implemented in v2.5''<br />
<br />
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").<br />
<br />
<br />
* '''''Get the list of shared folders in the avatar's inventory''''' : @getinv[:folder1/.../folderN]=<channel_number><br />
''Implemented in v1.11, added sub-folders in v1.13''<br />
<br />
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.<br />
<br />
The answer is a list of names, separated by commas (","). Folders which names begin with a dot (".") will be ignored.<br />
<br />
<br />
* '''''Get the list of shared folders in the avatar's inventory, with information about worn items''''' : @getinvworn[:folder1/.../folderN]=<channel_number><br />
''Implemented in v1.15''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Object : "@getinvworn:Restraints/Leather cuffs=2222"<br />
Viewer : "|02,Arms|30,Legs|10"<br />
<br />
Folders which names begin with a dot (".") will be ignored. The two digits are calculated as follows :<br />
<br />
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".<br />
<br />
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".<br />
<br />
The digits, comprised between 0 and 3 included, have the following meaning :<br />
<br />
:* 0 : No item is present in that folder<br />
:* 1 : Some items are present in that folder, but none of them is worn<br />
:* 2 : Some items are present in that folder, and some of them are worn<br />
:* 3 : Some items are present in that folder, and all of them are worn<br />
<br />
<br />
* '''''Get the path to a shared folder by giving a search criterion''''' : @findfolder:part1[&&...&&partN]=<channel_number><br />
''Implemented in v1.13.1''<br />
<br />
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 ('/').<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder''''' : @attach:<folder1/.../folderN>=force (*)<br />
''Implemented in v1.11, added no-mod items in v1.12, added sub-folders in v1.13''<br />
<br />
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.<br />
<br />
Attachment point names are the same as the ones contained into the "Attach To" submenu : "skull", "chest", "l forearm"...<br />
<br />
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.<br />
<br />
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.<br />
<br />
'''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.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, without replacing what is already being worn''''' : @attachover:<folder1/.../folderN>=force (*)<br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
This command works exactly like @attach described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder''''' : @attachoverorreplace:<folder1/.../folderN>=force (*)<br />
''Implemented in v2.5''<br />
<br />
This command works exactly like @attach described hereabove, it is a synonym.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, and its children recursively''''' : @attachall:<folder1/.../folderN>=force (*)<br />
''Implemented in v1.15''<br />
<br />
This command works exactly like @attach described hereabove, but also attaches whatever is contained into children folders.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, and its children recursively, without replacing what is already being worn''''' : @attachallover:<folder1/.../folderN>=force (*)<br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
This command works exactly like @attachall described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, and its children recursively''''' : @attachalloverorreplace:<folder1/.../folderN>=force (*)<br />
''Implemented in v2.5''<br />
<br />
This command works exactly like @attachall described hereabove, it is a synonym.<br />
<br />
<br />
* '''''Force detach items contained inside a shared folder''''' : @detach:<folder_name>=force (*)<br />
''Implemented in v1.11''<br />
<br />
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.<br />
<br />
<br />
* '''''Force detach items contained inside a shared folder, and its children recursively''''' : @detachall:<folder1/.../folderN>=force (*)<br />
''Implemented in v1.15''<br />
<br />
This command works exactly like @detach described hereabove, but also detaches whatever is contained into children folders.<br />
<br />
<br />
* '''''Get the path to the shared folder containing a particular object/clothing worn on a point''''' : @getpath[:<attachpt> or <clothing_layer>]=<channel_number><br />
''Implemented in v1.16''<br />
<br />
Makes the viewer automatically answer the path to the shared folder containing the item that :<br />
:* issues this command if no option is set<br />
:* is attached on the attach point provided in the option field, ex : @getpath:spine=2222 => "Restraints/Collar"<br />
:* is worn on the clothing layer provided in the option field, ex : @getpath:pants=2222 => "Casual/Jeans/Tight"<br />
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 ('/').<br />
<br />
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.<br />
<br />
<br />
* '''''Get the all paths to the shared folders containing the objects/clothing worn on a point''''' : @getpathnew[:<attachpt> or <clothing_layer>]=<channel_number><br />
''Implemented in v2.1 and v1.24''<br />
<br />
Makes the viewer automatically answer the paths to the shared folders containing the item(s) that :<br />
:* issues this command if no option is set<br />
:* are attached on the attach point provided in the option field, ex : @getpathnew:spine=2222 => "Restraints/Collar,Jewelry/Cute necklace"<br />
:* is worn on the clothing layer provided in the option field, ex : @getpathnew:pants=2222 => "Casual/Jeans/Tight"<br />
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 (',').<br />
<br />
This command has been added to replace @getpath, since in 2.1 several objects can be worn on the same attachment point.<br />
<br />
<br />
* '''''Force attach items contained into a shared folder that contains a particular object/clothing''''' : @attachthis[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v1.16''<br />
<br />
This command is a shortcut for a @getpath followed with an @attach command (this saves a listener and a timeout).<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, without replacing what is already being worn''''' : @attachthisover[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
This command works exactly like @attachthis described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder''''' : @attachthisoverorreplace[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v2.5''<br />
<br />
This command works exactly like @attachthis described hereabove, it is a synonym.<br />
<br />
<br />
* '''''Force attach items contained into a shared folder that contains a particular object/clothing, and its children folders''''' : @attachallthis[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v1.16''<br />
<br />
This command is a shortcut for a @getpath followed with an @attachall command (this saves a listener and a timeout).<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder, without replacing what is already being worn''''' : @attachallthisover[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v2.1.2 and v1.24''<br />
<br />
This command works exactly like @attachallthis described hereabove, except that it won't kick objects and pieces of clothing that are already being worn.<br />
<br />
<br />
* '''''Force attach items contained inside a shared folder''''' : @attachallthisoverorreplace[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v2.5''<br />
<br />
This command works exactly like @attachallthis described hereabove, it is a synonym.<br />
<br />
<br />
* '''''Force detach items contained into a shared folder that contains a particular object/clothing''''' : @detachthis[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v1.16''<br />
<br />
This command is a shortcut for a @getpath followed with a @detach command (this saves a listener and a timeout).<br />
<br />
<br />
* '''''Force detach items contained into a shared folder that contains a particular object/clothing, and its children folders''''' : @detachallthis[:<attachpt> or <clothing_layer>]=force (*)<br />
''Implemented in v1.16''<br />
<br />
This command is a shortcut for a @getpath followed with a @detachall command (this saves a listener and a timeout).<br />
<br />
<br />
* '''''Allow/prevent removing some folders''''' : @detachthis[:<layer>|<attachpt>|<path_to_folder>]=<y/n><br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, the user is unable to remove a folder if either of these conditions is filled :<br />
:* no option is specified and the folder contains the object that issues this restriction<br />
:* the "layer" option is set (shirt, pants...) and the folder contains a piece of clothing that is worn on this layer<br />
:* the "attachpt" option is set (l forearm, spine...) and the folder contains an attachment that is worn on this point<br />
:* the "path_to_folder" option is set and the folder corresponds to this location<br />
<br />
Moreso, this folder or these folders cannot be renamed, moved, deleted or modified.<br />
<br />
<br />
* '''''Allow/prevent removing some folders and their children''''' : @detachallthis[:<layer>|<attachpt>|<path_to_folder>]=<y/n><br />
''Implemented in v2.3 and v1.25''<br />
<br />
These commands do exactly like @detachthis, but also apply to their children folders recursively.<br />
<br />
<br />
* '''''Allow/prevent wearing some folders''''' : @attachthis:<layer>|<attachpt>|<path_to_folder>=<y/n><br />
''Implemented in v2.3 and v1.25''<br />
<br />
When prevented, the user is unable to attach a folder if either of these conditions is filled :<br />
:* the "layer" option is set (shirt, pants...) and the folder contains a piece of clothing that is meant to be worn on this layer<br />
:* the "attachpt" option is set (l forearm, spine...) and the folder contains an attachment that is meant to be worn on this point<br />
:* the "path_to_folder" option is set and the folder corresponds to this location<br />
<br />
Moreso, this folder or these folders cannot be renamed, moved, deleted or modified.<br />
<br />
<br />
* '''''Allow/prevent wearing some folders and their children''''' : @attachallthis[:<layer>|<attachpt>|<path_to_folder>]=<y/n><br />
''Implemented in v2.3 and v1.25''<br />
<br />
These commands do exactly like @attachthis, but also apply to their children folders recursively.<br />
<br />
<br />
* '''''Remove/add exceptions to the detachallthis restriction, for one folder only''''' : "@detachthis_except:<folder>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can remove the items contained into the indicated folder.<br />
<br />
<br />
* '''''Remove/add exceptions to the detachallthis restriction, for one folder and its children''''' : "@detachallthis_except:<folder>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can remove the items contained into the indicated folder, or in any of its children.<br />
<br />
<br />
* '''''Remove/add exceptions to the attachallthis restriction, for one folder only''''' : "@attachthis_except:<folder>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can wear the items contained into the indicated folder.<br />
<br />
<br />
* '''''Remove/add exceptions to the attachallthis restriction, for one folder and its children''''' : "@attachallthis_except:<folder>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can wear the items contained into the indicated folder, or in any of its children.<br />
<br />
<br />
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.<br />
<br />
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.<br />
<br />
Example :<br />
A script issues a @attachallthis:=n restriction, preventing the whole #RLV folder and its children from being attached. It also issues a<br />
@detachallthis:=n restriction, preventing the whole #RLV folder and its children from being removed as well.<br />
Therefore the #RLV folder is now completely frozen.<br />
<br />
However, the same object issues a @attachallthis:Jewelry/Gold=add exception, then a @detachallthis:Jewelry/Gold=add one, making the Jewelry/Gold<br />
folder available for wearing and removing.<br />
Finally, it issues a @attachallthis:Jewelry/Gold/Watch=n restriction followed by a @detachallthis:Jewelry/Gold/Watch=n restriction.<br />
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<br />
rest is out of reach.<br />
<br />
===Touch===<br />
<br />
* '''''Allow/prevent touching objects located further than 1.5 meters away from the avatar''''' : @fartouch=<y/n><br />
''Implemented in v1.11''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent touching objects located further than 1.5 meters away from the avatar''''' : @touchfar=<y/n><br />
''Implemented in v2.4''<br />
<br />
This command is a synonym of @fartouch<br />
<br />
<br />
* '''''Allow/prevent touching any objects''''' : @touchall=<y/n><br />
''Implemented in v2.4''<br />
<br />
When prevented, the avatar is unable to touch/grab any object and attachment. This does not apply to HUDs.<br />
<br />
<br />
* '''''Allow/prevent touching objects in-world''''' : @touchworld=<y/n><br />
''Implemented in v2.4''<br />
<br />
When prevented, the avatar is unable to touch/grab objects rezzed in-world, i.e. not attachments and HUDs.<br />
<br />
<br />
* '''''Remove/add exceptions to the touchworld prevention''''' : "@touchworld:<UUID>=<rem/add>"<br />
''Implemented in v2.5''<br />
<br />
When adding an exception, the user can touch this object in particular.<br />
<br />
<br />
* '''''Allow/prevent touching one object in particular''''' : @touchthis:<UUID>=<rem/add><br />
''Implemented in v2.5''<br />
<br />
When prevented, the avatar is unable to touch/grab the object which UUID corresponds to the one specified in the command.<br />
<br />
<br />
* '''''Remove/add an exception to the touch* preventions, for one object only''''' : "@touchme=<rem/add>"<br />
''Implemented in v2.6''<br />
<br />
When adding such an exception, the user can touch this object in particular.<br />
<br />
<br />
* '''''Allow/prevent touching attachments''''' : @touchattach=<y/n><br />
''Implemented in v2.4''<br />
<br />
When prevented, the avatar is unable to touch attachments (theirs and other avatars'), but this does not apply to HUDs.<br />
<br />
<br />
* '''''Allow/prevent touching one's attachments''''' : @touchattachself=<y/n><br />
''Implemented in v2.4''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent touching other people's attachments''''' : @touchattachother=<y/n><br />
''Implemented in v2.4''<br />
<br />
When prevented, the avatar is unable to touch other people's attachments (but they can touch their owns). This does not apply to HUDs.<br />
<br />
===Location===<br />
<br />
* '''''Allow/prevent viewing the world map''''' : @showworldmap=<y/n><br />
''Implemented in v1.11''<br />
<br />
When prevented, the avatar is unable to view the world map, and it closes if it is open when the restriction becomes active.<br />
<br />
<br />
* '''''Allow/prevent viewing the mini map''''' : @showminimap=<y/n><br />
''Implemented in v1.11''<br />
<br />
When prevented, the avatar is unable to view the mini map, and it closes if it is open when the restriction becomes active.<br />
<br />
<br />
* '''''Allow/prevent knowing the current location''''' : @showloc=<y/n><br />
''Implemented in v1.12''<br />
<br />
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).<br />
<br />
===Name Tags and Hovertext===<br />
<br />
* '''''Allow/prevent seeing the names of the people around''''' : @shownames=<y/n><br />
''Implemented in v1.12.2, added more dummy names in v1.16''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent seeing all the hovertexts''''' : @showhovertextall=<y/n><br />
''Implemented in v1.19''<br />
<br />
When prevented, the user is unable to read any hovertext (2D text floating above some prims).<br />
<br />
<br />
* '''''Allow/prevent seeing one hovertext in particular''''' : @showhovertext:<UUID>=<y/n><br />
''Implemented in v1.19''<br />
<br />
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).<br />
<br />
<br />
* '''''Allow/prevent seeing the hovertexts on the HUD of the user''''' : @showhovertexthud=<y/n><br />
''Implemented in v1.19''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent seeing the hovertexts in-world''''' : @showhovertextworld=<y/n><br />
''Implemented in v1.19''<br />
<br />
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.<br />
<br />
===Group===<br />
<br />
* '''''Force the agent to change the active group''''' : @setgroup:<group_name>=force<br />
''Implemented in v2.5''<br />
<br />
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.<br />
<br />
<br />
* '''''Allow/prevent activating a group''''' : @setgroup=<y/n><br />
''Implemented in v2.5''<br />
<br />
When prevented, the user is unable to change the active group.<br />
<br />
<br />
* '''''Get the name of the active group''''' : @getgroup=<channel_number><br />
''Implemented in v2.5''<br />
<br />
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.<br />
<br />
<br />
===Viewer Control===<br />
<br />
* '''''Allow/prevent changing some debug settings''''' : @setdebug=<y/n><br />
''Implemented in v1.16''<br />
<br />
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 :<br />
:* AvatarSex (0 : Female, 1 : Male) : gender of the avatar at creation.<br />
:* 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.<br />
<br />
* '''''Force change a debug setting''''' : @setdebug_<setting>:<value>=force (*)<br />
''Implemented in v1.16''<br />
<br />
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.<br />
<br />
See the list of allowed debug settings in the @setdebug command hereabove.<br />
<br />
<br />
* '''''Get the value of a debug setting''''' : @getdebug_<setting>=<channel_number><br />
''Implemented in v1.16''<br />
<br />
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.<br />
<br />
See the list of allowed debug settings in the @setdebug command hereabove.<br />
<br />
<br />
* '''''Allow/prevent changing the environment settings''''' : @setenv=<y/n><br />
''Implemented in v1.14''<br />
<br />
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).<br />
<br />
<br />
* '''''Force change an environment setting''''' : @setenv_<setting>:<value>=force (*)<br />
''Implemented in v1.14''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Each particular sub-command works as follows (the names are chosen to be as close to the Windlight panels of the viewer as possible) :<br />
<br />
{| border="1" cellpadding="5"<br />
| '''@setenv_XXX:<value>=force where XXX is...''' || '''<value> range''' || '''Sets...'''<br />
|-<br />
| 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'''<br />
|-<br />
| 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'''<br />
|-<br />
| ambientr || 0.0-1.0 || Ambient light, Red channel<br />
|-<br />
| ambientg || 0.0-1.0 || Ambient light, Green channel<br />
|-<br />
| ambientb || 0.0-1.0 || Ambient light, Blue channel<br />
|-<br />
| ambienti || 0.0-1.0 || Ambient light, Intensity<br />
|-<br />
| bluedensityr || 0.0-1.0 || Blue Density, Red channel<br />
|-<br />
| bluedensityg || 0.0-1.0 || Blue Density, Green channel<br />
|-<br />
| bluedensityb || 0.0-1.0 || Blue Density, Blue channel<br />
|-<br />
| bluedensityi || 0.0-1.0 || Blue Density, Intensity<br />
|-<br />
| bluehorizonr || 0.0-1.0 || Blue Horizon, Red channel<br />
|-<br />
| bluehorizong || 0.0-1.0 || Blue Horizon, Green channel<br />
|-<br />
| bluehorizonb || 0.0-1.0 || Blue Horizon, Blue channel<br />
|-<br />
| bluehorizoni || 0.0-1.0 || Blue Horizon, Intensity<br />
|-<br />
| cloudcolorr || 0.0-1.0 || Cloud color, Red channel<br />
|-<br />
| cloudcolorg || 0.0-1.0 || Cloud color, Green channel<br />
|-<br />
| cloudcolorb || 0.0-1.0 || Cloud color, Blue channel<br />
|-<br />
| cloudcolori || 0.0-1.0 || Cloud color, Intensity<br />
|-<br />
| cloudcoverage || 0.0-1.0 || Cloud coverage<br />
|-<br />
| cloudx || 0.0-1.0 || Cloud offset X<br />
|-<br />
| cloudy || 0.0-1.0 || Cloud offset Y<br />
|-<br />
| cloudd || 0.0-1.0 || Cloud density<br />
|-<br />
| clouddetailx || 0.0-1.0 || Cloud detail X<br />
|-<br />
| clouddetaily || 0.0-1.0 || Cloud detail Y<br />
|-<br />
| clouddetaild || 0.0-1.0 || Cloud detail density<br />
|-<br />
| cloudscale || 0.0-1.0 || Cloud scale<br />
|-<br />
| cloudscrollx || 0.0-1.0 || Cloud scroll X<br />
|-<br />
| cloudscrolly || 0.0-1.0 || Cloud scroll Y<br />
|-<br />
| densitymultiplier || 0.0-0.9 || Density multiplier of the fog<br />
|-<br />
| distancemultiplier || 0.0-100.0 || Distance multiplier of the fog<br />
|-<br />
| eastangle || 0.0-1.0 || Position of the east, 0.0 is normal<br />
|-<br />
| hazedensity || 0.0-1.0 || Density of the haze<br />
|-<br />
| hazehorizon || 0.0-1.0 || Haze at the horizon<br />
|-<br />
| maxaltitude || 0.0-4000.0 || Maximum altitude of the fog<br />
|-<br />
| scenegamma || 0.0-10.0 || Overall gamma, 1.0 is normal<br />
|-<br />
| starbrightness|| 0.0-2.0 || Brightness of the stars<br />
|-<br />
| sunglowfocus || 0.0-0.5 || Focus of the glow of the sun<br />
|-<br />
| sunglowsize || 1.0-2.0 || Size of the glow of the sun<br />
|-<br />
| sunmooncolorr || 0.0-1.0 || Sun and moon, Red channel<br />
|-<br />
| sunmooncolorg || 0.0-1.0 || Sun and moon, Green channel<br />
|-<br />
| sunmooncolorb || 0.0-1.0 || Sun and moon, Blue channel<br />
|-<br />
| sunmooncolori || 0.0-1.0 || Sun and moon, Intensity<br />
|-<br />
| sunmoonposition || 0.0-1.0 || Position of the sun/moon, different from "daytime", '''use this to set the apparent sunlight after loading a Preset'''<br />
|}<br />
<br />
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.<br />
<br />
* '''''Get the value of an environment setting''''' : @getenv_<setting>=<channel_number><br />
''Implemented in v1.15''<br />
<br />
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 /><br />
Note: only @getenv_daytime is supported by v1.19.0 (or older, i.e. non Windlight) viewers implementing RestrainedLove v1.15 and later.<br />
<br />
===Footnotes===<br />
<br />
(*) Silently discarded if the user is prevented from doing so by the corresponding restriction. This is on purpose.<br />
Ex : Force detach won't work if the object is undetachable. Force undress won't work if the user is prevented from undressing.<br />
<br />
==Important note about the global behaviours such as sendchat==<br />
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. <br />
<br />
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.<br />
<br />
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.<br />
<br />
==Shared Folders==<br />
<br />
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.<br />
<br />
"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".<br />
<br />
To do this :<br />
* 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".<br />
* Move a folder containing restraints or other attachments directly into this new folder.<br />
* Wear the contents of that folder, that's it !<br />
<br />
So it would look like this :<br />
<br />
My Inventory<br />
|- #RLV<br />
| |- cuffs<br />
| | |- left cuff (l forearm) (no copy)<br />
| | \- right cuff (r forearm) (no copy)<br />
| \- gag<br />
| \- gag (mouth) (no copy)<br />
|- Animations<br />
|- Body Parts<br />
.<br />
.<br />
.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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...).<br />
<br />
HOW TO SHARE NO-MODIFY ITEMS :<br />
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.<br />
<br />
Example with no-modify shoes :<br />
<br />
My Inventory<br />
|- #RLV<br />
| \- shoes<br />
| |- left shoe (left foot)<br />
| | \- left shoe (no modify) (no transfer) <-- no-mod object<br />
| |- right shoe (right foot)<br />
| | \- right shoe (no modify) (no transfer) <-- no-mod object<br />
| \- shoe base (no modify) (no transfer) <-- this is not an object<br />
|- Animations<br />
|- Body Parts<br />
.<br />
.<br />
.<br />
<br />
GOTCHAS :<br />
* Do NOT put a comma (',') in the name of the folders under the shared root or it would screw the list up.<br />
* 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.<br />
* 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.<br />
* 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).<br />
<br />
<br />
'''''Accept sub-folders given via llGiveInventoryList() into the shared folder''''' :<br />
<br />
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).<br />
<br />
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).<br />
<br />
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).<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
==For your information==<br />
Here is how it works internally, for a better understanding of the gotchas you may encounter :<br />
* 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).<br />
<br />
* 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.<br />
<br />
* 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).<br />
<br />
* 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.<br />
<br />
* 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.<br />
If '''''UUID1''''' is a collar and '''''UUID2''''' is a gag :<br />
<br />
'''''UUID1''''' => detach, tploc, tplm, tplure, sittp<br />
<br />
'''''UUID2''''' => detach, sendim, sendim:(keyholder)<br />
<br />
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 :<br />
<br />
'''''UUID1''''' => detach, tploc, tplm, tplure, sittp, sendim<br />
<br />
'''''UUID2''''' => detach, sendim, sendim:(keyholder)<br />
<br />
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.<br />
<br />
* One-shot commands, on the other hand, are executed on-the-fly and are not stored.<br />
<br />
* 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).<br />
<br />
* 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.<br />
<br />
[[Category:Third Party Client]]<br />
[[Category:RestrainedLove]]</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=No_sensor&diff=1172677No sensor2012-09-15T14:42:54Z<p>Tonya Souther: fix variable name mismatch in code snippet</p>
<hr />
<div>{{Issues/SVC-2409}}{{LSL_Event<br />
|event_id=14<br />
|event_delay<br />
|event=no_sensor<br />
|event_desc=Result of a call to [[llSensor]] or [[llSensorRepeat]].<br />
|constants<br />
|spec<br />
|caveats=<br />
*sensor/no_sensor are not always the best solution:<br />
**To determine if something is in/out of range is overkill. For this situation use: [[llGetObjectDetails]] as you will see in the [[#Useful Snippets|Useful&nbsp;Snippets]] section.<br />
**To determine if an avatar is in the region, try [[llGetAgentSize]]<br />
|examples=<br />
<lsl>//List all avatars in range.<br />
default {<br />
on_rez(integer i) {<br />
llSensor("", "", AGENT, 100000, 10000);<br />
}<br />
sensor(integer num) {<br />
integer i = 0;<br />
do {<br />
llOwnerSay(llDetectedName(i) + " is " + (string)llVecDist(llGetPos(), llDetectedPos(i)) + "m away.");<br />
}while(++i < num);<br />
}<br />
no_sensor() {<br />
llOwnerSay("No avatars in range.");<br />
}<br />
}</lsl><br />
<br />
|helpers=<br />
<lsl>//An alternative solution for find out if a user is not in range<br />
//No sensor is used so the above caveat doesn't apply.<br />
<br />
integer InRange(key uuid, float distance)<br />
{<br />
list data = llGetObjectDetails(uuid, [OBJECT_POS]);<br />
if(data == [])<br />
return 0;<br />
return llVecDist(llList2Vector(data, 0), llGetPos()) <= distance;<br />
}</lsl><br />
|also_header<br />
|also_events<br />
|also_functions={{LSL DefineRow||[[llSensor]]}}<br />
{{LSL DefineRow||[[llSensorRepeat]]}}<br />
|also_articles<br />
|also_footer<br />
|notes<br />
|mode<br />
|bugs={{LSL Bug|SVC-2409|llSensorRepeat not triggering no_sensor unless a sensor event handler is present}}<br />
|deprecated<br />
|cat1=Sensor<br />
|cat2<br />
|cat3<br />
|cat4<br />
}}</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=TPVD/Developers_Group_Agenda&diff=1170571TPVD/Developers Group Agenda2012-07-13T18:00:09Z<p>Tonya Souther: /* New: */ added code signing</p>
<hr />
<div> '''Add agenda requests at the end, and please put your SL Name in the request so Oz's know who to contact for any clarification'''<br />
'''Use <nowiki>--~~~~</nowiki> to insert your signature'''<br />
Next meeting: '''Noon SLT, July 13'''<br />
<br />
====New:====<br />
<br />
# Pathfinding<br />
#* What you will need to do<br />
#* The llphysicsextensions stub, and the corresponding licensed library -- [[User:Oz Linden|Oz Linden]]<br />
# Compatibility with [http://community.secondlife.com/t5/Tools-and-Technology/Project-Shining-to-Improve-Avatar-and-Object-Streaming-Speeds/ba-p/1583465 Project Shining] improvements -- [[User:Oz Linden|Oz Linden]]<br />
#* New HTTP library -- Monty<br />
#* Avatar Baking -- Oz<br />
# New community driven user group for content creation improvements --[[User:Geenz Spad|Geenz Spad]]<br />
# Build process code signing for Mountain Lion -- [[User:Tonya Souther|Tonya Souther]]<br />
<br />
<!-- Add your item above this comment, and be sure to attach your name or signature using --~~~ --><br />
<br />
====Open Items:====<br />
<br />
# In-world Viewer Test resources ([[User:Alexa Linden|Alexa Linden]])<br />
# People API (we can still hope)<br />
<br />
[[Category:Third Party Viewers]]</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=TPVD/Developers_Group_Agenda&diff=1156191TPVD/Developers Group Agenda2011-10-28T17:08:33Z<p>Tonya Souther: /* New: */</p>
<hr />
<div> '''Add agenda requests at the end, and please put your SL Name in the request so Oz's know who to contact for any clarification'''<br />
'''Use <nowiki>--~~~~</nowiki> to insert your signature'''<br />
Next meeting: '''Oct 28'''<br />
<br />
====New:====<br />
<br />
# UI Merge surprises<br />
##...and secret development as it affects LL's relationship with TPVDs... -- [[User:Tonya Souther|Tonya Souther]] 10:08, 28 October 2011 (PDT)<br />
# Marketplace API<br />
# Two Inventory messages are moving from UDP to HTTP EventQueue: BulkUpdateInventory and RemoveInventoryObjects -- Stone Linden<br />
<br />
<!-- Add your item above this comment, and be sure to attach your name or signature using --~~~~ --><br />
<br />
====Open Items:====<br />
<br />
# Login Screen Widgets - ready for testing<br />
# '''Profile/People API'''<br />
# OpenGL rendering fixes, news? [[User:TankMaster Finesmith|TankMaster Finesmith]] 08:21, 16 September 2011 (PDT)<br />
# Any updates on communications reliability issues:<br />
#*{{JiraIssue|VWR-25940|HTTP communication with grid capabilities router is unreliable at times affecting HTTP Textures}}<br />
#*{{JiraIssue|SVC-6917|Apache2-worker/caps router on sim hosts is relaying 499 HTTP status codes back to clients - not a valid wire status code}}<br />
#*{{JiraIssue|SVC-6760|Apache2-worker/caps router on sim hosts is experiencing a high failure rate leading to service interruptions}}<br />
#*{{JiraIssue|VWR-25145|asset/texture download scenarios that work badly}}<br />
#*{{JiraIssue|VWR-26218|Windows viewer is experiencing DNS issues while attempting to fetch textures}}<br />
#: and the 499/caps failures? Can someone find out why do a few users see these issues so much? --[[User:Kadah Coba|Kadah Coba]] 12:38, 31 May 2011 (PDT)<br />
#* Seeking feedback on good/bad experiences and networking hardware here:<br />
#** {{JiraIssue|VWR-25426|Friendlist displays users as Unknown or (loading), teleports fail, assets will not save}}<br />
<br />
<br />
[[Category:Third Party Viewers]]</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=TPVD/Developers_Group_Agenda&diff=1145137TPVD/Developers Group Agenda2011-06-02T15:16:58Z<p>Tonya Souther: </p>
<hr />
<div><!-- Add agenda requests at the end, and please put your SL Name in the request (use --~~~~ to insert your signature) so I know who to contact for any clarification --><br />
<br />
Current and Open Items:<br />
# V1->V2 adoption issue, V2's vivox implementation appears unreliable in Push-To-Talk mode (V1 default and behavior many users wish to keep) due to faulty speech detection delaying when the microphone opens. See http://jira.phoenixviewer.com/browse/FIRE-1154. Looking for possible advice on how to address this. Is it something embedded in the vivox binary, or is the behavior tunable in some way within the viewer source? Looking for a vivox point of contact at LL. [[User:Arrehn Oberlander|Arrehn Oberlander]] <br />
# The Future of Search<br />
# Getting really tired of LL support and developers blaming third party viewers for things like asset failures, delivery failures and dozens of other things that have nothing to do with TPV's. Eg. VWR-25840, STORM-703, VWR-25276 (inventory items outside of inventory folder) As well as blames by LL support that Phoenix is responsible for displaying region prim counts incorrectly and dozens more like this. Also a quote from one of LL's support "SydahneP: It's very possible.. We have linked most of the server issues from the latest update with the Phoenix viewer. " -- [[User:Jessica Lyon|Jessica Lyon]]<br />
## And if a problem '''is''' related to a TPV, then come talk to us, don't just complain about TPVs. -- [[User:Tonya Souther|Tonya Souther]] 08:16, 2 June 2011 (PDT)<br />
# Minimap coarse location messages, any possibility on getting that updated to support avatars over 1000m --[[User:Kadah Coba|Kadah Coba]] 13:13, 21 May 2011 (PDT)<br />
# Drop date for Region WL yet? :3 --[[User:Kadah Coba|Kadah Coba]] 17:32, 31 May 2011 (PDT)<br />
# Any updates on SVC-6917, SVC-6760, VWR-25940, and the 499/caps failures? Can someone find out why do a few users see these issues so much? --[[User:Kadah Coba|Kadah Coba]] 12:38, 31 May 2011 (PDT)<br />
[12:28] Kadah (kadah.coba): Joshua, any updates on those 499s and caps failures?<br />
[12:28] Josh (joshua.linden): no update<br />
[12:29] Josh (joshua.linden): still in progress, still high priority<br />
[12:30] Josh (joshua.linden): re: caps - It's entirely on our servers; it affects hosts, and is intermittent even when a host has "gone bad".<br />
That's all I can really say. It's not your viewer or ISP<br />
<br />
<br />
Previous agenda:<br />
# Direct Delivery - new delivery mechanism; Brooke Linden, Marketplace<br />
# Any updates on getting detailed stats? --[[User:Kadah Coba|Kadah Coba]] <br />
# Looking for documentation of crashlog / minidump processing, such as example server code, build tool integration, documentation of process, etc. --([[User:Arrehn Oberlander|Arrehn Oberlander]])<br />
<br />
[[Category:Third Party Viewers]]</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=TPVD/Developers_Group_Agenda&diff=1145136TPVD/Developers Group Agenda2011-06-02T15:15:49Z<p>Tonya Souther: </p>
<hr />
<div><!-- Add agenda requests at the end, and please put your SL Name in the request (use --~~~~ to insert your signature) so I know who to contact for any clarification --><br />
<br />
Current and Open Items:<br />
# V1->V2 adoption issue, V2's vivox implementation appears unreliable in Push-To-Talk mode (V1 default and behavior many users wish to keep) due to faulty speech detection delaying when the microphone opens. See http://jira.phoenixviewer.com/browse/FIRE-1154. Looking for possible advice on how to address this. Is it something embedded in the vivox binary, or is the behavior tunable in some way within the viewer source? Looking for a vivox point of contact at LL. [[User:Arrehn Oberlander|Arrehn Oberlander]] <br />
# The Future of Search<br />
# Getting really tired of LL support and developers blaming third party viewers for things like asset failures, delivery failures and dozens of other things that have nothing to do with TPV's. Eg. VWR-25840, STORM-703, VWR-25276 (inventory items outside of inventory folder) As well as blames by LL support that Phoenix is responsible for displaying region prim counts incorrectly and dozens more like this. Also a quote from one of LL's support "SydahneP: It's very possible.. We have linked most of the server issues from the latest update with the Phoenix viewer. " -- [[User:Jessica Lyon|Jessica Lyon]]<br />
# Minimap coarse location messages, any possibility on getting that updated to support avatars over 1000m --[[User:Kadah Coba|Kadah Coba]] 13:13, 21 May 2011 (PDT)<br />
# Drop date for Region WL yet? :3 --[[User:Kadah Coba|Kadah Coba]] 17:32, 31 May 2011 (PDT)<br />
# Any updates on SVC-6917, SVC-6760, VWR-25940, and the 499/caps failures? Can someone find out why do a few users see these issues so much? --[[User:Kadah Coba|Kadah Coba]] 12:38, 31 May 2011 (PDT)<br />
[12:28] Kadah (kadah.coba): Joshua, any updates on those 499s and caps failures?<br />
[12:28] Josh (joshua.linden): no update<br />
[12:29] Josh (joshua.linden): still in progress, still high priority<br />
[12:30] Josh (joshua.linden): re: caps - It's entirely on our servers; it affects hosts, and is intermittent even when a host has "gone bad".<br />
That's all I can really say. It's not your viewer or ISP<br />
<br />
<br />
Previous agenda:<br />
# Direct Delivery - new delivery mechanism; Brooke Linden, Marketplace<br />
# Any updates on getting detailed stats? --[[User:Kadah Coba|Kadah Coba]] <br />
# Looking for documentation of crashlog / minidump processing, such as example server code, build tool integration, documentation of process, etc. --([[User:Arrehn Oberlander|Arrehn Oberlander]])<br />
<br />
[[Category:Third Party Viewers]]</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=TPVD/Developers_Group_Agenda&diff=1145135TPVD/Developers Group Agenda2011-06-02T15:14:17Z<p>Tonya Souther: </p>
<hr />
<div><!-- Add agenda requests at the end, and please put your SL Name in the request (use --~~~~ to insert your signature) so I know who to contact for any clarification --><br />
<br />
Current and Open Items:<br />
# V1->V2 adoption issue, V2's vivox implementation appears unreliable in Push-To-Talk mode (V1 default and behavior many users wish to keep) due to faulty speech detection delaying when the microphone opens. See http://jira.phoenixviewer.com/browse/FIRE-1154. Looking for possible advice on how to address this. Is it something embedded in the vivox binary, or is the behavior tunable in some way within the viewer source? Looking for a vivox point of contact at LL. [[User:Arrehn Oberlander|Arrehn Oberlander]] <br />
# The Future of Search<br />
# Getting really tired of LL support and developers blaming third party viewers for things like asset failures, delivery failures and dozens of other things that have nothing to do with TPV's. Eg. VWR-25840, STORM-703, VWR-25276 (inventory items outside of inventory folder) As well as blames by LL support that Phoenix is responsible for displaying region prim counts incorrectly and dozens more like this. Also a quote from one of LL's support "SydahneP: It's very possible.. We have linked most of the server issues from the latest update with the Phoenix viewer. " -- [[User:Jessica Lyon|Jessica Lyon]]<br />
# Minimap coarse location messages, any possibility on getting that updated to support avatars over 1000m --[[User:Kadah Coba|Kadah Coba]] 13:13, 21 May 2011 (PDT)<br />
# Drop date for Region WL yet? :3 --[[User:Kadah Coba|Kadah Coba]] 17:32, 31 May 2011 (PDT)<br />
# Any updates on SVC-6917 & SVC-6760 & the 499/caps failures? Can someone find out why do a few users see these issues so much? --[[User:Kadah Coba|Kadah Coba]] 12:38, 31 May 2011 (PDT)<br />
[12:28] Kadah (kadah.coba): Joshua, any updates on those 499s and caps failures?<br />
[12:28] Josh (joshua.linden): no update<br />
[12:29] Josh (joshua.linden): still in progress, still high priority<br />
[12:30] Josh (joshua.linden): re: caps - It's entirely on our servers; it affects hosts, and is intermittent even when a host has "gone bad".<br />
That's all I can really say. It's not your viewer or ISP<br />
<br />
<br />
Previous agenda:<br />
# Direct Delivery - new delivery mechanism; Brooke Linden, Marketplace<br />
# Any updates on getting detailed stats? --[[User:Kadah Coba|Kadah Coba]] <br />
# Looking for documentation of crashlog / minidump processing, such as example server code, build tool integration, documentation of process, etc. --([[User:Arrehn Oberlander|Arrehn Oberlander]])<br />
<br />
[[Category:Third Party Viewers]]</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=User:Tonya_Souther&diff=1142755User:Tonya Souther2011-05-06T19:16:54Z<p>Tonya Souther: </p>
<hr />
<div>Mac OS X developer lead for [[Third_Party_Viewer_Directory/Phoenix]] and [[Third_Party_Viewer_Directory/Firestorm]].</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=User:Tonya_Souther&diff=1142754User:Tonya Souther2011-05-06T19:16:00Z<p>Tonya Souther: Created page with "Mc OS X developer lead for Third_Party_Viewer_Directory/Phoenix and Third_Party_Viewer_Directory/Firestorm."</p>
<hr />
<div>Mc OS X developer lead for [[Third_Party_Viewer_Directory/Phoenix]] and [[Third_Party_Viewer_Directory/Firestorm]].</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=TPVD/Developers_Group_Agenda&diff=1142753TPVD/Developers Group Agenda2011-05-06T19:08:03Z<p>Tonya Souther: </p>
<hr />
<div><!-- Add agenda requests at the end, and please put your SL Name in the request (use --~~~~ to insert your signature) so I know who to contact for any clarification --><br />
<br />
Current and Open Items:<br />
# Any updates on SVC-6760, [[https://jira.secondlife.com/browse/SVC-6917 SVC-6917]] and [[https://jira.secondlife.com/browse/VWR-25426 VWR-25426]] I can't do anything on viewer 2 still :( --[[User:Kadah Coba|Kadah Coba]] 17:33, 5 May 2011 (PDT)<br />
# Any updates on getting detailed stats? --[[User:Kadah Coba|Kadah Coba]] 14:44, 3 May 2011 (PDT)<br />
# Looking for documentation of crashlog / minidump processing, such as example server code, build tool integration, documentation of process, etc. --([[User:Arrehn Oberlander|Arrehn Oberlander]])<br />
# [[https://jira.secondlife.com/browse/VWR-25479 VWR-25479]] (Avatar physics causing rendering incompatibilities with V1 clients) is marked as awaiting review. Any new news on this item, besides Oz's patch? --([[User:Arrehn Oberlander|Arrehn Oberlander]]) ...and [[https://jira.secondlife.com/browse/SVC-6943 SVC-6943]], too. -- [[User:Tonya Souther|Tonya Souther]] 12:08, 6 May 2011 (PDT)<br />
# Open Question: We've been getting reports of increased circuit drops/timeouts, and I've noticed a few myself, particularly after teleports. How would these show up on the crash statistics? What tools do we have to measure their severity and impact? --([[User:Arrehn Oberlander|Arrehn Oberlander]])<br />
<br />
<br />
<br />
Previous agenda:<br />
# provide a list of package files in http://s3.amazonaws.com/viewer-source-downloads/install_pkgs and other related download locations so we may be able to updat the packages we use with the viewer more easily<br />
# [[Third_Party_Viewer_Directory]] order seems to be inconsistent some weeks. Are you determining "highest version number" from alphabetic order of the viewers' channels? [[User:Kadah Coba|Kadah Coba]] 19:39, 11 April 2011 (PDT)<br />
# Info on XMPP, from Oskar's simulator UG he mentioned XMPP is dead (or will be soon)... so want more info/clarification<br />
## I think he said that XMPP was found to be unable to scale to all the edge cases, but didn't have any details. What's next, IRC? IRC would be nice. Can we have IRC? --[[User:Kadah Coba|Kadah Coba]] 11:20, 22 April 2011 (PDT)<br />
# Digital signing: Viewer2 only has the installer signed for widows (at least on the release that I checked, 2.6.1.225680), does LL get many reports of issues with anti virus ware that might be caused by this? We're signing both the installer and the viewer executable. Would there be a reason for me not to sign the slplugin and slvoice as well? --[[User:Kadah Coba|Kadah Coba]] 11:20, 22 April 2011 (PDT)<br />
# Detailed stats with hardware info, status on getting them? --[[User:Kadah Coba|Kadah Coba]] 11:20, 22 April 2011 (PDT)<br />
# [[https://jira.secondlife.com/browse/VWR-25426 VWR-25426]] seems to be occurring more frequently in the busy sims. I have no updates, just want Oz to be aware of the issue as well. --[[User:Kadah Coba|Kadah Coba]] 11:20, 22 April 2011 (PDT)<br />
# (If Monty is in attendance, this is more towards him) On some region crossing, attachments are observed in the console being detached then getting reattached especially with HUDs which would seemed to cause a crash on Phoenix if the HUD had hovertext. Some prims from some attachments will disappear on these crossing, usually happens to my hair as its has a lot of prims and the effect is quite obvious on it. Sorry, don't have logs of this handy atm, but will start collect them plus region info and file an appropriate jira. --[[User:Kadah Coba|Kadah Coba]] 11:20, 22 April 2011 (PDT)</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=Downloads&diff=1057943Downloads2010-10-10T19:33:49Z<p>Tonya Souther: /* Phoenix Viewer */ Updates for server rework and version update; grammar and spelling fixes</p>
<hr />
<div>{{Help|Viewer=*}}{{RightToc}}<br />
<br />
{{KBcaution|This page is not maintained by, or endorsed by, Linden Lab.<br />
*To download the latest official Second Life Viewer releases, please visit the '''[http://secondlife.com/support/downloads/ main download page]'''.<br />
*For a list of third-party viewers that have self-certified compliance with the '''[http://secondlife.com/corporate/tpv.php Policy on Third-Party Viewers]''', please visit the '''[http://viewerdirectory.secondlife.com Viewer Directory]'''.}}<br />
<br />
<br />
== Linden Lab Viewers ==<br />
<br />
The following viewers are available on the official '''[http://secondlife.com/support/downloads/ Downloads]''' page:<br />
<br />
* '''Second Life Viewer''' (a.k.a. the official Viewer, regular Viewer etc.)<br />
* '''[[Release Candidate|Release Candidate Viewer]]'''<br />
** Not always available<br />
** As the name says, these are candidates to become the next release (of the Second Life Viewer)<br />
* '''[[First Look|First Look Viewer]]'''<br />
** Not always available<br />
** "Provide a 'first look' at new features under development" before those are ready to get into a Release Candidate or even a release<br />
* '''Beta Grid Viewer'''<br />
** Only available when a new feature that is being tested on the beta grid requires a new viewer<br />
** Usually, you can use any viewer you like to connect to Aditi, the [[Preview Grid]]<br />
* '''[[Snowglobe|Snowglobe Viewer]]'''<br />
** Linden Lab's own "fork" of the Second Life Viewer<br />
** Quicker inclusion of third party contributions than in the Second Life Viewer<br />
** Review of contributions and QA done by the open source community (some Residents have commit access)<br />
<br />
== Third-party Viewers ==<br />
{{KBcaution|As previously [http://bit.ly/3pvpolicy announced], Linden Lab [https://blogs.secondlife.com/community/community/blog/2010/02/23/introducing-a-new-third-party-viewer-directory-and-policy introduced] the '''[http://secondlife.com/corporate/tpv.php Third Party Viewer Policy]'''. That policy is part of the [http://secondlife.com/corporate/tos.php Terms of Service] updated on '''April 30, 2010'''}}<br />
<br />
Third-party Viewers are those which have been created by developers not working for Linden Lab. These Viewers offer altered or additional functionality compared to the official Second Life Viewer.<br />
<br />
The [[Extended_FAQ|Extended FAQ]] states that it is okay to create and distribute third-party viewers as long they adhere to the respective licenses for code usage and server usage. <br />
<br />
The code itself is licensed under {{OSWebsite|gplv2|alt=the GNU General Public License (GPL)}}, which governs modification and redistribuition of the source code. Use of Linden Lab's servers will still be governed by [http://secondlife.com/corporate/tos.php the Second Life Terms of Service] and [http://secondlife.com/corporate/tpv.php the Linden Lab Policy on Third-Party Viewers]. The latter is being revised, so please consult the [[Linden_Lab_Official:Third_Party_Policy_and_Viewer_Directory_FAQ|FAQ]] until a more final version is available.<br />
<br />
''Note to authors: If you make a viewer available make sure to include platform, version numbers and dates.''<br />
{{Anchor|Viewers}}<br />
{|class="wikitable sortable collapsible" {{prettytable}}<br />
|+ ''click the boxed arrows to sort on columns''<br />
|- {{KBtablehead}}<br />
! Name !! {{HoverText|Type|Graphic/Text}} !! {{HoverText|First release|Specified in YYYY-MM-DD}} !! {{HoverText|Latest Release|Specified in YYYY-MM-DD}} !! {{HoverText|Status|Active/Inactive/Discontinued}} !! {{HoverText|W|For Windows}} <ref name="available">"X": Available with binary distribution</ref>!! {{HoverText|M|For Macintosh}} <ref name="available"/> !! {{HoverText|L|For Linux(Ubuntu, Debian or so)}} <ref name="available"/> !! {{HoverText|i|For iPhone/iPod Touch}} <ref name="available"/><br />
|-<br />
| [[#AjaxLife]] || Text || || 2008-09-15 || Active ||X||X||X||X<br />
|-<br />
| [[#Cool VL Viewer]] || Graphic || 2007-11-16 || 2010-10-02 || Active ||X||X||X||<br />
|-<br />
| [[#Combat Cubed]] || Graphic || || 2010-06-16 || Active ||X|| || ||<br />
|-<br />
| [[#Emerald Viewer]] || Graphic || || 2010-04-19 || Blocked ||X||X||X||<br />
|-<br />
| [[#Emerald Viewer, Frequency Edition]] || Graphic || || 2009-09-25 || Discontinued || ||X|| ||<br />
|-<br />
| [[#Hippo OpenSim Viewer]] || Graphic || || 2010-04-24 || Active ||X|| ||X||<br />
|-<br />
| [[#Imprudence]] || Graphic || || 2010-08-28 || Active ||X||X||X||<br />
|-<br />
| [[#Kirstens Viewer]] || Graphic || || 2010-08-30 || Active ||X||X||X||<br />
|-<br />
| [[#METAbolt]] || Text || 2008-04-15 || 2010-09-26 || Active ||X|| || ||<br />
|-<br />
| [[#Meerkat]] || Graphic || || 2009-09-06 || Discontinued ||X|| ||X||<br />
|-<br />
| [[#MetaPay for iPhone and iPod Touch]] || Text || || || || || || ||X<br />
|-<br />
| [[#Milk Release Client]] || Graphic || || 2010-01-20 || Inactive || ||X||X||<br />
|-<br />
| [[#Nicholaz Edition]] || Graphic || || 2009-09-07 || Discontinued ||X||X||X||<br />
|-<br />
| [[#omvviewer]] || Graphic || || 2009-03-27 || Active || || ||X||<br />
|-<br />
| [[#omvviewer-light]] || Text || || 2009-08-25 || Active ||X|| ||X||<br />
|-<br />
| [[#Onrez Viewer]] || Graphic || || || Discontinued || || || ||<br />
|-<br />
| [[#Phoenix Viewer]] || Graphic ||2010-09-04 || || Active ||X||X||X||<br />
|-<br />
| [[#Radegast]] || Text || || 2010-07-28 || Active ||X|| ||X||<br />
|-<br />
| [[#Rainbow Viewer / Cool Viewer]] || Graphic || || 2010-04-24 || Discontinued ||X||X||X||<br />
|-<br />
| [[#RealXtend Edition]] || Graphic || || 2008-07-28 || Active ||X|| || ||<br />
|-<br />
| [[#Restrained Love]] || Graphic || || 2010-09-05 || Active ||X||X||X||<br />
|-<br />
| [[#SLeek]] || Text || || || Discontinued || || || ||<br />
|-<br />
| [[#SLiteChat]] || Text || || || Active ||X||X||X||<br />
|-<br />
| [[#Snowglobe, Frequency Edition]] || Graphic || || 2009-10-17 || Discontinued ||X||X||X||<br />
|-<br />
| [[#Sparkle IM for iPhone and iPod Touch]] || Text || || || || || || ||X<br />
|-<br />
| [[#TEKSTUFF Viewers]] || Graphic || || 2010-04-20 || Active ||X|| || ||<br />
|-<br />
| [[#Touch Life for iPhone]] || Text || || || || || || ||X<br />
|-<br />
| [[#Toxic Viewer]] || Graphic || || 2010-03-04 || Discontinued ||X|| || ||<br />
|-<br />
| [[#Whisper (SlXSLChat)]] || Text || || 2010-05-09 || Active ||X||X||X||<br />
|-<br />
|}<br />
<br />
<references /><br />
<br />
== Graphical Viewers ==<br />
<br />
=== Cool VL Viewer ===<br />
<br />
''' Description '''<br />
<br />
This viewer was created and is maintained by {{User|Henri Beauchamp}} (This viewer was formerly known as the "Cool SL Viewer" and its first public release was v1.18.4.3, released on 2007-11-16). It combines elements of several of the other viewers, as well as extra features, bug fixes and extra patches, all very carefully tested.<br />
<br />
It puts emphasis on high UI coherency from one version to the other (meaning no bad surprise for "old timers") while staying in sync with Linden Lab's official viewer features (it's not a fork which would get outdated with time), high stability and reliability, and a high reactivity to new patches and bug fixes provided by the Open Source community.<br />
<br />
An "old" v1.19 (legacy renderer) branch is also maintained for the benefit of "old" computer users, which also gets most of the essential features of newer viewers back-ported to it (Mono scripting and adult compliance, for example).<br />
An experimental branch (Cool VL Viewer v1.25), based on the code of Snowglobe v1.5 is also available.<br />
<br />
The Cool VL Viewer is TPV policy compliant. Please see [http://sldev.free.fr/CoolVLViewerReadme.html its TPV TOS].<br />
<br />
''' Extra Features '''<br />
<br />
* Reverses many of the unpopular interface changes, restoring separate friends and groups floaters and reinstating the packet loss and bandwidth indicators, the old toolbar and buttons layouts, the old/normal commands layout in the pie menus, the "All(old)" search tab, the old style (name-sortable) "Groups" search tab, the "Fly" button in the movement controls floater, and '''optionally''' reinstating the old, more visible, status bar icons and/or tracking dots in the mini-map, and the old chat history floater (without chat input line). Also fixes some UI regressions (missing buttons in some floaters, or visited landmarks tracking in inventory for example).<br />
* Implements the "RestrainedLove" API (formerly known as "RestrainedLife"), based on Marine Kelley's reference patch (switchable and disabled by default).<br />
* Allows to configure the date and time formats to match your locale or personal preferences (including with optional seconds for chat and IM timestamps).<br />
* Allows to wear/remove attachments and clothing items on double-click in inventory.<br />
* Allows to optionally prevent notifications to show and be logged in the main chat. <br />
* Allows to disable typing sounds.<br />
* MUD/MUSH/MUCK/MUX style "poses" (i.e. you can type ":" instead of "/me " to emote), and OOC double parenthesis auto-close (i.e. you can type: "((phone, BRB" and it will show as "((phone, BRB))").<br />
* Allows to hide the "Master volume" when not needed in the panel overlay (and the "Release Keys" button for v1.19.2).<br />
* Allows to build large prims (up to 256m in any or all dimensions) on OpenSim (not on SL, because of server-side limitations).<br />
* Improved friends list floater (with info about what your friends allow you to see: tehri online status and/or their position on the map).<br />
* Improved build tools floater (smaller increments in several parameters, extra "slice" parameter for some prims, transparency up to 100%, check box toggle for drag distance limit, adjustable number of decimals in Object tab for the position/size/rotation parameters). Also allows to set the "invisible" texture from the texture picker (for invisi-prims).<br />
* Improved texture preview floater (with aspect ratio combo).<br />
* Improved notecard floater (with Edit menu and Search/replace feature).<br />
* Improved mini-map with panning, larger zooming range, specific symbol for avatars above 1024m (work around for a limitation of current server and viewer versions), etc...<br />
* Improved beacons: can filter beacons based on owner (you, others or anyone), can highlight attachments, can dissociate non-object sound sources, can keep beacons "always on" even when the beacons floater is closed.<br />
* Allows to export and import objects you own and created as XML files (for backup and restore purpose, or to transfer objects from one grid to another).<br />
* Allows to connect to all existing grids (and not only LL's) from the login screen.<br />
* Allows network bandwidth over 1500Kbps (and up to 8000Kbps).<br />
* Allows to save/compile scripts present in the inventory as Mono scripts.<br />
* Allows to teleport to double-clicked locations on screen.<br />
* Allows to sit anywhere "on the ground".<br />
* Allows to adjust the Z offset (height above the floor) for playing animations (v1.23 and v1.25 branches only).<br />
* Allows to cache the inventory in the background after login (for faster inventory operations).<br />
* Allows to preview animations on your avatar prior to uploading them.<br />
* Implements a group titles floater.<br />
* Implements a radar floater.<br />
* Implements a teleports history floater.<br />
* Implements a "Worn" tab in the inventory floater, and a search/filter by item name, description or creator.<br />
* Implements "speed rezzing" on login and TPs.<br />
* Implements an object "area search" floater.<br />
* Implements the newest LSL functions, highlighting them properly (with tooltips) in the script editor and allowing to compile them.<br />
* Allows to ignore (and not only decline) friendship and calling card offers.<br />
* Allows to change how minimized floaters are stacked (top/bottom, bottom/top, left/right, right/left, fraction of the screen width to use for the stack).<br />
* Shows avatar keys in profile (in "My notes" tab).<br />
* Shows the avatar true height in the appearance floater.<br />
* Renders properly objects worn on the illegal attachment points defined in some hacked third parties viewers.<br />
* '''Provides full support for the new Alpha and Tattoo wearables !''' (full implementation for v1.23 and v1.25 branches. The partial Alphas do not render properly in the v1.19 branch: ok for full body parts Alphas).<br />
* '''NEW: Provides inventory item links support !''' (v1.23 and v1.25 branches only).<br />
* '''NEW: Provides multiple attachments per point support !''' (v1.23 and v1.25 branches only).<br />
* Implements various backports for the v1.19.2 version (Mono compilation support, adult searches and compliance, build and TP up to 4096m, bulk set permissions, TP on double-click on LM in inventory, edit terrain "force" setting, security fixes, etc).<br />
* Many bugfixes by Henri Beauchamp, Nicholaz Beresford, Gigs Taggart, Blakar Ogre, McCabe Maxsted and others.<br />
* More minor features and improvements, to be discovered on the [http://sldev.free.fr/ website]...<br />
* All switchable extra features easily configurable via a "Cool features" tab in the preferences floater.<br />
<br />
''' Links '''<br />
* Website: [http://sldev.free.fr/ The Cool VL Viewer homepage]<br />
* Message board: [http://sldev.free.fr/forum/ Cool VL Viewer forum]<br />
* Linux viewer: see the [http://sldev.free.fr/ The Cool VL Viewer homepage] for files and installation instructions.<br />
* Windows viewer: see the [http://sldev.free.fr/ The Cool VL Viewer homepage] for files and installation instructions.<br />
* MacOS X viewer: [http://hyangreflections.blogspot.com/ See Hyang Zhao's site] for files and instructions.<br />
* Source code: The standard Linden codebase is used, with the addition of the patches listed and linked to on the homepage.<br />
* Screen shots: [http://sldev.free.fr/index.php?page=features Key features and screen shots]<br />
<br />
''' Version and timestamp '''<br />
<br />
* Version : 1.23.5.31 (stable viewer with Windlight renderer)<br />
* Date : 2010/10/02<br />
* Status : Active.<br />
<br />
* Version : 1.19.2.90 (stable viewer with legacy renderer)<br />
* Date : 2010/08/22<br />
* Status : Active (bug and security fixes only, no new feature developed).<br />
<br />
* Version : 1.25.0.8 (experimental viewer based on Snowglobe v1.5.0)<br />
* Date : 2010/10/02<br />
* Status : Active.<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Emerald Viewer ===<br />
Previously known as "Greenlife Emerald Viewer" - changed to just "Emerald" in October 2009.<br />
<br />
''' Description '''<br />
<br />
This is a home-brew viewer which adds new functionality to the viewer with the intent of easing the user's interaction with the environment. It's developed by multiple people. Versions for Windows, Mac, and Linux are released.<br />
<br />
While Emerald has been listed in Linden Lab's Third Party Viewer Directory, it has recently been removed due to controversy over the actions of certain involved developers. As of September 8, 2010, Emerald Viewer has been blocked from logging into Second Life.<br />
<br />
''' Extra Features '''<br />
<br />
* Avatar Scanner<br />
** Full sim range (detects over 1M in the air)<br />
** Shows name, age, payment info, current activity. <br />
** Land and estate commands for ejecting/banning multiple avatars at once<br />
** Buttons to open profile, IM, teleport to or track selected avatars<br />
** Ability to chat radar info (keys) to boost lsl radars<br />
** Ability to display chat notifications for entering sim, exiting sim, entering chat range, exiting chat range, entering draw distance and exiting draw distance respectively.<br />
* RLV API Implementation (off by default)<br />
* Different login page<br />
* Ability to open and display the owner and location of objects that IM you<br />
* Teleport to positions by double clicking<br />
* Option to disable progress screens (teleport, login, and logout respectively)<br />
* Clothing layer protection (prevents sending of individual clothing textures to other clients, ensuring they can't copy the clothing)<br />
* Customizable IM auto-response system, including giving inventory in the response<br />
* Fly can be set to always enabled, even with Admin menu closed<br />
* Can turn your avatar 'visually phantom'<br />
* Allows ground sit anywhere<br />
* Can enable the attaching of objects in inventory by double-click<br />
* Can block object sit-on-click<br />
* Chatbar as a command line for rezzing platforms, teleporting to coordinates or sims, or teleporting to particular heights.<br />
* Various crash fixes<br />
* Free uploading of "temporary" textures (sim-local and disappear on relog)<br />
* Notification when a friendship ends<br />
* Detection of cooperating alternative viewers<br />
* Shows object last owner in build floater<br />
* Scripts are compiled to mono by default in agent inventory<br />
* Inventory is fetched in background immediately on login<br />
* Group info can be accessed in about land, even if group is not deeded<br />
* Profiles show agent key<br />
* More minimap dot colors, blue for lindens, grey for muted, and purple for friended lindens<br />
* Build Floater Enhancements<br />
** More object choices (from the drop down that lets you change a cube to a sphere)<br />
** More precision information (5 decimal points)<br />
** Ability to set all prim parameters without changing shape (easy prim torture)<br />
** Ability to easily change sculpt stitching<br />
** Can set transparency to 100%<br />
** Can set texture repeats above 100<br />
* Can turn off the typing sound<br />
* Teleport History Floater<br />
* Animation Info Floater<br />
** Shows you all current animations being played on your avatar<br />
** Allows you to stop, or revoke permissions of animations you do not want<br />
** Ability to detect owner of the animations being played, as well as their name<br />
* Included the 1.23 Bulk Permissions Setting<br />
* Option to block the 1 click auto sit<br />
* Multiple custom skins<br />
<br />
''' Links '''<br />
* Website: http://www.modularsystems.sl<br />
* Direct download link: http://bit.ly/4C5QfE or http://modularsystems.sl/downloads.html<br />
* Online Support: http://modularsystems.sl/wiki/<br />
* Source code: http://bit.ly/4C5QfE or http://modularsystems.sl/downloads.html<br />
<br />
''' Version and time stamp '''<br />
<br />
* Version : 1.23.5.1634<br />
* Date : 04/19/2010<br />
* Status : Blocked<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Hippo OpenSim Viewer ===<br />
<br />
''' Description'''<br />
<br />
The Hippo OpenSim Viewer is a modified Second Life viewer, targeted at OpenSim users. It allows building up to a height of 10,000 m, scaling prims up to 256x256x256 m and other exciting features. More specific OpenSim features are under development.<br />
The last developer blog commented: Releasing Hippo OpenSim Viewer v0.6.3. This release adds a Windows uninstaller and small changes to comply to the Linden Lab Policy on Third-Party Viewers.<br />
<br />
''' Availability '''<br />
Is currently available for Linux and Windows.<br />
<br />
''' Links '''<br />
* Website: http://mjm-labs.com/viewer/<br />
<br />
''' Version and timestamp '''<br />
* Version : 0.6.3<br />
* Platforms:<br />
** Binary available for Windows and Linux<br />
** Source available (unspecified)<br />
* Date : April 24th, 2010<br />
* Status : Active + updated<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Imprudence ===<br />
<br />
''' Description '''<br />
<br />
From the [http://imprudenceviewer.org/wiki/Manifesto Imprudence Manifesto]:<br />
<br />
:&#147;The primary goal of Imprudence is simple: ''to greatly improve the usability of the Viewer''. In particular, there are 3 aspects of usability that we intend to address:<br />
:<br />
:* ''Approachability.'' Improving comfort and ease of use, especially for new or non-technical users.<br />
:* ''Efficiency.'' Improving speed and ease of common tasks and workflows.<br />
:* ''Satisfaction.'' Improving the emotional effect of the software on the user.<br />
:<br />
:This is not to minimize other aspects of usability, such as reliability, accessibility, or internationalization/localization. We recognize their importance, but lack the expertise to properly address them. We welcome people with such expertise to join the project and help.&#148;<br />
<br />
Note: Due to licensing issues, this viewer does not ship with the proprietary SLVoice module and its associated files. These can be added back from the official client for those needing voice. [http://imprudenceviewer.org/wiki/How_to_Re-enable_Voice_Chat Instructions for adding voice chat support] are available on the Imprudence Viewer wiki.<br />
<br />
''' Extra Features '''<br />
<br />
Check the [http://imprudenceviewer.org/wiki/Features Features page] on the Imprudence wiki for the most up to date features list.<br />
<br />
* Countless user interface improvements and bug fixes<br />
* Content Backup (export and import objects, scripts, and avatar shapes that you created)<br />
* Minimap Radar (minimap has a built-in "avatar radar" to tell you who is nearby)<br />
* Enhanced Minimap (better zooming, panning, double click to teleport)<br />
* Restrained Love (RLV) API Support<br />
* Double-click Teleport and Autopilot<br />
* [http://imprudenceviewer.org/wiki/Build_Math_Expressions Build Math Expressions]<br />
* Windlight Toolbar (quick access to windlight presets and graphics settings)<br />
* Grid Manager, with built in support for alternative grids like OSGrid, ReactionGrid, 3rd Rock Grid, and more<br />
* Search Inventory by Creator or Description<br />
* Inventory Quick Filter (quickly filter inventory to show only notecards, or only clothing, etc.)<br />
* Worn Items Tab (shows what you are currently wearing)<br />
* Unread IM Count (shows how many new/unread IMs you have)<br />
* Middle-mouse Paste for Linux<br />
* Confirmation dialogs to prevent accidents (no more accidently teleporting home!)<br />
* Restore to Last Position (rez objects at their previous position)<br />
* Offer Teleport button in the IM window<br />
* Double-click to wear attachments in inventory<br />
* "Phantom Avatar" Mode<br />
* Asset (Texture) Browser<br />
* Animation List<br />
* See object's Last (previous) Owner<br />
* Ground Sit Anywhere<br />
* Hide Selection Outlines (hide the laggy and distracting glowing outlines when building)<br />
* Choose Default Chat Channel<br />
* Includes stability improvements from Nicholaz<br />
<br />
''' Links '''<br />
* Website: http://imprudenceviewer.org/<br />
* Download: http://imprudenceviewer.org/wiki/Downloads<br />
* Forums: http://imprudenceviewer.org/forums/<br />
* The Imprudence Manifesto: http://imprudenceviewer.org/wiki/Manifesto<br />
<br />
''' Version and timestamp '''<br />
* Version : 1.3.0 RC2<br />
* Date : August 28, 2010<br />
* Version : 1.2.1<br />
* Date : November 26, 2009<br />
* Platform: Windows, Linux, Mac<br />
* Status : Active<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Kirstens Viewer ===<br />
<br />
''' Description '''<br />
<br />
This is a Hybrid Viewer based primarily around SVN trunk,snowglobe trunk and render-pipeline , its specifically aimed at High End Systems (photography and film makers).<br />
The viewer also has additions and UI changes from Kirsten and others such as Niran's UI mods.<br />
<br />
''' Major Features '''<br />
* Custom Viewer 2.0 UI - Ability to use custom skins<br />
* Custom Deferred Render Pipeline<br />
* Global Illumination, Projected textures, SSAO, Touch Glow etc <br />
* Modified Camera Controls<br />
* Post Process Effects, Including Anaglyph 3D shader<br />
* Multi wearables - Multi Attachment System<br />
* Extra Windlight Settings and Enhanced Environment Controls<br />
* Ability to control visual elements such as Hover text<br />
* Enhancements to Build Controls, planar textures , transparency.<br />
* Extra Controls for shadows,viewer,performance,global illumination<br />
<br />
* Higher Framerates on supported hardware.<br />
<br />
''' Version and timestamp '''<br />
<br />
* Version: 2.1.0 (35)<br />
* Date : 2010 August 30<br />
* Status : Active<br />
<br />
<br />
''' Links '''<br />
<br />
Homepage / Forums / Downloads: http://www.kirstensviewer.com/<br />
Source SVN: http://sourceforge.net/projects/kirstensviewers/develop<br />
Commit History Trac: http://sourceforge.net/apps/trac/kirstensviewers/<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Restrained Love ===<br />
<br />
''' Description '''<br />
<br />
This viewer, codename "'''RestrainedLove'''" is an attempt at enhancing the experience of people who practice BDSM in Second Life. It is used jointly with simple scripts made to use its features in-world, such as making an attached object undetachable, preventing chat and such. An '''API''' (Application Programming Interface, a text file) is provided so that every content creator can create their own scripts to interface their own items to the viewer and use its features.<br />
<br />
''' Extra Features '''<br />
* Attachments can be made undetachable<br />
* Chat and IM prevention on demand, with exceptions if needed<br />
* Teleport and sit-tp prevention on demand, with exceptions if needed<br />
* Editing and Rezzing prevention on demand<br />
* Adding/Removing clothes on demand, + force remove clothes and force remove unlocked attachments<br />
* Force sit and prevent stand up (even after a relog) on demand<br />
* Manual (by IM) and automatic (by script) version checking<br />
* Force attach objects and outfits<br />
* API for content creators<br />
* And more...<br />
<br />
''' Links '''<br />
* Website: [http://realrestraint.blogspot.com/ Marine Kelley's blog on Blogspot]<br />
* Direct download link to the Windows viewer: [http://www.erestraint.com/realrestraint Download for Windows] (Executable and readme)<br />
* Direct download link to the MacOS X viewer: [http://www.erestraint.com/realrestraint Download for MacOS X] (Executable and readme, courtesy of Mo Noel)<br />
* Direct download link to the Linux viewer: [http://www.erestraint.com/realrestraint Download for Linux] (Executable and readme, courtesy of Loom Kish)<br />
* Source code and text API : [http://www.erestraint.com/realrestraint Download] (Text files)<br />
* API as a wiki page : [[LSL Protocol/RestrainedLoveAPI|API]] (Wiki format)<br />
* Specification to interface cages and furnitures with the viewer through the use of a relay : [[LSL Protocol/Restrained Love Relay Specs|Relay Specs]] (Wiki format)<br />
<br />
''' Version and timestamp '''<br />
<br />
* Version : 2.1.2.2 , Standalone version<br />
* Date : Sept 5, 2010<br />
* Version : 1.22.1 , compiled on SL official viewer 1.23.5<br />
* Date : 02/25/2010<br />
* Status : Active<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Toxic Viewer ===<br />
<br />
'''No Longer In development. '''<br><br />
<br />
https://dcs.sourcerepo.com/dcs/tox_view/ <br />
<br />
Source only now as it is not actively developed.<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
<br />
<br />
=== Emerald Viewer, Frequency Edition ===<br />
<br />
''' Description'''<br />
<br />
This viewer is based on GreenLife Emerald Viewer, but includes a couple of modifications.<br />
<br />
''' Added Features (compared to GreenLife Emerald) '''<br />
<br />
* Busy-on-lost focus: Allows resident to automatically switch to busy mode after a set amount of time, _after_ the viewer window lost focus (good for people who have other work to do, and want to ensure that other residents know why their IMs remain unanswered)<br />
* custom tags on a per-avatar basis: add keywords to residents' group/name tag hover box<br />
* display group/name tags in individual colours (per avatar)<br />
* display payment info and age in name tags<br />
** friends always coloured yellow<br />
** muted people always in grey<br />
** all others in a chosen colour out of 7 options<br />
* grey out groups, which have been chosen not to be displayed in your profile<br />
<br />
''' Removed Features '''<br />
* IRC client<br />
* experimental Utility Stream<br />
* Client detection (conflicts with the aforementioned use of name tags)<br />
<br />
''' Availability '''<br />
Emerald Viewer, Frequency Edition is currently available as Intel-only OS X binary, and as full source code for OS X, Windows & Linux.<br />
<br />
''' Version and timestamp '''<br />
<br />
* Version : Emerald Viewer, Frequency Edition, 1.0.2 (based on GreenLife Emerald 1.23.4-673)<br />
* Platforms:<br />
** Binary available for OS X 10.5+ (any volunteers for Windows/Linux?)<br />
** Source valid for OS X, Linux, Windows<br />
* Date : Sep 25th, 2009<br />
* Status : Discontinued as of November 8, 2009, download no longer available<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Phoenix Viewer ===<br />
<br />
''' Description '''<br />
<br />
Phoenix Viewer is a fork of the well known Emerald Viewer, created to keep the Emerald features alive after Linden Lab placed the block on that viewer. This is not Emerald renamed. Phoenix is a new project, with a new team, new goals, new objectives, new procedures and full transparency in everything. Starting out where Emerald left off at version 2587, Phoenix developers have already made a lot of progress in finding and fixing bugs as well as creating some new features. Currently, Phoenix is based on Snowglobe 1.5, with its most recent release being 1.5.1.373. Phoenix is listed on the Linden Lab Third Party Viewer Directory.<br />
<br />
''' Extra Features '''<br />
<br />
* Avatar Scanner<br />
** Full sim range (detects over 1M in the air)<br />
** Shows name, age, payment info, current activity. <br />
** Land and estate commands for ejecting/banning multiple avatars at once<br />
** Buttons to open profile, IM, teleport to or track selected avatars<br />
** Ability to chat radar info (keys) to boost lsl radars<br />
** Ability to display chat notifications for entering sim, exiting sim, entering chat range, exiting chat range, entering draw distance and exiting draw distance respectively.<br />
* RLV API Implementation (off by default)<br />
* Different login page<br />
* Ability to open and display the owner and location of objects that IM you<br />
* Teleport to positions by double clicking<br />
* Option to disable progress screens (teleport, login, and logout respectively)<br />
* Clothing layer protection (prevents sending of individual clothing textures to other clients, ensuring they can't copy the clothing)<br />
* Customizable IM auto-response system, including giving inventory in the response<br />
* Fly can be set to always enabled, even with Admin menu closed<br />
* Can turn your avatar 'visually phantom'<br />
* Allows ground sit anywhere<br />
* Can enable the attaching of objects in inventory by double-click<br />
* Can block object sit-on-click<br />
* Chatbar as a command line for rezzing platforms, teleporting to coordinates or sims, or teleporting to particular heights.<br />
* Various crash fixes<br />
* Free uploading of "temporary" textures (sim-local and disappear on relog)<br />
* Notification when a friendship ends<br />
* Detection of cooperating alternative viewers<br />
* Shows object last owner in build floater<br />
* Scripts are compiled to mono by default in agent inventory<br />
* Inventory is fetched in background immediately on login<br />
* Group info can be accessed in about land, even if group is not deeded<br />
* Profiles show agent key<br />
* More minimap dot colors, blue for lindens, grey for muted, and purple for friended lindens<br />
* Build Floater Enhancements<br />
** More object choices (from the drop down that lets you change a cube to a sphere)<br />
** More precision information (5 decimal points)<br />
** Ability to set all prim parameters without changing shape (easy prim torture)<br />
** Ability to easily change sculpt stitching<br />
** Can set transparency to 100%<br />
** Can set texture repeats above 100<br />
* Can turn off the typing sound<br />
* Teleport History Floater<br />
* Animation Info Floater<br />
** Shows you all current animations being played on your avatar<br />
** Allows you to stop, or revoke permissions of animations you do not want<br />
** Ability to detect owner of the animations being played, as well as their name<br />
* Option to block the 1 click auto sit<br />
* Multiple custom skins<br />
<br />
''' Links '''<br />
* Website: http://www.phoenixviewer.com<br />
* Direct download link: http://wiki.phoenixviewer.com/doku.php?id=downloads<br />
* Online / Support and bug reporting: http://jira.phoenixviewer.com/<br />
* Source code: http://hg.phoenixviewer.com/<br />
<br />
''' Version and time stamp '''<br />
<br />
* Version : 1.5.1.373<br />
* Date : October 7, 2010<br />
* Status : Active<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Meerkat ===<br />
<br />
''' Goals '''<br />
<br />
* To create a fully GPL viewer (no proprietary dependencies)<br />
* To encourage a community of developers that will submit patches for prompt integration<br />
* To have the freedom to make the sort of changes that Linden Lab has traditionally been unable to integrate (translation patches, refactoring, fixing intentionally crippled features, changes that touch many files)<br />
* To retain compatibility with Linden Lab's grid and protocols, present and future<br />
* To implement a loosely coupled cross-grid functionality that requires no central authentication authority.<br />
<br />
''' Extra Features '''<br />
* Log out and back in without quitting<br />
* Loosely coupled intergrid teleport -- In Process<br />
* Most of the other changes common to third party viewers<br />
<br />
''' Links '''<br />
* <del>Website: [http://www.meerkatviewer.org/ Meerkat Viewer]</del> (note: the Meerkat site is down)<br />
* Direct download link: [http://code.google.com/p/meerkat-viewer/downloads/list Download versions of this viewer] <br />
* Source code: svn checkout http://meerkat-viewer.googlecode.com/svn/trunk/ meerkat<br />
<br />
''' Version and timestamp '''<br />
* Version : 0.2.x<br />
* Date : September 6, 2009<br />
* Status : Discontinued, website offline. Source and binary downloads still available on google code (see above).<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Nicholaz Edition ===<br />
<br />
''' Description '''<br />
<br />
These are Windows viewer based on SL builds with a focus on stability, usability and performance (see [http://www.blueflash.cc/users/nicholaz/EyeCandy/!!Installation.txt Installation.txt] for homebrew disclaimer). Mac and Linux variants are available through other open sourcers (links on the website).<br />
<br />
''' Extra Features '''<br />
* Improved stability<br />
* Lower memory footprint<br />
* GUI redesigns <br />
* Workarounds for common annoyances (Group IM Filtering, "Release Key" button, etc.)<br />
* see [http://nicholaz-beresford.blogspot.com/2008/05/version-overview.html this entry] for an overview of different versions<br />
<br />
''' Links '''<br />
* Website: [http://nicholaz-beresford.blogspot.com/ Nicholaz Beresford on Blogspot]<br />
* Direct download link: [http://www.blueflash.cc/users/nicholaz Download versions of this viewer] <br />
* Source code: Look at the [http://www.blueflash.cc/users/nicholaz download site] for the source-xxx-zip files in the respective folders and see the readme.txt inside the archives<br />
<br />
''' Version and timestamp '''<br />
<br />
* Date : 09/07/2009<br />
* Status : Discontinued<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Onrez Viewer ===<br />
<br />
''' Description '''<br />
<br />
The Onrez viewer was made by the Onrez company in connection with a Second Life themed story on the high tech forensics based TV show "CSI: New York".<br />
<br />
''' Extra Features '''<br />
* A back and history button for teleports<br />
* In-viewer web browsing. <br />
<br />
''' Comment '''<br />
The source code for this viewer is closed source.<br />
<br />
''' Version and timestamp '''<br />
* Status : Discontinued, download no longer available<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Rainbow Viewer / Cool Viewer ===<br />
<br />
''' Description '''<br />
<br />
Based on the offical SecondLife sourcecode licensed under GPL2, this speedy Metaverse Client can connect you to a huge variety of exciting Virtual Worlds! It incorporates a lot of improved, new, up- and backported features and fixes that make the fast and rock stable RV/CV the client of choice for many users.<br />
<br />
This viewer includes many patches and changes from a lot of different people and sources which I am very grateful to be able to use. Credits are given to everyone I know, in case I missed someone I sincerely apologize.<br />
<br />
Thanks to Henri Beauchamp who laid the foundation for this viewer with his Cool SL Viewer. Special thanks to Winter Ventura for the Cool Viewer logo and Jacek Antonelli and Peter Stindberg for the Rainbow Viewer logo :). And to all the others who helped and supported me, especially the people involved and behind Imprudence!<br />
<br />
<br />
''' Some incomprehensive list of features '''<br />
<br />
A major improvement is an up-to-date OpenGL implementation that especially helps users plagued by ATI's Catalyst drivers but also leads to measurable improvements of overall graphics performance by 30...100% compared to the official viewer; depending on your system. Rainbow Viewer features the current user interface whereas Cool Viewer spots the leaner cleaner and more configurable legacy UI. It's all about choice :).<br />
<br />
* New 1.22.12.0 code baseline<br />
* CV's legacy User interface with a clean, simple and userfriendly layout or Rainbow Viewers current official UI, you choose!<br />
* Improved Graphics rendering, especially for ATI users (measured >1/3 faster than the official viewer)<br />
* Alpha and Tattoo Layer support from SL 2.0<br />
* Updated tested list of Virtual World grids<br />
* Marine Kelley's RestrainedLove (off per default)<br />
* Full Adult Compliance<br />
* Redesigned and "up-ported" search functionality, probably the best search in any viewer nowadays<br />
* Jiggly Bewbz :)<br />
* Temporary texture and animation upload<br />
* Better inventory search for content, description and creator <br />
* Low lag radar and AV management tools<br />
* Viewer skinning<br />
* Object and Shape export/import, limited to creator<br />
* Bulk permission editing<br />
* Last owner display to track content theft <br />
* "Worn" tab in inventory <br />
* Double click to wear attachments <br />
* Enhanced building tools <br />
* Flexible Sculpties <br />
* Large Prims (currently only for Opensim grids due to SL limitations) <br />
* Maximized Network Bandwidth <br />
* Flexible Grid selection at login for SL and all OpenSims <br />
* Teleport History and speedy doubleclick teleport <br />
* Avatar UUID in profiles<br />
* Features tab in Preferences for easy switching of features<br />
* Optimized latest OpenJPEG 1.3 <br />
...and a large number of other goodies and stability fixes that improve your overall experience. Too many to mention here :). Please check the [http://code.google.com/p/coolviewer/wiki/ReleaseNotes Release Notes] for details.<br />
<br />
<br />
''' Links '''<br />
* Website: [http://my.opera.com/boylane Rainbow Viewers for Virtual Worlds]<br />
* Direct download link: [http://coolviewer.googlecode.com Binary versions on Google Code]<br />
* Source code: [http://github.com/boy Sources on Github]<br />
<br />
<br />
''' Version and timestamp '''<br />
<br />
* Rainbow Viewer 1.22.12 R6<br />
* Rainbow Viewer Cool Edition (Cool Viewer) 1.22.12 R13 <br />
* Rainbow Viewer Netbook Edition v1.2 (speedy pre-Windlight 1.19.0.5)<br />
* Date : 24/04/2010<br />
* Status : Active<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== RealXtend Edition ===<br />
<br />
''' Description '''<br />
<br />
The realXtend viewer is a heavily modified version of the Linden Lab's Second Life client by a partnership of two Finnish companies, ADMINO technologies and LudoCraft.<br />
<br />
The successor to the realXtend viewer is Naali (release 0.3.1 on 21st September 2010, download from http://code.google.com/p/realxtend-naali/downloads/list).<br />
<br />
'''Extra Features '''<br />
* Second life compatibility mode for use in SL and Opensim worlds<br />
* Teleports between realXtend and Secondlife<br />
<br />
''' Links '''<br />
* Website: http://www.realxtend.org/<br />
* Direct download link: http://www.realxtend.org/downloads.html<br />
* Source code: http://sourceforge.net/projects/realxtendviewer/<br />
<br />
''' Version and timestamp '''<br />
* Version : 0.4.2<br />
* Date : 09/24/2009<br />
* Status : Discontinued, replaced by Naali.<br />
<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Snowglobe, Frequency Edition ===<br />
<br />
''' Description'''<br />
<br />
This viewer is based on Linden Lab's Snowglobe Viewer, but includes a bunch of modifications, some of them custom-made, some adopted from other viewers (Emerald, Meerkat, Cool SL).<br />
<br />
''' Snowglobe: Frequency Edition -- Features '''<br />
<br />
Some highlights:<br />
<br />
* Kitty Barnett's RLVa 1.0.4e.<br />
* Radar client / Avatar List<br />
* Teleport History Floater<br />
* Double-Click Teleport<br />
* Double-Click Inventory Actions<br />
* Inventory Quick-Filter<br />
* Custom Tags for Avatars with Colours (and Payment Info/Age)<br />
* Z-axis Offset Change to avoid Sinking into the Ground<br />
* Option to disable Progress Screens (Teleport, Login, and Logout respectively)<br />
* Show List of alt Avatars upon Login<br />
* Detection when someone starts a new Instant Message (allow to optionally steal Focus)<br />
* Avatar Height displayed in "Edit Appearance" Floater<br />
* Sit anywhere Functionality<br />
* Instant Inventory Loading on Login<br />
* Slider for Drawing Distance/Graphics Remote<br />
* Camera Zoom up to 1024m<br />
* Show Age in Days in Profile Floater<br />
* Free uploading of "Temporary" Textures<br />
* Unpublished Groups greyed-out <br />
* busy-on-lost-focus <br />
* added Busy-Mode shortcut <br />
<br />
We are currently working on more features.<br />
<br />
''' Links '''<br />
* Website: http://www.sfreq.org/wiki/snowglobe/Releases (find binary & source code there)<br />
<br />
''' Version and timestamp '''<br />
<br />
* Version : Snowglobe:Frequency 1.2.0 (based on unreleased Snowglobe 1.2.0, SVN trunk 2834)<br />
* Platforms:<br />
** Binary available for OS X 10.5+ Windows, Linux<br />
** Source valid for OS X, Linux, Windows<br />
* Date : Oct 17, 2009<br />
* Status : Discontinued on January 21, 2010<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== omvviewer ===<br />
<br />
''' Goals '''<br />
<br />
* To create a fully GPL viewer (no proprietary dependencies)<br />
* To enable easy building of the source code on various Linux distros including 64 bit distros<br />
* To Get the viewer packaged with in Linux Distros<br />
<br />
''' Packages available (32 and 64 bit) '''<br />
* Debian Lenny <br />
* Ubuntu Intrepid <br />
* Arch <br />
* Gentoo <br />
<br />
''' Extra Features '''<br />
Various extra features found in other viewers, UI changes are kept to a bare minimum as this is a packaging project not a code base fork. Stability fixes are given high priority.<br />
<br />
''' Links '''<br />
* Website: [http://omvviewer.byteme.org.uk/ Project page]<br />
* Source code: [http://omvviewer.byteme.org.uk/source.shtml Source details]<br />
<br />
''' Version and timestamp '''<br />
<br />
* Date : 27/March/2009<br />
* Version : 1.22.11<br />
* Status : Active<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Combat Cubed ===<br />
<br />
''' Description '''<br />
<br />
This client is aimed mostly at the SL Military, but sports quite a few interesting improvements that make it worth taking a look at.<br />
<br />
''Originally known as Vertical Life.''<br />
<br />
''' Major Features '''<br />
* Enhanced Look & Feel, for example flexible camera movement<br />
* Prototype Script API, secure and parallel<br />
* Slimmed down for FPS combat<br />
* Identification, Friend versus Foe, mostly under the hood now but soon exposed<br />
<br />
''' Links '''<br />
* Splash: http://bit.ly/cXOcDX<br />
<br />
''' Version and timestamp '''<br />
<br />
* Version: 1<br />
* Date : 2010 June 16<br />
* Status : Active<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== TEKSTUFF Viewers ===<br />
<br />
''' Description '''<br />
<br />
The TEKSTUFF viewers are created to enable Youtube movies on TEKSTUFF media screens inside Second Life. The TEKSTUFF viewers are slight modifications of already available viewers like the regular SL 1.23.5 viewer and the Emerald 1634 viewer. Apart from that, the Emerald based viewer is fixed so it can be used in Opensim grids as well. <br />
<br />
''' Links '''<br />
* Web presence: http://www.tekstuff.net/<br />
<br />
''' TODO '''<br />
<br />
* Make a Linux viewer<br />
* Make a Mac OS viewer<br />
<br />
''' Major Features '''<br />
* All the functionality of the viewer it was based upon (LL 1.23.5 or Emerald 1634)<br />
* Will allow you to view Youtube movies on TEKSTUFF media screens<br />
* The Emerald based viewer can also be used in OpenSim grids (texture loading is fixed)<br />
<br />
<br />
''' Version and timestamp '''<br />
<br />
* Version: 1.23.5 (LL & Emerald)<br />
* Date : 2010 April 20<br />
* Status : Active<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Milk Release Client ===<br />
<br />
<br />
''' Description '''<br />
<br />
This client is aimed at development of all kinds, thrown together by Project Neox. Focusing on advanced non-profit development of Second Life and various features to whom content creators would find suitable.<br />
<br />
<br />
''' TODO '''<br />
<br />
* XStreetSL shopping UI client-kiosk<br />
* Compile Linux and Mac OS X builds<br />
* Multiple link object texturing, via name<br />
* Completion of 3-Dimensional Mini Map<br />
* Region Statistics notifications before teleports<br />
<br />
<br />
''' Major Features '''<br />
* Rendering options for individual avatars<br />
* Secure Voice-chat usage<br />
* Extensions in avatar editing<br />
* Additional Attachment points<br />
<br />
<br />
''' Version and timestamp '''<br />
<br />
* Version: 1.23.5<br />
* Date : 2010 January 20<br />
* Status : Discontinued and won't be available for download. <br />
<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
==Text-Only Viewers==<br />
<br />
===AjaxLife ===<br />
''' Description '''<br />
Browser based Second Life client, created by Katharine Berry. The only web-browser client which made it a lifeline for residents who could not use a full graphical viewer, or who could not download other text-only clients because of limitations such as corporate firewalls.<br />
<br />
(Now running again!)<br />
<br />
''' Links '''<br />
* Website: http://ajaxlife.net/<br />
<br />
''' Version and timestamp '''<br />
* Version: 0.6.1.2<br />
* Date: 2010/05/21<br />
* Platform: Platform independant<br />
* Status: Active<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== METAbolt ===<br />
''' METAbolt is a Second Life TPV Directory listed Text Client (http://viewerdirectory.secondlife.com/listing/show/listing_id/118) '''<br />
<br />
''' Description '''<br />
<br />
METAbolt is an SL text client. It is light weight and cross grid, which means it will work in Second Life as well as other grids that are based on OpenSIM. METAbolt is Open Source so it's free...it is built ground up using libopenmetaverse and it is '''not''' a modified version of the official SL viewer. Currently METAbolt is only available for Windows platforms.<br />
<br />
METAbolt is ideal if:<br />
<br />
* the graphical viewers are not allowed at your work place <br />
* you have a low powered computer that has difficulty running the SL viewer<br />
* you have a low speed internet connection e.g. dial up/ISDN <br />
* you need to run multiple alts at the same time for land security, modelling, group management functions etc <br />
* you can't or don't want to run the SL viewer all the time but need the ability to stay online for communications or other reasons<br />
<br />
''' Features '''<br />
<br />
Too many to be listed here! Here are just a few:<br />
<br />
* Ability to mass distribute products, objects, scripts etc<br />
* Ability to start multiple instances for different alts from a command and/or batch file<br />
* Fully ACCESSIBLE and also compatible with accessibility client applications such as JAWS for SL users with disabilities<br />
* Auto log-in upon SL disconnect<br />
* Built in Machine Translation with 16 language pairs<br />
* Auto spoken language detection<br />
* Emoticons on chat & IM. Feature can be switched on/off<br />
* Detailed user preference settings<br />
* Auto clothes changer<br />
* Send/receive group notices<br />
* Ability to wear and take off clothing, shape, skin and objects<br />
* Sophisticated AI (Artificial Intelligence)<br />
* Radar which shows nearby avatars with distances. The distance can configured to any level via application settings<br />
* Radar has single click icons for IM, profile, worn attachments, friendship offer, turn to, follow, go to, freeze, eject, ban of selected avatar on radar list<br />
* Teleport history with ability to save any location as a landmark as well as Teleport with one click<br />
* Mute list of avatars and objects<br />
* Ability to disable Group IMs and Group Notices<br />
* Auto-sit upon login optional fuction<br />
* Ability to relay IMs to Twitter in real time<br />
* Ability to use/display local or SL time<br />
* Fully functional SL like "About Land" with "return of objects" feature on selected avatar/s<br />
* Functional Profile viewer where you can edit your details<br />
* Advanced IDE for developers to develop in LSL, C#, SQL, Java, XML and many others with context help, tooltips, snippets and more<br />
* Ability to create, edit, save scripts and notecards to inventory as well as Hard Drive (only the ones you own)<br />
* Picture viewer to view textures and snapshots in detail with the ability to rotate and save to Hard Drive (only the ones you own)<br />
* Full chat & IM logs (features can be switched on/off)<br />
* Music player with album art and lyrics<br />
* Media player capable of playing ANY internet based content specified in land media (providing you have the necessary software installed on your machine)<br />
* Movement direction buttons<br />
* Mini map with ZOOM capability on chat screen for a "single click" access<br />
* Large/main map with icons that show other avatars on the same level as you, above you and below you with a "click and teleport" feature on the map<br />
* SL search on Events, Places, People and Groups<br />
* Advanced auto update features which you can configure to your liking<br />
* Object Manager: Detailed object information (including child objects and task inventory), stats and powerfull search function which also offers the ability to edit Permissions on objects you own (this is also available via the inventory)<br />
* Group Manager plug-in for sending direct group invites (optional)<br />
* Uses low computing power and bandwidth<br />
* Displays advertising from various partners<br />
* One-to-One quick technical support via METAforums<br />
* Plug-ins & extensions are supported from developers. As well as DLL & EXEs, uncompiled classes can be developed in C#, VB and Java and dropped in as an extension<br />
<br />
''' Links '''<br />
* Website: http://www.metabolt.net/<br />
* Wiki: http://www.metabolt.net/METAwiki/<br />
* Download: http://www.metabolt.net/download.asp<br />
* Source code: http://www.metabolt.net/download.asp (includes plug-in/extension sample project)<br />
<br />
''' Version and timestamp '''<br />
* Version : 0.9.33.0 (BETA)<br />
* Date : 26/09/2010<br />
* Platform: Windows Only<br />
* 32bit & 64bit versions<br />
* Status : Active<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== omvviewer-light ===<br />
<br />
''' A Text client for the 3D Metaverse '''<br />
<br />
''' Description '''<br />
omvviewer-light is a text client for the 3D Metaverse including SecondLife, written from Scratch (but using the libomv library for protocol handling). It's GUI is created in Gtk# which is cross-platform making this the only current Text client that is still active and cross platform. Tested on Linux (32/64 bit) and Windows (not 64-bit windows).<br />
<br />
''' Features '''<br />
To many to list here in detail please see the project page below but in summary, Full inventory control, Full Chat/IM/Group IM's. Object search and interaction. Realtime local maps. Parcel displays. Read and Edit NoteCards and Scripts. View profiles. Friends Lists etc .....<br />
<br />
''' Links '''<br />
* Website: [http://omvviewer-light.byteme.org.uk/ Project page]<br />
* Source code: [http://omvviewer-light.byteme.org.uk/source.shtml Source details]<br />
<br />
''' Version and timestamp '''<br />
<br />
* Date : 25/Aug/2009<br />
* Version : 0.48.0.6<br />
* Status : Active<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Radegast ===<br />
<br />
''' Lightweight client for connecting to Second Life and [http://opensimulator.org/ OpenSim] based virtual worlds '''<br />
<br />
''' Description '''<br />
<br />
Radegast is feature rich GUI client. With it's full support for all communication within a virtual world (chat, IM, group IM, friends conference) it's ideal for situations where full 3D client is less than ideal solution, for example, an office environment, too slow a machine and similar.<br />
<br />
It's written using [http://lib.openmetaverse.org/ libopenmetaverse], and it runs on any platform that supports .NET/mono. Its being actively tested on Windows and Linux. <br />
<br />
''' Features '''<br />
<br />
* Chat (local, IM, group, friends conference)<br />
* Inventory (allows manipulation, deletion of the items, moving them around, sending to other people by dropping item on their profile)<br />
* Ability to wear/take off clothes and attachments from the inventory<br />
* Backup of all scripts and notecards from the inventory<br />
* World map (works on all grids)<br />
* Object finder - list objects nearby, sort them by distance, name, see details<br />
* A.L.I.C.E AI chat - turn it on in tools menu and have fun with automatic responses to chat/IM generated by a built in Artificial Intelligence<br />
* List of all avatars in a region (radar), and those within 300m in nearby regions<br />
* Movement controls<br />
* Support for activating gestures from the inventory<br />
* Avatar appearance - others using 3D client will see you appear correctly, and will not be able to tell that you're using a text client<br />
* Streaming music<br />
* Accessibility improvements for blind and visually impaired SL'ers<br />
* Text-To-Speech for reading out loud incoming messages<br />
* Speech recognition for controlling UI and entering text in chat<br />
* Experimental voice support for local chat<br />
* Partial RLV support <br />
* Manipulation of object contents, notecard and script editing<br />
* Group management<br />
* On Windows, support 3D view of in-world objects<br />
* Command line interface (type //help for list in the main chat console)<br />
* TPV compliant and listed in the [http://viewerdirectory.secondlife.com/listing/show/listing_id/148 official viewer directory.]<br />
* Command line options that allow (among other things) to automatically login using supplied credentials<br />
* In-world sounds<br />
<br />
''' Links '''<br />
<br />
* Website: [http://radegastclient.org/ radegastclient.org]<br />
* Downloads: [http://radegastclient.org/wiki/Radegast_Download Downloads]<br />
* Nightly build: [http://radegastclient.org/files/radegast-latest.zip Zip Archive] [http://radegast.sourceforge.net/files/radegast-latest.exe Windows Installer]<br />
* Source code: [http://radegastclient.org/wiki/Radegast_Download#Source Source bundle]. Instructions on how to build Radegast from source can be found [http://radegastclient.org/wiki/Building_From_Source here].<br />
* Report bugs/request new features: [http://jira.openmetaverse.org/browse/RAD Issue tracker]<br />
* Documentation: [http://radegastclient.org/wiki/ Wiki]<br />
<br />
''' Version and timestamp '''<br />
<br />
* Date : July 28, 2010<br />
* Version : 1.22<br />
* Status : Active<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Whisper (SlXSLChat) ===<br />
<br />
''' A light-weight yet feature rich text-only Second Life client '''<br />
<br />
''' Description '''<br />
Whisper is a text-only Second Life client that comes in two parts. The client is written in Java (so it can run on many platforms). The client connects to a "transport", which is written in C# and uses LibOpenMetaVerse. The idea behind this architecture is that if you don't like the client, you can write your own and not have to worry about implementing the Second Life protocol yourself. The entire project is open source and published under the GPLv3 licence.<br />
<br />
''' Features '''<br />
* Public chat<br />
* Instant messaging<br />
* Group chat<br />
* Search/join/leave groups<br />
* Search for avatars<br />
* Image retrieval<br />
* Profile retrieval<br />
* Notifications / popups as you would get in Second Life (e.g. group notices, balance changes, inventory offers)<br />
* Teleportation (home, to area within current sim, to nearby avatar)<br />
* Nearby avatar tracking on map of Sim<br />
* Autopilot navigation to nearby avatars<br />
* URL highlighting<br />
* Encrypted traffic between client and transport<br />
* Transport can be run anywhere, the client connects via TCP/IP<br />
* Client only sends MD5 hashed password to transport<br />
* On Apr.20, 2010, SlXSLChat has rebranded to “Whisper”.<br />
<br />
''' Links '''<br />
* Website: [http://whisper.slx.cc/ Whisper]<br />
* SourceForce Project Page: [https://sourceforge.net/projects/slxslchat/ Project Page]<br />
<br />
''' Version and timestamp '''<br />
* Date : May 9, 2010<br />
* Version : 1.3<br />
* Status : Active<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== SLeek ===<br />
First text only viewer ever, mentioned for completeness, not actively maintained anymore. MetaBolt is based on SLeek.<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
<br />
=== SLiteChat ===<br />
<br />
''' A Lite IM/Chat Text-only Client for Second Life '''<br />
<br />
''' Description '''<br />
SLiteChat (pronounced "slight-chat") is a completely open source text-only IM/chat client for use with Second Life. Use it to talk to your friends without having to load up all of those heavy graphic goodies. Useful for those at work times. :-) <br />
<br />
''' Features '''<br />
* Communicate in-world with people on your friends list. Full adding/removing and search for Residents supported.<br />
* Group chat is supported (however at this writing you cannot leave a group or search for to join).<br />
* Local chat and IM history is supported.<br />
* Can log into other grids.<br />
<br />
''' Links '''<br />
* Website: [http://www.slitechat.org/ Project page]<br />
* Source code: [http://www.slitechat.org/download/ Source details]<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
===Sparkle IM for iPhone and iPod Touch ===<br />
<br />
''' Second Life Chat and IM on your iPhone or iPod Touch '''<br />
<br />
''' Description '''<br />
iPhone and iPod Touch based Second Life Client, developed by Genkii. The only native client available on the iPhone. Connect over 3G, Edge or Wifi to Second Life for a easy and fast communication in SL on the go. <br />
<br />
''' Links '''<br />
* Website: http://sparkle.genkii.com/<br />
* iTunes AppStore: http://bit.ly/6DRS2<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== Touch Life for iPhone ===<br />
<br />
''' iPhone Client for Second Life '''<br />
<br />
''' Description '''<br />
<br />
Touch Life allows you to log into Second Life anytime from your iPhone or iPod Touch. <br />
<br />
''' Features '''<br />
<br />
* Instant Messaging - Initiate or respond to individual or group IM's.<br />
* Chat - Converse with nearby avatars.<br />
* World Map - View sims, teleport, search or use landmarks.<br />
* MiniMap & Who's Nearby - Zoom in, move & turn, see who's nearby.<br />
* Inventory - View notecards & pictures, give & accept items.<br />
* Profiles - View profiles, make payments, teleport, befriend.<br />
* Groups - View groups, join & leave, send invites.<br />
* Search - Find people, groups, places, regions, and more.<br />
* Photos - Snap pictures and upload as textures.<br />
* Much More!<br />
<br />
''' Links '''<br />
* Website: http://www.pocketmetaverse.com/<br />
* AppStore: [http://itunes.apple.com/us/app/touch-life/id343511720?mt=8 Open in iTunes]<br />
<br />
[[#Viewers|[Back to the list]]]<br />
<br />
=== MetaPay for iPhone and iPod Touch ===<br />
<br />
''' Send L$ with a simple to use and free iPhone App. '''<br />
<br />
''' Description '''<br />
<br />
MetaPay is a simple and fun way to send Linden Dollars from your iPhone and iPod touch for FREE! Out with friends and want to pay your part of the tab but have no cash? Use MetaPay to send L$ to your friends in Second Life® instead. Or use it to send L$ for any in-world use without firing up the full Second Life® client. <br />
<br />
''' Links '''<br />
* Free in the AppStore: [http://bit.ly/metapay Open in iTunes]<br />
<br />
[[#Viewers|[Back to the list]]]</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=Sculpted_Prims:_Resident-made_Tools&diff=1038612Sculpted Prims: Resident-made Tools2010-09-18T19:02:25Z<p>Tonya Souther: /* Sculpt Studio */ updating link from XSL to Marketplace</p>
<hr />
<div>{{Help|Object=*}}<br />
{| align="right"<br />
| __TOC__<br />
|}<br />
<br />
This page showcases '''special purpose tools''' for creating, manipulating, and viewing sculpted prims. Most of them are created by SL residents, but the reason they are on this page is that they are ''not'' general purpose 3D tools.<br />
For that list, see [[Sculpted Prims: 3d Software Guide]].<br />
<br />
= Preview Tools =<br />
<br />
== Offline Preview Tools ==<br />
Basic tools that can be used to preview what a sculpt texture will look like when uploaded into Second Life and rendered as a prim. All of these are made by other Residents and should generally be considered beta or works in progress.<br />
<br />
=== AvPainter ===<br />
Sculpty previewer that allows you to preview with texture. Also allows you to paint directly on the surface to create texture maps. Support for layers. Full version allows texture maps to be saved as PSD and TGA.<br />
*'''Creator''': [[user:Pootle Trollop | Pootle Trollop]]<br />
*'''Link to get it''': [http://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=158462 Purchase from Xstreet] or [http://avpainter.osbyte.net/dl.php?name=demo&regcode=demo Download Demo]<br />
*'''Requires''': A PC running Windows XP or Vista, as well as [http://www.microsoft.com/downloads/details.aspx?familyid=0856eacb-4362-4b0d-8edd-aab15c5e04f5&displaylang=en Microsoft .NET Framework Version 2.0 Redistributable]. Includes XNA/DirectX component installer.<br />
<br />
=== Cel_Sculptpreview ===<br />
*'''Creator''': [[user:Cel Edman | Cel Edman]]<br />
*'''Link to get it''': [http://www.xs4all.nl/~elout/sculptie/ Download from website]<br />
*'''Requires''': [http://java.com/en/download/index.jsp Java Runtime Engine 1.6 or higher] installed on your system. This is a simple Sculpt previewer created in [http://processing.org/ Processing]. Downloads available for Windows, Mac OS X and Linux. Currenly not further developed, since Cel continues on developing Sculptypaint (Resident-made Sculpt Creation Tools) at the moment, that got this realtime previewer as well.<br />
<br />
=== A Hacky Sculpt Previewer ===<br />
*'''Creator''': [[user:Yumi Murakami | Yumi Murakami]]<br />
*'''Link to get it''': [http://www.bijodesign.com/sculpt/SculptPreview.html Web Start Launcher], [http://www.bijodesign.com/sculpt/SculptPreview.jar Executable JAR file], [[Hacky Sculpt Previewer | Source Code]] (Java SDK required to run from the source).<br />
*'''Requires''': [http://java.com/en/download/index.jsp Java Runtime Engine 1.6 or higher], [http://java.sun.com/products/java-media/3D/download.html Java 3d API] and any OS that will run them (Win and Linux are well covered, Mac is not). If installing or upgrading the JRE, be sure to do it before installing Java3d. The Web Start link above should be able to automatically install any needed components. Note that it will attempt to automatically redirect your browser to a download page, so if nothing happens when you click on it, please check your security settings will allow this.<br />
<br />
=== Sculptaire ===<br />
Open source sculpty previewer that also allows preview with texture.<br />
*'''Creator''': [[user:Flame Swenholt | Flame Swenholt]]<br />
*'''Link to get it''': [http://sourceforge.net/projects/sculptaire/ Download from website]<br />
*'''Requires''': Windows 2000 SP4, Windows XP SP2 or Windows Vista (NOT x64!), as well as [http://www.microsoft.com/downloads/details.aspx?familyid=0856eacb-4362-4b0d-8edd-aab15c5e04f5&displaylang=en Microsoft .NET Framework Version 2.0 Redistributable]<br />
<br />
=== SculptySpace ===<br />
Supports textured Sculpt preview with Second Life style texture parameters.<br />
*'''Creator''': [[user:Sculpty Carver | Sculpty Carver]]<br />
*'''Link to get it''': [http://www.sculptyspace.com/index.php?id=2 Download from website]<br />
*'''Requires''': Windows XP SP2 or Windows Vista, [http://www.microsoft.com/downloads/details.aspx?familyid=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en Microsoft Visual C++ 2005 SP1 Redistributable]<br />
<br />
=== SIEE(Sculptie Importer Exporter and Editor) ===<br />
*'''Creator''': [[user:Rex Cronon | Rex Cronon]]<br />
*'''Link to get it''': [http://www.elektralusion.com/siee_122809/ Run it from website]<br />
*'''Requires''': [http://java.com/en/download/index.jsp Java Runtime Engine 1.6 or higher] installed on your system. This is java applet. To run it you only need to have a browser that allows applets to run. It has many functions. I personally use it with ArtOfIllusions. I plan to have it allow the use of addons. If you have any questions, comments, or you find any bugs please send me an IM in world:) This program is free to use for a limited time. My only request is that you mention it:)<br/><br />
Thank you Eleanora Newell for hosting it:)<br />
<br />
=== XNA Sculptpreview ===<br />
*'''Creator''': [[user:Eddy Stryker | Eddy Stryker]]<br />
*'''Link to get it''': [[User:Eddy_Stryker/XNA_Sculptpreview | XNA Sculptpreview]]<br />
*'''Requires''': Windows XP SP2 or Windows Vista, along with the Microsoft XNA framework (see above link for details)<br />
*'''Derivatives''': [http://mailerdaemon.home.comcast.net/SculptedPreview.zip XNA SculptPreview] - Modified version to include LOD and a more sensible camera configuration (and a bunch of other changes under the hood).<br />
<br />
== In-world Preview Tools ==<br />
<br />
Tools that can be used to view in Second Life what a sculpt will look like before the texture is uploaded.<br />
<br />
=== Sculpt Preview using Parcel Media ===<br />
Tutorial on using the Parcel Media as a Sculpt Texture Preview. Example available at the in-world location listed below.<br />
*'''Website:''' [http://nandnerd.info/blog/2007/06/16/sculpty-media-video-url-previewer/ blog.nandnerd.info/...]<br />
*'''Forum Discussion:''' [http://forums-archive.secondlife.com/8/16/191214/1.html forums-archive.secondlife.com]<br />
*'''Author:''' [[User:nand Nerd | nand Nerd]]<br />
*'''In-World:''' [http://slurl.com/secondlife/Lasiocampa/133/209/57 Lasiocampa]<br />
*'''Requirements:''' Web hosting (free small image hosting at http://imageshack.us works without hassle)<br />
<br />
<br />
=== Texture Wizard (Commercial) ===<br />
Works using the media texture on your land (you must own or rent land to use it) using QuickTime, the way an in-game TV does. Saving a .bmp, .jpg or .psd file will automatically update the image in-game. You can see your changes live on a prim. Avoids uploads until you are done (you must still upload for a permanent version). Also works just as a regular texture previewer.<br />
*'''Website:''' [http://sl.infomyth.com/texturepreview/texturepreview.htm Infomyth.com]<br />
*'''In-World:''' [http://slurl.com/secondlife/Horowitz/164/20/21/ Horowitz]<br />
*'''Cost:''' L$399 (about $1.80 U.S.)<br />
*'''Operating Systems:''' Windows XP<br />
<br />
= Special purpose Sculpt Creation / Manipulation Tools =<br />
The tools listed here aren't fully-fledged 3d modelling programs &mdash; they are stand-alone tools for creating sculpt maps, usually in some limited way. As with the previewers above, consider them works in progress.<br />
<br />
On the other hand, if they do what you want, a lathe tool, for example, then they are much easier than buying, setting up, learning, and using a full 3D modeller.<br />
<br />
=== LandSculptor ===<br />
Makes a sculptie model of any region in SL. LandSculptor scans the sim region and creates a sculpt map texture you can use to make detailed models of your land. Rez the LandSculptor and start scanning and in about a minute, you'll be provided with a set of textures to make your own sculptie model.<br />
*'''Creator:'''[[User:Emma Nowhere | Emma Nowhere]]<br />
*'''Link to get it:'''http://www.nowherevirtual.com/landsculptor/<br />
*'''Requires:''' Web browser<br />
<br />
=== LD Sculpty Protect ===<br />
LD Sculpty Protect is a tool to protect sculpty textures in Second Life - that nobody can steal your hard work by simply making screenshots. It is optimized to manage multiple files at once. It is possible to use your own logo! See website for more information.<br />
*'''Creator''': [[user:Langweiliger Dreier | Langweilliger Dreier]]<br />
*'''Link to get it''': [https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=986734 https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=986734]<br />
*'''Requires''': Windows PC<br />
<br />
=== LD Sculpty Shrink ===<br />
LD Sculpty Shrink is a tool to decrease size of sculpties to any size - to make sculpted nano prims for example. It is optimized to manage multiple files. (LD Sculpty Protect is included in this tool). See website for more information.<br />
*'''Creator''': [[user:Langweiliger Dreier | Langweilliger Dreier]]<br />
*'''Link to get it''': [https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=987653 https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=987653]<br />
*'''Requires''': Windows PC<br />
<br />
=== Math Sculptor 1.0===<br />
*'''Creator''': [[user:Burhop Piccard | Burhop Piccard]]<br />
*'''Link to get it''': http://mark.burhop.net there is also a [[MathSculptor|MathSculptor]] wiki page.<br />
*'''Requires''': Windows XP or Vista. <br />
Math Sculptor is free application for creating and viewing sculpted primitives. It provides dynamic viewing and modification of sculpties. What differentiates this application is that it is build upon an extendible "addin" architecture. This allows others to easily create new algorithms that generate completely new types of sculpties. See http://mark.burhop.net for more information and sample sculpted primitives.<br />
<br />
=== PloppSL ===<br />
PloppSL allows you to create Sculpted Prims for Second Life by painting the front and back side of your model. Thus, texture and model are created in one step. You can create or use different textures for the front and backside of your model. You can also paint in your favored paint program, import the images into PloppSL by drag&drop and turn them into 3D models.<br />
*'''Creator:'''[[User:Imp Iwish | Imp Iwish]]<br />
*'''Link to get it:''' http://www.secondplopp.com/<br />
*'''Operating Systems:''' Windows, Mac OS<br />
<br />
'''Resources'''<br />
* [http://forums-archive.secondlife.com/8/c5/213219/1.html SL forum thread]<br />
<br />
=== ROKURO Sculpted Prim Maker ===<br />
<br />
*'''Creator:'''[[User:Yuzuru Jewell | Yuzuru Jewell]]<br />
*'''Link to get it:''' http://kanae.net/secondlife/<br />
*'''Requires:''' Windows<br />
<br />
Rokuro translates from Japanese as "lathe" and that's basically what this is: a standalone version of the lathe tool found in many 3d modeling programs that saves directly to sculpt maps. You draw a line in 2d by editing the various points and the program effectively spins that line around an axis to create the 3d object. Cylinders and polygonal prisms are both possible. Obviously limited to things you can create with this method so far, but easy for anyone to pick up and use and more features are still being added. Created by Yuzuru Jewell...arigato!<br />
<br />
'''Resources'''<br />
* [http://forums-archive.secondlife.com/8/98/184264/1.html sl forum thread]<br />
<br />
=== SculptCrafter ===<br />
Turns a linkset of spheres, cylinders and boxes into a sculptie and outputs it as a web link (giving a lego-like feel of moving parts of your sculpt around fast and getting quasi-immediate results), which you click and do 'save file' to get your sculpt map. The sculptie will look as much like the linkset within certain technical limits, such as the fact it does not support twist.<br />
*'''Creator:'''[[User:Contagious Republic | Contagious Republic]]<br />
*'''Link to get it:'''http://slurl.com/secondlife/3DBuildEasy/183/114/508<br />
*'''Requires:''' 86 prims at most, but typically 30 or so. Only during creation.<br />
<br />
You can fit 64 boxes into a sculptie; 28 for spheres; 85 for spikes, 23 cylinders of 8 sides, or mix thereof. As they can be placed independantly, you get the unprecedented ability to make several window frames per sculpt, for example.<br />
<br />
The SculptCrafter is 100% functional if you use it in its sandbox, including ability to output sculpt and use/sell them as normal, except for the "10 prims per sculpt" limit and the fact you must create in its sandbox. The demo also works anywhere the 1rst of each month, which is handy for contests, classes, and other events. The full version works anywhere, anytime.<br />
<br />
=== Sculpted Sim Terrain Mapper ===<br />
*'''Creator''': [[user:Anjin Meili | Anjin Meili]]<br />
*'''Link to get it''': [http://www.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=270738 Slexchange]<br />
*'''Requires''': Secondlife client and a object create and script permissions on a parcel. <br />
The Sculpted Sim Terrain Mapper creates a sculpted primitive map in 3D of any given Simulator. The tool simply is rezzed onto a parcel in the sim, and allowed to run. It will report back to the operator a URL to pickup a completed sculpted texture in TGA format. The data collected may also be used to create higher detail maps of the simulator, by using more prims, up to an 8x8 grid of sculpted prims to represent a simulator. Or just the default of one prim for the entire simulator. While the packaged tool is fee based, due to the costs of operating the backend... There is an open source version written entirely in LSL that requires minimal server side support. Contact Anjin Meili for a copy of the open source code. This tool is an example of using data to create sculpted primitives, with very little interaction. The source details using PPM as a description format within LSL for the sculpted texture map.<br />
<br />
=== Sculpt Studio ===<br />
A high-end in-world sculpting tool for beginners, advanced and professional Sculptors, that allows to apply SL building skills to sculpting.<br />
*'''Creator''': [[user:TheBlack Box | TheBlack Box]]<br />
*'''Link to get it''': [https://marketplace.secondlife.com/p/Sculpt-Studio-v60/356396 Second Life Marketplace]<br />
*'''Requires''': SL (34+ Prims) and Browser<br />
<br />
=== Sculpty Hider ===<br />
This is a FREE alternative to Langweiliger's LD Sculpty Protect with all of the benefits.<br />
*'''Creator''': [[user:Gorge Go | Gorge Go]]<br />
*'''Link to get it''': [http://caboosecode.webs.com/Programs/Sculpty_Hider.rar http://caboosecode.webs.com/Programs/Sculpty_Hider.rar]<br />
*'''Requires''': Windows PC<br />
<br />
=== sculpty.php ===<br />
A web-based series of tools, still rather primitive but constantly updating. Currently implemented are revolve and z,r revolve which both take a series of values (radii and z-pos,radii values respectively) and rotate them around the z-axis. Recently implemented a constant cross-section which extrudes a series of x,y values through the z-axis.<br />
*'''Creator:''' [[User:nand Nerd | nand Nerd]]<br />
*'''Link to get it:''' http://www.nandnerd.info/sculpt/<br />
*'''Requires:''' Browser<br />
<br />
=== SculptyPaint v.092===<br />
*'''Creator''': [[user:Cel Edman | Cel Edman]]<br />
*'''Link to get it''': [http://www.xs4all.nl/~elout/sculptpaint/ Download from website]<br />
*'''Requires''': [http://java.com/en/download/index.jsp Java Runtime Engine 1.6 or higher] installed on your system?! In case it wont work. <br />
Last update: march 10 - 2008. Realtime sculpt previewer. Drawing tool: manipulate the width, height and shape of the Sculpt. Edit RGB Layers, Flower, Stone, Stair and Point, Texturesketch and Morph Tool. Downloads available for Windows, Mac-OSX and Linux.<br />
<br />
=== SnurbO'Matic ===<br />
*'''Creator''': [[user:Anjin Meili | Anjin Meili]]<br />
*'''Link to get it''': [http://www.slexchange.com/modules.php?name=Marketplace&file=item&ItemID=273452 Slexchange]<br />
*'''Requires''': Secondlife client and a sandbox with at least 1100 primitives. <br />
SnurbO'Matic is an in world tool that allows editing and creation of sculpties. The system uses a molding method, allowing a mesh to be molded around other inworld objects. Objects must not be phantom. The mold may be modified using normal in world build tools. Each mesh node is visualized as a sphere, and can be moved as desired. Once finished, the mold is saved and a casting produced thru an automated web process. The user gets a URL when completed for a TGA file containing the texture. This can be further refined using off grid tools, or simply uploaded to Second Life as is. For new modelers, its easier to start with a close approximation of an object, rather then manipulating a sphere to the object they wish. For landscapers, the tool can produce organic, smooth, and unique rocks, logs, etc. Search for the group SculptO'Matic, or visit our sandbox and lab in Talakin.<br />
<br />
=== Sim Terrain Surveyor ===<br />
*'''Creator''': [[user:Glox Parisi | Glox Parisi]]<br />
*'''Link to get it''': [http://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1184678 SL-Exchange]<br />
*'''Requires''': Any graphics editor capable of portable pixmap files (*.ppm). <br />
Scans the sim elevation profile and chats the readings which you then convert into a sculpt map texture using GIMP, ACDSee or Photoshop or any other graphics editor that supports .ppm portable pixmap files.<br />
<br />
=== TATARA - Sculpted Prim Previewer and Editor ===<br />
TATARA displays both a sculpted prim and its texture.<br />
*'''Creator:'''[[User:Yuzuru Jewell | Yuzuru Jewell]]<br />
*'''Link to get it:'''http://kanae.net/secondlife/tatara.html<br />
*'''Requires:''' Windows<br />
<br />
A sculpted Prim can be edited in the five modes:ROKURO/TOKOROTEN/MAGE/WAPPA/TSUCHI.<br />
The five modes can be combined and used.<br />
Furthermore, TATARA can correct coordinates for every control point in the BITMAP and TSUCHI mode.<br />
Created by Yuzuru Jewell...arigato!<br />
<br />
=== Terrain Sculptor (Open Source) ===<br />
*'''Creator''': [[user:Cadroe Murphy | Cadroe Murphy]]<br />
*'''Link to get it''': [http://spinmass.blogspot.com/2007/08/terrain-sculptor-maps-sims-and-creates.html Blog]<br />
*'''Requires''': .NET 2.0<br />
Terrain Sculptor is a .NET application which uses a [http://www.libsecondlife.org/wiki/Main_Page libsecondlife] bot to retrieve the elevation data for a sim and generates a sculpty texture of the terrain. It also downloads the world map image from the web for use as a texture. The user can teleport to specific locations within sims and monitor the process through a graphical display. The operation usually takes a number of seconds after logging into a sim. Elevation data can be saved and loaded seperately. The application is relatively user-friendly but errors are not always handled informatively. The source code is open.<br />
<br />
=== TOKOROTEN(extruder)Sculpted Prim Maker ===<br />
This Program makes Sculpted Prim texture .tga file of the pushed-out object.<br />
*'''Creator:'''[[User:Yuzuru Jewell | Yuzuru Jewell]]<br />
*'''Link to get it:''' http://kanae.net/secondlife/tokoroten.html<br />
*'''Requires:''' Windows<br />
<br />
TOKOROTEN is Japanese jelly extruded to thin strips.<br />
An object will be pushed out if the form of the hole which you push out is made.<br />
You can twist or round an object. You draw a line in 2d by editing the various points and the program. Obviously limited to things you can create with this method so far, but easy for anyone to pick up and use and more features are still being added. Created by Resident Yuzuru Jewell...arigato!<br />
<br />
'''Resources'''<br />
* [http://forums-archive.secondlife.com/8/98/184264/1.html sl forum thread]<br />
<br />
= File Converters =<br />
These utilities are made to translate 3d files directly into sculpt maps, with varying degrees of sucess.<br />
<br />
=== 3dm2sculpt ===<br />
A command-line utility that reads an [[#3D_File_Formats | OpenNURBS]] .3dm file and generates a .tga sculpt map from it. Still in need of a lot of testing but potentially very useful for any program that supports this format.<br />
*'''Creator:''' [[User:Cindy Crabgrass | Cindy Crabgrass]]<br />
*'''Link to get it:''' [[3dm2sculpt|3dm2sculpt]]<br />
*'''Requires:''' Windows<br />
<br />
=== obj2sculpt ===<br />
A command-line utility that reads a Wavefront Style .obj file and generates a .tga sculpt texture from it. Still in need of a lot of testing but potentially very useful for any program that supports this format.<br />
*'''Creator:''' [[User:Cindy Crabgrass | Cindy Crabgrass]]<br />
*'''Link to get it:''' http://forums-archive.secondlife.com/8/e8/182763/1.html#post1505114 ''(dead link, attachment was not archived)''<br />
*'''Link on the TG forums:''' Nonexistent, can someone please fix this?<br />
*'''Requires:''' Windows<br />
<br />
=== raw2sculpt.html ===<br />
A client-side, pure JavaScript tool that converts [[Tips for Creating Heightfields and Details on Terrain RAW Files|RAW Terrain files]] to Sculpted Prim textures.<br />
*'''Creator:''' [[User:SignpostMarv Martin|SignpostMarv Martin]]<br />
*'''Link to get it:''' http://svc.sl.marvulous.co.uk/raw2sculpt.html<br />
*'''Requires:''' Firefox 3.6+ or any browser supporting file drag & drop, file reading & Canvas.<br />
<br />
=== Sculpty Maker ===<br />
Sculpty Maker is a free program for Windows PCs that allows you to create objects in zBrush and convert them to Second Life sculpted prims. It includes an in-world tool called Sculpty Rezzer that assembles the converted objects, and a plug-in for zBrush that allows you to export sculptmaps directly from zBrush. Please direct all support questions to Vlad Bjornson.<br />
*'''Creator:''' 2k Suisei<br />
*'''Link to get it:''' http://www.shiny-life.com/sculpty-maker/<br />
*'''Requires:''' Windows, zBrush<br />
<br />
= Importers =<br />
These utilities assist in bringing sculpted creations in to the Second Life world:<br />
<br />
=== GridImageUpload ===<br />
A simple graphical user interface to upload textures to the grid. It will show you the compressed texture size before uploading and allow you to upload lossless images, perfect for 64x64 or smaller sculpt maps.<br />
*'''Creator:''' [[User:Eddy Stryker | Eddy Stryker]]<br />
*'''Link to get it:''' [[GridImageUpload]]<br />
*'''Requires:''' Windows, Linux, OSX<br />
<br />
=== importprimscript ===<br />
A command-line utility to batch upload an entire folder output from Qarl's Advanced Maya Sculpt Exporter in to Second Life and rez the scene as a full permission linkset. The sculpt maps are uploaded as lossless images and the textures are uploaded with the normal compression settings.<br />
*'''Creator:''' [[User:Eddy Stryker | Eddy Stryker]]<br />
*'''Link to get it:''' [[Importprimscript|Importprimscript]]<br />
*'''Requires:''' Windows, Linux, OSX<br />
<br />
'''NOTE:''' Although the main utility is command-line, for using the app on Windows there is a GUI provided by Johan Durant on the importprimscript page.<br />
<br />
=== redcap ===<br />
redcap is an open-source command line utility for uploading images to Second Life.<br />
*'''Creator:''' [[User:Adam Marker | Adam Marker]]<br />
*'''Link to get it:''' [http://adammarker.org/redcap/ redcap] ([http://github.com/slothbear/redcap source])<br />
*'''Requires:''' Ruby, ImageMagick<br />
<br />
<br />
<br />
<br />
[[Category: Sculpted Prims]]</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=Talk:LlSitTarget&diff=466163Talk:LlSitTarget2009-08-19T15:11:42Z<p>Tonya Souther: /* UpdateSitTarget changes? */ seconded</p>
<hr />
<div>== Unsitting on wrong side or camera rotation ==<br />
<br />
Hi, i am getting frustrated with this. I create a board and set the sit target with<br />
llSitTarget(<0.4, 0.0, 0.0>, ZERO_ROTATION);<br />
and an animation which for "standing". So while the person technical sits, she stands in front of the board. <br />
But I have a problem with that: If the board stand freely, the person unsits right through it towards the other side. I can put the board with the back facing a large wall. In the case the unsitting is correctly in front of it. But on sit down the camera rotates, so that it is behind the avatar again; on the other side of the wall.<br />
<br />
If anyone has an idea how to fix, please tell me (even if it is just an idea where to look for more information). --[[User:Maike Short|Maike Short]] 12:41, 24 February 2008 (PST)<br />
<br />
:You could position the camera with the {{LSLGC|Camera}} functions. -- [[User:Strife Onizuka|Strife Onizuka]] 04:46, 25 February 2008 (PST)<br />
<br />
==Optimization==<br />
<pre><br />
list GetSitTarget(integer prim, key av)<br />
{//WARNING: llGetObjectDetails can introduce an error that goes as far as the 5th decimal place.<br />
vector tp = llGetAgentSize(av);<br />
if(tp)<br />
{<br />
if(prim == LINK_THIS)//llGetLinkKey doesn't like LINK_THIS<br />
prim = llGetLinkNumber();<br />
<br />
list details = OBJECT_POS + (list)OBJECT_ROT;<br />
rotation f = llList2Rot(details = (llGetObjectDetails(llGetLinkKey(prim), details) + llGetObjectDetails(av, details)), 1);<br />
<br />
return [(llRot2Up(f = (llList2Rot(details, 3) / f)) * tp.z * 0.02638) + ((llList2Vector(details, 2) - llList2Vector(details, 0)) / f) - <0.0, 0.0, 0.4>, f];<br />
}<br />
return [];<br />
}//Written by Strife Onizuka<br />
</pre><br />
<br />
==Using llSetLinkPrimitiveParams for skydiving: why limited to 5m in a linked set?==<br />
llSetLinkPrimitiveParams can be used as a handy tool to adjust an avatar's position and rotation.<br />
This works perfectly when the object consists of 1 prim, with a range for setting the avatar position away to 500m easily!<br />
When there are more prims linked, this offset seems to be limited to 5m (measured with llVecDist). This is an awfull sideeffect!<br />
<br />
Put this next script inside a prim and sit on the prim, it will bring you to 1000.0 higher then the prim.<br />
Next link this prim to another prim and try again. You will notice you are limited to 5m. My Question: why is this limited?<br />
<pre><br />
// by Randur Source<br />
<br />
integer heightcnt = 0;<br />
list heights = [0.0, 1.0, 5.0, 6.0, 10.0, 100.0, 300.0, 500.0, 800.0, 1000.0];<br />
<br />
default<br />
{<br />
state_entry()<br />
{<br />
llSitTarget(ZERO_VECTOR,ZERO_ROTATION); // Clear the current sittarget for a clear test<br />
llSetRot(ZERO_ROTATION); // set the prim to no rotation, for simple z axis movement<br />
}<br />
<br />
changed(integer change)<br />
{<br />
if (change & CHANGED_LINK) // detect linked prims and avatars<br />
{<br />
integer primnum = llGetNumberOfPrims(); // the avatar is the last linked prim<br />
if (primnum <= 1) // stop if there is only 1 prim<br />
return;<br />
<br />
key avatar = llGetLinkKey(primnum);<br />
if (llGetAgentSize(avatar) == ZERO_VECTOR) // stop if this is not an avatar<br />
return;<br />
<br />
// loop through the list of test heights:<br />
for (heightcnt = 0; heightcnt < llGetListLength(heights); heightcnt++)<br />
{<br />
float height = llList2Float(heights,heightcnt);<br />
llSetLinkPrimitiveParams(primnum,[PRIM_POSITION,<0.0,0.0,height>]); // set this to the wanted height using a vector z axis<br />
<br />
vector avatarpos = llList2Vector(llGetObjectDetails(avatar,[OBJECT_POS]),0); // detect the avatar position within the sim<br />
float distance = llVecDist(llGetPos(),avatarpos);<br />
llOwnerSay("Attempt to move " + llKey2Name(llGetLinkKey(primnum)) + " to " + (string)height + "m high resulting to " + (string)distance + "m");<br />
<br />
llSleep(1.0);<br />
}<br />
llUnSit(avatar);<br />
}<br />
}<br />
}<br />
</pre><br />
==UpdateSitTarget changes?==<br />
I recently worked on a project where I used a version of this function, and it appears that it is a little off. A couple of things I noted: the Z-offset of the sit target is 0.35, not 0.4, and the avatar size doesn't seem to affect this position at all. When I used this function verbatim, I noticed discrepancies between the actual sit target and the set position call. When I changed the script as noted, I got a perfect match. Has the handling of the sit target been changed since this was written? [[User:Talarus Luan|Talarus Luan]] 22:57, 1 July 2009 (UTC)<br />
:Seconded. I wish I'd looked at this discussion before spending an hour on trying to figure out how the code actually behaved. -- [[User:Tonya Souther|Tonya Souther]] 15:11, 19 August 2009 (UTC)</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=LSL3&diff=450953LSL32009-08-06T14:56:03Z<p>Tonya Souther: /* Functions */</p>
<hr />
<div>{{RightToc}}<br />
== Purpose ==<br />
The purpose of the LSL3 project is to design a new programing language that would replace LSL2 in Second Life.<br />
<br />
== Design Ideals ==<br />
*It should be designed to enable expression and not hinder expression with complex or over burdensome syntax requirements.<br />
*C style syntax and order of operations<br />
*Type safety<br />
*Strongly Typed<br />
<br />
== Goal ==<br />
* Address the shortcomings of LSL2 and add new functionality while limiting the increase of language complexity.<br />
* Design LSL3 with Hierarchical Linking in mind {{Jira|MISC-2237}}<br />
<br />
== Proposed Changes for LSL2 ==<br />
Here are some proposed changes to LSL2. Please add new changes, if they cannot be summed up in a single sentence please create a subpage to this article and put a link in the appropriate section. <br />
<br />
=== Major changes ===<br />
* Object model<br />
* Get ride of get and set functions, use getters and setters instead where possible (syntax sugar).<br />
* Persistent storage/memory<br />
<br />
=== Syntax ===<br />
* Fix quaternion ordering<br />
* Object model for base types<br />
* Array indexer<br />
* continue and break keywords.<br />
* switch statement.<br />
<br />
=== Types ===<br />
* User defined class & structures<br />
** Duck Typing (LinFu?)<br />
** Anonymous classes?<br />
* bool type<br />
* pointers<br />
* Remove restriction on lists containing lists<br />
<br />
=== Functions ===<br />
* Organized into static classes?<br />
* Or keep the namespace flat to keep the syntax simple.<br />
* Add ability to write notecards<br />
<br />
=== States & Events ===<br />
* State variables.<br />
* User defined events that can be triggered by external scripts.<br />
<br />
=== Libraries ===<br />
* Script libraries that can be sold and passed around.<br />
* Natural syntax which can be used instead of link_message<br />
<br />
== Flaws with LSL2 ==<br />
Here is a list of flaws with LSL2 that should be fixed.<br />
=== Combining Quaternions ===<br />
* See {{JIRA|SVC-1047}} for a full description of this.<br />
<br />
=== Evaluation order ===<br />
* Given the code <code>f(a) + g(a)</code>, currently <code>g(a)</code> gets executed before <code>f(a)</code>.<br />
** Changing this so <code>f(a)</code> gets executed first should improve performance on Mono.<br />
<br />
===Comparisons of lists=== <br />
*Only length is compared.<br />
*The result of a list equality is the difference of the lengths.<br />
<br />
==='if else' syntax===<br />
* <code>if([1])</code> evaluates to false.<br />
<br />
=== [[PRIM_ROTATION]] ===<br />
* For child prims it requires dividing out the root prims rotation.<br />
<br />
=== [[llInsertString]] ===<br />
* Does not support negative indexes.<br />
<br />
=== {{LSLGC|Detected|llDetected*}} Functions ===<br />
* Do not support negative indexes.<br />
<br />
== Resources ==<br />
*{{Jira|SVC-1657}}</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=LSL3&diff=450943LSL32009-08-06T14:53:34Z<p>Tonya Souther: /* Types */ add lists of lists</p>
<hr />
<div>{{RightToc}}<br />
== Purpose ==<br />
The purpose of the LSL3 project is to design a new programing language that would replace LSL2 in Second Life.<br />
<br />
== Design Ideals ==<br />
*It should be designed to enable expression and not hinder expression with complex or over burdensome syntax requirements.<br />
*C style syntax and order of operations<br />
*Type safety<br />
*Strongly Typed<br />
<br />
== Goal ==<br />
* Address the shortcomings of LSL2 and add new functionality while limiting the increase of language complexity.<br />
* Design LSL3 with Hierarchical Linking in mind {{Jira|MISC-2237}}<br />
<br />
== Proposed Changes for LSL2 ==<br />
Here are some proposed changes to LSL2. Please add new changes, if they cannot be summed up in a single sentence please create a subpage to this article and put a link in the appropriate section. <br />
<br />
=== Major changes ===<br />
* Object model<br />
* Get ride of get and set functions, use getters and setters instead where possible (syntax sugar).<br />
* Persistent storage/memory<br />
<br />
=== Syntax ===<br />
* Fix quaternion ordering<br />
* Object model for base types<br />
* Array indexer<br />
* continue and break keywords.<br />
* switch statement.<br />
<br />
=== Types ===<br />
* User defined class & structures<br />
** Duck Typing (LinFu?)<br />
** Anonymous classes?<br />
* bool type<br />
* pointers<br />
* Remove restriction on lists containing lists<br />
<br />
=== Functions ===<br />
* Organized into static classes?<br />
* Or keep the namespace flat to keep the syntax simple.<br />
<br />
=== States & Events ===<br />
* State variables.<br />
* User defined events that can be triggered by external scripts.<br />
<br />
=== Libraries ===<br />
* Script libraries that can be sold and passed around.<br />
* Natural syntax which can be used instead of link_message<br />
<br />
== Flaws with LSL2 ==<br />
Here is a list of flaws with LSL2 that should be fixed.<br />
=== Combining Quaternions ===<br />
* See {{JIRA|SVC-1047}} for a full description of this.<br />
<br />
=== Evaluation order ===<br />
* Given the code <code>f(a) + g(a)</code>, currently <code>g(a)</code> gets executed before <code>f(a)</code>.<br />
** Changing this so <code>f(a)</code> gets executed first should improve performance on Mono.<br />
<br />
===Comparisons of lists=== <br />
*Only length is compared.<br />
*The result of a list equality is the difference of the lengths.<br />
<br />
==='if else' syntax===<br />
* <code>if([1])</code> evaluates to false.<br />
<br />
=== [[PRIM_ROTATION]] ===<br />
* For child prims it requires dividing out the root prims rotation.<br />
<br />
=== [[llInsertString]] ===<br />
* Does not support negative indexes.<br />
<br />
=== {{LSLGC|Detected|llDetected*}} Functions ===<br />
* Do not support negative indexes.<br />
<br />
== Resources ==<br />
*{{Jira|SVC-1657}}</div>Tonya Southerhttps://wiki.secondlife.com/w/index.php?title=LlSetAlpha&diff=447243LlSetAlpha2009-08-03T14:47:37Z<p>Tonya Souther: fix bug in cloak function; would not fully cloak object before (left alpha at 0.1)</p>
<hr />
<div>{{LSL_Function/face|face}} {{LSL_Function/alpha|alpha}} {{LSL_Function<br />
|func_id=51|func_sleep=0.0|func_energy=10.0<br />
|func=llSetAlpha|sort=SetAlpha<br />
|p1_type=float|p1_name=alpha<br />
|p2_type=integer|p2_name=face<br />
|func_footnote<br />
|func_desc=Sets the '''alpha''' on '''face'''<br />
|return_text<br />
|spec<br />
|caveats<br />
|constants<br />
|examples=<lsl><br />
float cloakSpeed = .1;<br />
<br />
default<br />
{<br />
touch_start(integer total_number)<br />
{<br />
integer x;<br />
float xf;<br />
for (x=9; x>=0; x--)<br />
{<br />
xf = x * .1;<br />
llSleep(cloakSpeed);<br />
llSetAlpha(xf,ALL_SIDES); <br />
}<br />
state cloaked;<br />
}<br />
}<br />
<br />
state cloaked<br />
{<br />
touch_start(integer total_number)<br />
{<br />
integer x;<br />
float xf;<br />
for (x=1; x<11; x++)<br />
{<br />
xf = x * .1;<br />
llSleep(cloakSpeed);<br />
llSetAlpha(xf,ALL_SIDES); <br />
}<br />
state default;<br />
}<br />
}<br />
</lsl><br />
|helpers<br />
|also_functions=<br />
{{LSL DefineRow||[[llGetAlpha]]|Gets the prim's alpha}}<br />
{{LSL DefineRow||[[llGetColor]]|Gets the prim's color}}<br />
{{LSL DefineRow||[[llSetColor]]|Sets the prim's color}}<br />
{{LSL DefineRow||[[llSetLinkColor]]|Sets link's color}}<br />
{{LSL DefineRow||[[llSetLinkAlpha]]|Sets link's alpha}}<br />
|also_tests<br />
|also_events=<br />
{{LSL DefineRow||[[changed]]|[[CHANGED_COLOR]]}}<br />
|also_articles<br />
|notes=In practical terms, "alpha" means "transparency" or "visibility".<br />
<br />
To be clear, llSetAlpha will only affect the prim that the script it is in. It will not affect any linked prims. To set the alpha state for those, use [[llSetLinkAlpha]]<br />
|deprecated<br />
|cat1<br />
|cat2<br />
|cat3<br />
|cat4<br />
}}</div>Tonya Souther