Talk:LSL Protocol/RestrainedLoveAPI

From Second Life Wiki
Jump to navigation Jump to search

Question regarding @remoutfit and teens

Thank you for putting up that API.

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

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

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

How to use for bondage furniture?

Hi Marine,

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

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

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

Looking forward to your answer. Ciao, Tam


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


Meaningless or App-Defined Rules

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

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

--Galatea Gynoid 12:07, 17 August 2008 (PDT)


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

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

--Marine Kelley 01:47, 18 August 2008 (PDT)

@sendchannel needs a bit of clarification

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

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

Marine Kelley 15:16, 4 April 2009 (UTC)

@acceptpermission & @denypermission

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

By the way, if @acceptpermission would also affect animation permission, that would be awesome! --Satomi Ahn 16:42, 19 February 2009 (UTC)

Oh it looks like the wiki has been completed now. Thanks Marine. But, may I ask, do @acceptpermission & @denypermission really work for animation permission now? Your blog says it is only for attachements and controls! --Satomi Ahn 11:52, 31 March 2009 (UTC)
Yes if I remember correctly it only accepts attach and controls permissions... I am really torn on the animation permission because it is automatically accepted if you're sitting on the prim that contains the animation (like furnitures), or wearing it (like restraints) but it proves to be a vulnerability for griefers to exploit. Granted, griefing with weird animations is lame (as is griefing in general), but it is griefing nonetheless. I should see how to accept animation permission requests from prims you are sitting on, regardless of whether they contain the animation or not. That should help for rezzable poseballs at least. Marine Kelley 15:13, 4 April 2009 (UTC)
Is there a way to start an animation which is not in the prim? In case it is possible it would be interesting to extend the relay protocol to allow this. But I thought this was impossible? Another idea is to explicitly specify the key of the prim that should be allowed to start an animation: @acceptpermission:7adf6218-ab26-8566-8387-660133840794=add. I am not sure if the viewer has this information in the permission query function. The scenario I have in mind is a Star Trek like force-field cell door that will give an electroshock on touch, assuming that the cell has an active relay session. Something else to keep in mind is that there is a pyramid scheme vampire game out there which sees accepting animation permission as accepting to be added to the database. --Maike Short 18:54, 4 April 2009 (UTC)
Eh, you actually wrote this, on the wiki: "Force the viewer to automatically accept attach and 'animate' permission requests : @acceptpermission=<rem/add> ". So I guess this is an error. By the way, Kitty might have pointed this to you, but there is actually a way to to get animation permissions by mean of RLV commands, exploiting a loophole in the logic you use for @acceptpermission. Basically, if this behavior is enabled, if you request permission to animate along with either permission to attach or permission to take controls, then you are granted both. --Satomi Ahn 20:35, 14 April 2009 (UTC)

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

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

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

--Satomi Ahn 23:52, 19 February 2009 (UTC)


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

Marine Kelley 15:09, 4 April 2009 (UTC)


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

--Satomi Ahn 09:31, 27 July 2009 (UTC)

Third party extension @putinv and the SL permission system

In my opinion the SL permission system has a serious) flaw. Objects owned by the land owner do have special rights without a permission dialog:

  • manage the ban list
  • change the media settings (can be used to get the ip-address of visitors)
  • teraform (can be used to destroy the landscape and return rezzed objects to the lost and found folder, thous destroying a lovely place)

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

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

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

Protecting attachments against detach

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

My question is: Would it be possible to include commands looking something like this?

  • Allow/prevent wearing attachments : @addattach[:<attachpt>]=<y/n>

Where attachpt is : 

chest|skull|left shoulder|right shoulder|left hand|right hand|left foot|right foot|spine|
pelvis|mouth|chin|left ear|right ear|left eyeball|right eyeball|nose|r upper arm|r forearm|
l upper arm|l forearm|right hip|r upper leg|r lower leg|left hip|l upper leg|l lower leg|stomach|left pec|
right pec|center 2|top right|top|top left|center|bottom left|bottom|bottom right
  • Allow/prevent removing attachments : @remattach[:<attachpt>]=<y/n>

Where attachpt is : 

chest|skull|left shoulder|right shoulder|left hand|right hand|left foot|right foot|spine|
pelvis|mouth|chin|left ear|right ear|left eyeball|right eyeball|nose|r upper arm|r forearm|
l upper arm|l forearm|right hip|r upper leg|r lower leg|left hip|l upper leg|l lower leg|stomach|left pec|
right pec|center 2|top right|top|top left|center|bottom left|bottom|bottom right

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

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

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

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

Version Changelog

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

feature suggestion: forcechat and forceIM

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

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

--TigroSpottystripes Katsu 16:24, 19 July 2009 (UTC)


force chat level (whisper, talk or shout)

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

Feature Suggestion: No-Fly/Fly zones

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

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

Feature sugestion: @Forcefly

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

Feature suggestion: @Forcepresskeys

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

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


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

