Cool VL Viewer forum

View unanswered posts | View active topics It is currently 2024-03-28 23:22:52



Reply to topic  [ 11 posts ]  Go to page 1, 2  Next
RestrainedLove commands black-listing 
Author Message

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
For a very long time now (years !), this is a feature I advocated for... And I got tired to wait for it to get implemented by Marine and to have, in the mean time, to compile personal builds of the Cool VL Viewer with blacklisting enabled (since there are some RestrainedLove commands that are just unacceptable for a true role-player like me). So, here it is for everyone to enjoy (and I hope, for Marine and RLVa folks to inspire themselves from it).

Starting with Cool VL Viewer v1.26.0.28 and v1.26.2.6, you can blacklist RestrainedLove commands with the exception of information commands and a few management commands (none of the @get* and @version* commands can be blacklisted, neither any of @clear, @notify, @detachme, @findfolder, @setrot, @adjustheight, @emote).

Blacklisting is done by listing the commands (as a comma-separated list) in the RestrainedLoveBlacklist variable. Note however, that this variable is only read when the viewer is started (so that one can't cheat by adding a command to the blacklist and see it ignored during an ongoing session). Also since some commands have a different effect depending on whether you use them with a "add"/"rem" parameter or with a "force" parameter, the latter are distinguished in the black list by adding "%f" to their "behaviour" name (i.e., you use "behav" in the variable to black-list @behav=add, and "behav%f" to blacklist @behav=force). So, for example, to blacklist @*im*, @setdebug=add and @setdebug_*=force commands, you set the RestrainedLoveBlacklist variable to "sendim,sendim_sec,sendimto,startim,startimto,recvim,recvim_sec,recvimfrom,setdebug,setdebug_%f".

Since it would be unpractical for the average, non-geeky user to set this variable manually, the Cool VL Viewer provides an easier way to set it.

For a start, I defined three basic profiles as follow (with the explanations that you will also find as tool tips for the corresponding radio buttons in the preferences floater):
  • BDSM Persona-Player: Persona-players are people who consider they make one with their avatar (their avatar is bearing their own persona, even if they don't share the same appearance or even gender). For them, IC (In Character) and OOC (Out Of Character) do not really mean anything (they are both IC and OOC at the same time when they play). They enjoy being restricted in the same way as their avatar and even further. RestrainedLove was primarily designed for persona-players. With this setting checked, no RestrainedLove command will be blacklisted.
  • BDSM Role-Player: Role-players are people who consider that, while their avatar may share some of their own traits, it is just a character (like the character in a novel) that they use to play a role. For them, IC (In Character) and OOC (Out Of Character) are two, entirely different things just like the writer of the novel (their OOC self), and a character in the novel (their IC self). They do not want to be restricted as a player (no OOC restrictions), but enjoy seeing their avatar restricted as a part of and as an enhancement to the role-play.
  • Non-BDSM: If you are not into BDSM and yet wish to benefit from some features RestrainedLove can offer to you, such as allowing scripts to change what your avatar is wearing, or to redirect your chat (used by emoters), or to TP you automatically (used by teleporting gates), but don't wish to get restricted in what you can do in any way, then this profile is for you !

And here is how it shows in the "Cool features" tab, "RetrainedLove" sub-tab of the "Preferences" floater:
Image

Then, if the black lists defined for the above profiles still don't suit you, you may choose to press the "Custom" button, that opens the following floater:
Image
As you can see, the commands are actually regrouped in categories that should hopefully prove clear and easy to understand even to the newbies. For the geeky folks among you, hovering the mouse cursor on the check boxes also pops up a tool tip containing all the @commands that are associated with the corresponding category.

Now, some scripters among you could start yelling at me for implementing stuff that breaks their RestrainedLove scripts. Well, as a scripter myself, and a maker and seller of RestrainedLove-enabled products, I did think about it all a lot before implementing such a feature.

For a start, you must consider that many RestrainedLove relays already implemented their own black-listing feature, so the viewer-side black list won't affect more in-world scripted items (those RestrainedLove items that are not worn and thus need a relay) than the black-list enabled relays have already been affecting for years. In fact, the viewer-side black list may even improve the situation since, unlike relays, it can give feedback about commands support... which brings us to the following chapter:

You also get a new info command (@getcommand), which may be used to retrieve the list of the commands that are both supported and not blacklisted by the viewer. This command actually already existed in RLVa (it reported the supported commands too, but of course, didn't take into account any black-list since there was none). It works much like the @getstatus command. The syntax is as follow:
@getcommand[:partial_name_match]=channel
Where "partial_name_match" is the (part) name of the command(s) for which you want to know if the viewer will execute it(them).
Example:
@getcommand:sendim=222
Will report "/sendim/sendim_sec/sendimto" for a "BDSM Persona-Player" profile and an empty string for a "BDSM Role-Player" or "Non-BDSM" profile.

There is however a small issue with @getcommand as it was implemented in RLVa: it didn't make any distinction between the @behav=add, and @behav=force variations of some commands and just returned "behav" (since with no black-list, if one variation was supported, the other was too). With the possibility to blacklist one variation and not the other, it would be better if @getcommand could distinguish both... For now and by default, the Cool VL Viewer implements a RLVa-compatible version of @getcommand, but if you set a special debug variable to TRUE, then @getcommand reports differently.
This debug variable is "RestrainedLoveExtendedGetcommand" and can be changed easily from the Advanced -> RestrainedLove sub-menu:
Image
In the above screen-shot, you can see that the "Enable the extended @getcommand version" is checked.
(EDIT: see this post for update)

With the extended @getcommand version, you could, for example, issue "@getcommand:remattach=222" and get "/remattach/remattach%f" when none of @remattach=add or @remattach=force are blacklisted (Persona and Role Players profiles), or just "/remattach%f" when @remattach=add is blacklisted (Non-BDSM profile).

It must also be noted that @notify reports succeed even for blacklisted commands. This is so that existing scripts (that expect some commands to be present based on RLV version number) don't get "stuck" waiting for a @notify report upon issuing a blacklisted command.

As a final word, I'll say that the black list actually broadens immensely the use of RestrainedLove that non BDSM-Persona-Players were so far very reluctant to enable in their viewer because of the unwanted restrictions they hated or just feared.


2011-11-19 15:15:09
Profile WWW

Joined: 2010-03-14 21:12:58
Posts: 86
Reply with quote
Wonderful Idea, and superb implementation. I hope and expect that this will wind up in the new RLV/RLVa work Marine and Kitty are doing.

I do have one completely cosmetic suggestion. As I'm sure you know, a lot of people are hesitant to use any RLV functionality because of it's BDSM and kinky sex related image. I think it would be better if we don't contribute to that and change the description wording on the preferences from "BDSM Toys Support" to "Extended and Restraint Support" and in the User Profiles change "BDSM" to "RLV." Or some other wording that doesn't have the kinky connotation. In places where BDSM is referenced, say something like "Originally developed for the BDSM community." and so on.

I would love to tell people to enable RLV and check the Non-RLV profile and then they can use the automatic teleporters and wardrobe changers, and never worry about being locked to a device or forced into kinky sex.

I know it's not much of a change, but I have some friends who are rabid about it and as soon as they see "BDSM" they freak out and run away screaming. (One wouldn't even let me hug her until I renamed my collar from "Ibrew's Collar" to "Ibrew's Choker" because she was so upset by the idea of being controlled.)

This is certainly not a high priority, but just something to keep in the back of your mind while coding.

Keep up the great work, Henri! You rock!


2011-11-20 21:48:08
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Ibrew Meads wrote:
I do have one completely cosmetic suggestion. As I'm sure you know, a lot of people are hesitant to use any RLV functionality because of it's BDSM and kinky sex related image. I think it would be better if we don't contribute to that and change the description wording on the preferences from "BDSM Toys Support"
This mention was removed in v1.26.2.7: the tool tip for the corresponding check box is pretty explicit anyway (mentioning both BDSM and non-BDSM usages of RestrainedLove).


2011-11-26 14:41:25
Profile WWW

Joined: 2010-08-21 12:30:36
Posts: 89
Reply with quote
3 things come to mind:

Are the profiles hot swappable in-world or do you need to change the selection and then restart ?

When you choose Custom what profile does it show you chose ?

Does the viewer broadcast what profile you currently are using to other RLV users (possibly with a query command?) ?


2011-11-28 01:23:07
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Lord wrote:
3 things come to mind:

Are the profiles hot swappable in-world or do you need to change the selection and then restart ?
Like I wrote above (and in the tool tip for the "User profile:" text in the panel): "Note however, that this variable is only read when the viewer is started". So yes, you need a restart, for obvious anti-cheating reasons.

Quote:
When you choose Custom what profile does it show you chose ?
Again, it's written in the tool tip: no radio button is checked when the blacklist is a custom one.

Quote:
Does the viewer broadcast what profile you currently are using to other RLV users (possibly with a query command?) ?
@getblacklist in IM will be implemented in RestrainedLove v2.08, so not yet but yes, soon.


2011-11-28 01:31:08
Profile WWW

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Since Marine adopted the blacklist and implemented new commands, the Cool VL Viewer v1.26.0.29 and v1.26.2.8 were made compatible with and updated to RLV 2.08.01.

Also, the RLVa-like @getcommand (which is not implemented in Marine's RLV) is still there, but in its extended version only, i.e. like if the "Enable extended @getcommand version" setting (implemented in v1.26.0.28 and v1.26.2.6 and now removed), was always on.

The new commands to get the blacklist are @getblacklist (also works in IMs, just like @version does) and @versionnumbl (works only for scripts and returns the version number followed with the comma-separated list of the blacklisted commands).


2011-12-03 14:40:51
Profile WWW

Joined: 2011-12-04 15:00:58
Posts: 22
Reply with quote
This essentially breaks one feature of many RLV furniture/relays of keeping a captive on reloging. All one has to do is setting the blacklisting to non-bdsm and relog and it's a silent escape.
Now i realize you could just as well turn off RLV and do the same, but that option is well known and being checked for, unlike the black-listing which pretends it got RLV while possible only having a few non key elements of it.

So my suggestion is this: Only allow black-listing options to be changed when no restrictions that were in effect at the end of the last session are affected.

The alternative would be that everyone who cares about this has to expand their scripts to check for all the various possibilities opened by this/buy such scripts. More work, more lag, more cost .. you get the idea.


2011-12-06 19:39:19
Profile

Joined: 2009-03-17 18:42:51
Posts: 5523
Reply with quote
Raish wrote:
This essentially breaks one feature of many RLV furniture/relays of keeping a captive on reloging. All one has to do is setting the blacklisting to non-bdsm and relog and it's a silent escape.
It doesn't break anything since:
Quote:
Now i realize you could just as well turn off RLV and do the same,
Exactly !...

Quote:
but that option is well known and being checked for, unlike the black-listing which pretends it got RLV while possible only having a few non key elements of it.
Nope, it's not "checked for". If you disable RLV, your relay will simply stop working and will not ping the device your avatar was sat upon... This is the *relay* (and not the device) that, on receiving the "pong" the device sends in reply to its "ping", auto-resits your av on re-log... There is no difference whatsoever in the result for the device (avatar not re-sat on re-log and device ignoring it).

Quote:
So my suggestion is this: Only allow black-listing options to be changed when no restrictions that were in effect at the end of the last session are affected.
This would be an interesting suggestion (and I did consider it already in the past), if there was not a very BIG problem with it: how do you escape a buggy device, or a situation you would normally safeword but for which you got no safeword option ?... This is why *all* the RestrainedLove viewers always allowed to deactivate the RestrainedLove support even when your avatar is restrained, so that RestrainedLove gets actually disabled on re-log.

Quote:
The alternative would be that everyone who cares about this has to expand their scripts to check for all the various possibilities opened by this/buy such scripts. More work, more lag, more cost .. you get the idea.
There are always means to cheat (and even with a secured viewer, no one could prevent a cheater to re-log with a non-RLV viewer to escape, then re-log again with the RLV viewer once they did escape).
There is no need for scripters to bother trying to cover all the cases (including cheating ones). All they should care about is providing proper support for people their device is designed for and clearly state the limitations in the documentation.


2011-12-06 20:00:30
Profile WWW

Joined: 2011-12-04 15:00:58
Posts: 22
Reply with quote
Henri Beauchamp wrote:
Raish wrote:
but that option is well known and being checked for, unlike the black-listing which pretends it got RLV while possible only having a few non key elements of it.
Nope, it's not "checked for". If you disable RLV, your relay will simply stop working and will not ping the device your avatar was sat upon... This is the *relay* (and not the device) that, on receiving the "pong" the device sends in reply to its "ping", auto-resits your av on re-log... There is no difference whatsoever in the result for the device (avatar not re-sat on re-log and device ignoring it).


Okay it's not being checked for normally by devices, but if wanted can easily be done as it's just one value and not 20.
I'm specifically thinking of the OpenCollar's function to notify the owner when the wearer logs in with a non-RLV Viewer. This creates a bit of a deterrent to cheating out unless really necessary. The other devices don't have to do anything and yet things get more interesting.

Quote:
Quote:
So my suggestion is this: Only allow black-listing options to be changed when no restrictions that were in effect at the end of the last session are affected.
This would be an interesting suggestion (and I did consider it already in the past), if there was not a very BIG problem with it: how do you escape a buggy device, or a situation you would normally safeword but for which you got no safeword option ?... This is why *all* the RestrainedLove viewers always allowed to deactivate the RestrainedLove support even when your avatar is restrained, so that RestrainedLove gets actually disabled on re-log.


I agree there needs to be a way to escape buggy scripts/bad situations, but one is all that is needed. Why create more escape paths that are hard to be controlled?

So allow turning RLV off altogether anytime, but allow fine tuning only if it doesn't affect the current restrictions.


2011-12-06 22:52:57
Profile

Joined: 2010-03-14 21:12:58
Posts: 86
Reply with quote
Raish wrote:
Henri Beauchamp wrote:
Raish wrote:
but that option is well known and being checked for, unlike the black-listing which pretends it got RLV while possible only having a few non key elements of it.
Nope, it's not "checked for". If you disable RLV, your relay will simply stop working and will not ping the device your avatar was sat upon... This is the *relay* (and not the device) that, on receiving the "pong" the device sends in reply to its "ping", auto-resits your av on re-log... There is no difference whatsoever in the result for the device (avatar not re-sat on re-log and device ignoring it).


Okay it's not being checked for normally by devices, but if wanted can easily be done as it's just one value and not 20.
I'm specifically thinking of the OpenCollar's function to notify the owner when the wearer logs in with a non-RLV Viewer. This creates a bit of a deterrent to cheating out unless really necessary. The other devices don't have to do anything and yet things get more interesting.


I'm pretty sure you'll see the collars start checking for this. It's simple and straightforward to check. It's also more appropriate for the collar to do it, since the RLV can be used for more than just bondage and restricting peoples ability to set those will just make it more difficult for those who don't use the RLV for bondage play.


2011-12-06 23:29:05
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 11 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.