Talk:LSL Protocol/RestrainedLoveAPI

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)