Difference between revisions of "Talk:LSL Protocol/RestrainedLoveAPI"

From Second Life Wiki
Jump to navigation Jump to search
Line 54: Line 54:
:Oh it looks like the wiki has been completed now. Thanks Marine. But, may I ask, do @acceptpermission & @denypermission really work for animation permission now? Your blog says it is only for attachements and controls! --[[User:Satomi Ahn|Satomi Ahn]] 11:52, 31 March 2009 (UTC)
:Oh it looks like the wiki has been completed now. Thanks Marine. But, may I ask, do @acceptpermission & @denypermission really work for animation permission now? Your blog says it is only for attachements and controls! --[[User:Satomi Ahn|Satomi Ahn]] 11:52, 31 March 2009 (UTC)


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


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

Revision as of 08:13, 4 April 2009

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)

@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)

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)