Feature suggestion: @allowpay

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

Feature Suggestion: force paint

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

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

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


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

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

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


--TigroSpottystripes Katsu 05:51, 8 August 2009 (UTC)

Curious behavior with exceptions and @sendim/@recvim

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

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

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

Feature Suggestion: @logout=force

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

@clear, detachments and locked status

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

Moderate rewrite of Architecture section

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

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


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

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

discription:

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

The list of 0s and 1s corresponds to :

none,chest,skull,left shoulder,right shoulder,left hand,right hand,left foot,right foot,spine, pelvis,mouth,chin,left ear,right ear,left eyeball,right eyeball,nose,r upper arm,r forearm, l upper arm,l forearm,right hip,r upper leg,r lower leg,left hip,l upper leg,l lower leg,stomach,left pec, right pec,center 2,top right,top,top left,center,bottom left,bottom,bottom right


in that order.

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


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

Misty Wulluf 12:37, 17 February 2010 (UTC)

Possible bug with respect to setdebug for scenegamma and renderresolutiondivisor

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

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

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

--Chloe1982 Constantine 21:06, 23 February 2010 (UTC)

Feature suggestion: @emailsnapshot:<emailaddr>=force

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

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

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


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

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

Although it would need to be limited to something reasonable.

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

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

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

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

Edit: Hmm, actually there are further privacy concerns with this idea, as much as I would like it, it also would expose the email address you registered with (and that is not visible otherwise). This seems like an unacceptable breech to me. I do wish there were some other way to get this sort of feature.

Winter Seale 00:08, 11 March 2010 (UTC)

there are probably some services out there that would allow anonymous forwarding of emailed pictures... --TigroSpottystripes Katsu 15:39, 15 April 2010 (UTC)
Even if not annonymous pic email fwdings, at least annonymous pic posting by email. --TigroSpottystripes Katsu 02:16, 16 May 2010 (UTC)

Feat Request: do NOT autocripple wireframe mode

if there really is need to cripple wireframe mode, add a command to explicitly do it, do NOT automaticly cripple it --TigroSpottystripes Katsu 15:37, 15 April 2010 (UTC)

Feature improvement: llGiveInventoryList() to subfolders

We should be able to send folders into #RLV subfolders to prevent cluttering of the #RLV root. For example a creator of traps could create a folder in #RLV/ and put all their traps' and toys' shared items into that subfolder. Imagine two RLV builders, one called "Trapmaker" the other "Transformer". The #RLV layout could look like this: 

#RLV
|-+~Trapmaker
| |-+Plant Trap
| | |--Item 1
| |  --Item 2
| |-+Bondage Trap
| | |--Item 1
| |  --Item 2
|  -+Cage Trap
|   |--Item 1
|    --Item 2
 -+~Transformer
  |-+Animal
  | |--Item 1
  |  --Item 2
  |-+Plant
  | |--Item 1
  |  --Item 2
   -+Rock
    |--Item 1
     --Item 2

And for new traps / transformation toys they could issue llGiveInventoryList(avatar,"#RLV/~Trapmaker/Bear Trap",["Item 1","Item 2"]); so the new items go under the respective subfolder. --Toy Wylie 13:32, 5 July 2010 (UTC)

Second that --Liace Parx 15:42, 5 July 2010 (UTC)
Third that, Needs it, and can come in handy sorting out inventory's rlv folder with folders like ~Clothes and ~avatars --Vixen Triellis 15:47, 5 July 2010 (UTC)
This would be a big help for builders and users alike. Thanks!Phantasi Firehawk 15:57, 5 July 2010 (UTC)
Definitely has my support. I can imagine the list of entries starting with tildes easily exceeding folders I've created myself - it already is almost 40% of the list. This would help reduce clutter a great deal, as well as giving you some idea of what the source of a given subfolder was - another handy benefit. --Tallinu Skytower 12:23, 7 July 2010 (UTC)

Error in Documentation of "@notify"

I don't presume to know much about how RLV works, but I believe I've found a slight error in the documentation of "@notify". It states that for folder-specific inventory offer notifications, you should include the folder path.

In the last sentence of "Start/stop notifications on a private channel" it reads 'issue a "@notify:2222;accepted_in_rlv inv_offer #RLV/~MyCuffs=add" command.' When I did this, the command would fail, but changing the command to "@notify:2222;accepted_in_rlv inv_offer=add" returns "/accepted_in_rlv inv_offer #RLV/~MyCuffs".

Just thought you'd like to know, this was a bit frustrating before I figured it out.

Rev Eponym 22:07, 2 February 2011 (PST)

Suggestion: better handling multiple layers and attachments

(here: some thoughts I have been toying with for some time now, which I believe should deserve some attention from whoever it may concern ;-).)

For almost one year, the 2.x generation of SL viewers has had the ability to stack several wearables and attachments on one spot. Sadly RLV has next to nothing to handle this new potential: the only new commands are the @attach[this][all]over series, handling the "how to add stuff" part.

We still miss the "how to selectively remove stuff" and "how to selectively lock stuff" parts (when that stuff is not necessarily set up in #RLV folders).

On the "how to selectively remove stuff" side, a few weeks ago, I have been toying with possible extensions. So far I implemented and tried the following ideas:

  1. a new debug setting that changes the behavior of @remoutfit:<layer>=force to only strip the topmost item on a clothing layer, making it possible again to peel one's outfit off piece by piece, even if several items are worn on one spot. This change is easy, straightforward, and directly compatible with close to every existing in-world script (read: you should seriously consider adding this very quickly!).
  2. 2 new commands (which I called @getworn=<channel> and @remworn:<name>=force), which returns the list of all attachment spots and clothing layer spots where something is being worn, along with indexes for each item being worn on these spots. (ok, I know, it's not very readable ;-). Here is an example: "underpants.1,undershirt.1,undershirt.2,pants.1,chest.1,chest.2", for somebody wearing items on underpants, undershirt, pants and chest, having 2 items on undershirt and two on chest).


Note that I list worn items (one list item per worn item), and not spots along with the number items worn on the spot. The reason of this choice is that I think that those list items are actually placeholders for better names the user would be able to specify (the same way the user is currently able to specify names for shared folders). Ideally, the example list should become for instance: "thong,bra,blouse,jeans,collar,handbag".

Aside from making it possible to handle each worn item separately, such a command brings new possibilities which did not exist with the current system, where only the following is possible:

  • either use @getoutfit and @getattach (and then @remoutfit and @remattach): 2 separate commands, and no visibility as to what you are currently stripping (and also no fine granularity in the case of multi-attachments/wearables)
  • or use shared folders with @getinvworn (and then @detach[all]:<foldername>=force), which requires complicated scripting to recursively browse subfolders. Also this requires that the target agent set up her inventory beforehand in a compatible way.

The @getworn/@remworn commands I propose adress all these issues:

  • only one command lists everything worn
  • each item can be removed separately
  • it is possible to setup custom names to facilitate the use
  • it will still work if no custom name is set (as names will default to <spot_name>.<stack_level>)
  • no complicated browsing: easy scripting, easy global view for the menu user

To make it even better, this could work well combined with RLVa-style composite folders: for each worn composite folder, list the composite as one worn item and hide all the actual items that are part of the composite (knowing that a blouse is made of a texture layer, prim cuffs and a prim collar is irrelevant to roleplay!).

As for the "how to lock stuff" part, well, the same naming scheme can of course be use. The syntax @remworn:<name>=n looks quite obvious. (as for preventing adding stuff relatively to one label name, it would not make much sense, so @addattach:<attachpt>=n and @addoutfit:<layer>=n could still be used)

Please comment!

--Satomi Ahn 05:44, 14 February 2011 (PST)

Suggestions: Camera settings

I am working on a game in SL and would very much enjoy if there was a function that could force an avatar out of mouselook (Currently with LSL you can only force INTO mouselook). And also a function to allow you to change the zoom-settings would be incredibly useful for me. (The ones currently controlled with ctrl+8/9/0 or through the edit menu). I hope this is doable.

--Jasdac Stockholm 05:07, 18 February 2011 (PST)

Suggestion: exception to @shownames

I would love to be able to add exceptions to @shownames, only the names in chat would already be very nice. Just wanted to let you know in case you're a bit bored and missing new suggestions ;)

Elena Bouscario 08:31, 6 March 2011 (PST)

Suggestion: RLV as a Viewer 2 plugin

I have always used 3rd party viewers for the ability to use RLV, however, there are now no RLV enabled viewers that do not crash within one minute of login for me. I resisted Viewer 2 until no RLV enabled viewers will now run for me. I would like to put out the suggestion/request that a plugin that provides the RLV enhancement to Viewer 2. Caitlin Loxingly 15:16, 17 April 2011 (PDT)

Feature Suggestion: Range sensitive exceptions to listening, seeing emotes and IMs

As viewers know the locations nearby agents (and some 3rd party viewers surface this information in Radar features) could we have RLV features that use this information also? Features that I think could be useful:

  • Partially deafen someone so that they can only here people talking within 10m (whispering within 5m, and shouting within 50m). Possibly implement this as a variable range so the RLV device chooses how close the sub has to be before being able to hear.
  • As above but for emotes.
  • Range sensitive IM blocking so that the sub cannot send or receive IMs from people within chat range (the sub should talk to people rather uses IMs for people nearby). But allow exceptions to this rule.

These features can be done within LSL scripts but require a fair bit of coding, and in the case of IM limiting - sensors on a fairly fast repeat rate, using information already known to the viewer would be a lot friendlier on sim performance.

Helena Lycia 00:14, 11 May 2011 (PDT)

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Talk:LSL_Protocol/RestrainedLoveAPI&oldid=1143359"