Monday, November 28, 2011

Restrained Love v2.8.1

Hi !

Ok I know I have just released RLV 2.8, but two things were still bugging me, so here they are, fixed :

- fixed : RLV_38 : @getinvworn can return string literal "n" instead of two numbers for the this/child status indication

- fixed : RLV_13 : @getstatus needs a new, or user-selectable, separator (first character was still always a slash).

Since the second bugfix implied changing the response to @getstatus[all], I have to bump the version of the RLV API to 2.8.1 as well. That's the only change, but the way it was done under 2.8 wasn't intuitive and could lead to more work for the scripter. Now a @getstatusall:;#=2222 will respond #showinv#showworldmap#showminimap (for example) instead of /showinv#showworldmap#showminimap.


Download the viewer here :
http://www.erestraint.com/realrestraint

The MD5 hash for the Windows installer is
72c2aeac34492fcec4c739581ec450b9

Sorry for the inconvenience,
Marine

Sunday, November 27, 2011

Restrained Love v2.8

Hey !

So here it is, after many promises, the new RLV with a blacklist to ignore some RLV commands !

I know, I'm a little late. Hehe. Anyway here it is. Along with many other bugfixes, just see for yourself :

- added : RLV_18 : Implement blacklist :
- RestrainedLoveBlacklist debug setting as a comma-separated list of tokens. Adding "%f" after a token indicates that we are blacklisting the "=force" variant instead of the "=n" one.
- @getblacklist[:partial_name]=2222 to retrieve a comma separated list of blacklisted commands
- @getblacklist in IM to act like @version.
- @versionnumbl=2222 to retrieve both the version and the blacklist.

- added : RLV_25 : Canonical names for new attach points need to be defined : "Neck" & "Root".

- changed : Re-establish fully opaque windows, since now we can control their transparencies through the preferences.

- fixed : RLV_35 : Layout of panel_status makes RLV unusable on smaller screens.

- fixed : RLV_28 : simple notifications unreadable (introduced in 2.7.4 by inverting the script dialogs).

- fixed : "@detach=n" on a child prim did not always make the whole object undetachable.

- fixed : RLV_37 : Double names on emotes on the chat history still show under @shownames.

- fixed : @attachallthis doesn't work with folder which name begins with "~", even under another folder (Thank you Sassy Romano for the report).

- fixed : RLV_13 : @getstatus needs a new, or user-selectable, separator.

Some of the changes involve new RLV commands (namely @getblacklist, @versionnumbl and @getstatus[all]), so the API will change version as well, to 2.8.


Go grab the viewer here :
http://www.erestraint.com/realrestraint/

And the MD5 hash for the Windows installer is :
61eb68da2b3fb85345393e430ddf0c36


Have fun !
Marine

Sunday, November 13, 2011

Restrained Love v2.7.4.2

Hello there,

I've been busy fixing bugs lately... and here is the result !

- changed : Radar hides information when the People window is too small, to improve readability.

- changed : Make the chat toasts bigger again.

- changed : Remove the "Block" button on scripts dialog, it was too easy to click on it by mistake.

- fixed : RLV_32 : @showloc wouldn't hide the location when coordinates are hidden.

- fixed : RLV_27 : Whisper/Shout don't show as such on chat history.

- fixed : RLV_31 : Viewer crashes when opening the Picks window.

- fixed : SL bug : Emotes appear twice on the chat history.

- fixed : Empty tokens in RLV commands ("@showloc=n,,showinv=n", "@showloc=n,") would raise a "failed command" alert, yet execute the command anyway (thank you Mo Noel for the report !)

- fixed : Information button on the top menu bar wasn't doing anything anymore, now it shows the Place Profile window again, like on the navigation bar and the mini-location bar.

- known issue : Payment notification text is totally off, as a result of the change to the placement of the buttons in the script dialogs.


You can grab the viewer here :
http://www.erestraint.com/realrestraint

And the MD5 hash for the Windows installer is :
215a6d23cf52beb9cf4d42117b7eda6b


Have fun !
Marine

Monday, November 7, 2011

Restrained Love v2.7.4.1

Hi there,

So I have added a shortcut to restart all the animations (I use this a lot so a shortcut is necessary), but I didn't realize this was used for "select all", AND it would not allow you to select all the text... Sorry about that !

So here is RLV 2.7.4.1, with the shortcut changed to Control+Alt+Shift+A, with my apologies :)

Grab the latest version here :
http://www.erestraint.com/realrestraint

And the MD5 hash for the Windows installer is :
241a78959f6f04e9faf7a952a7b5b7c7

Have fun !
Marine

Sunday, November 6, 2011

Restrained Love v2.7.4

Hello there,

This is it ! RLV has switched to SL 3.x, this means the sidebar is gone, and we are back to individual windows, like in v1.x ! And naturally this required a lot of adapting and tweaking, that's why I took so long before releasing this version.

You will notice quite a few changes compared to v2.x, but you should quickly find your marks again. The most noticeable changes are the sidebar that is no longer in the viewer, and the notification area that has shifted to the upper right corner of the screen, just like in v1.

Oh wait... This actually creates a big problem, at least for me. You see, I am used to clicking on the same buttons on the same scripts (namely mine), and with time I have grown to predict their position on the screen, even before they appear. This makes me a lot more productive, and it has been so since day one. Let's do a little history here :

In SL v1.x, script dialogs were on the upper right corner of the screen, and were bright blue. There was some text in a fixed size area, possibly with a scrollbar, and then the buttons that you pressed to dialog with the script.




In SL v2.x, these dialogs have moved to a notification area, which is on the lower right corner of the screen. And this time, the text would be a variable size area, but still above the buttons so it wouldn't matter, the buttons would always be at the same spot. Best of both worlds : buttons always at the same position, and no more scrollbar to hide the text.





But now, in SL v.3, the script dialogs are back to the upper right corner, this is all well and good but there is still no scrollbar. Which means the buttons (that follow after the text, which is still a variable size area) would appear... just anywhere on the screen, depending on how much text there is to display ! Eek ! That's unacceptable if you ask me.

That's why for this version and probably onwards, I have inverted the text and the buttons. The buttons appear above the text instead of below. It takes a little time to get used to, but it works since they are now always at the same spot. It creates an issue, though : some notifications are totally off. I will be working on it, but it is less easy than it seems and I really want to release this version now.





And now, on to the other good stuff :

- added : Ctrl+A keyboard shortcut will do a "Me" > "Movement" > "Restart All Animations".

- changed : Now @showloc will also hide the coordinates, not only the parcel and the region. Thank you Chorazin Allen for the suggestion !

- changed : Chat history window is optimized, and the "Google translate" checkbox is removed (for now, but if too many people use it I will put it back).

- changed : in v3.x, the SL viewer shows notifications (IMs, script dialogs etc) on the upper right corner of the screen. This seriously messes up the placement of the buttons on script dialogs, as their positions are not predictable anymore. Therefore I swapped the buttons with the text, and the buttons now appear above the text.

- changed : Chat bar disappears when losing focus, if the chat history is hidden and if "CloseChatOnReturn" is set to TRUE in the debug settings. Chat toasts are also moved slightly higher up so that the chat bar does not hide them.

- changed : Reduced the minimum size of most used windows (inventory, appearance, people, places), as well as the size of the tabs on these windows.

- fixed : "Use region settings" switched back to the latest customized Windlight settings, instead of the default region settings. Thank you Lance Corrimal for the heads-up !

- fixed : Sending a TP offer would behave wrongly if one of the people who were sent the TP offer was an exception to the @sendim restriction. Thank you Lance Corrimal for the fix !

- fixed : Some Windlight settings were wrongly set through RLV commands (namely all the "intensity" values). Thank you Henri Beauchamp for the fix !

- known issue : Payment notification text is totally off, as a result of the change to the placement of the buttons in the script dialogs.


You can grab the viewer here :
http://www.erestraint.com/realrestraint

And the MD5 hash for the Windows installer is
598d864225c163c50b8560dd7e836422


Please note : In case you hate this viewer (or it does not work for you), I am leaving 2.7.2 and 2.7.3 on the download page. The change might be too much for some.

Have fun !
Marine

Saturday, October 22, 2011

Restrained Love v2.7.3.3

Hello there !

Finally, here is the version I've been working on loosely, while waiting for LL to deliver sources to a viewer that actually works. It's not perfect, I find it works better than 2.7.3.2, but I still experience occasional crashes, especially when downloading a lot of textures (in crowded areas for example). But at least it's usable.

Here are the bugfixes and improvements I have added in this version :

- added : Make gestures activate/deactivate when wearing/removing items respectively through a script.
- added : New icon for the viewer, thanks to Kittin Ninetails's nice work :)
- added : "Use region settings" menu item in the World > Sun menu, to be able to revert to default without having to open 3 windows.
- fixed : Now each prim handles its own restrictions (instead of all defaulting to the root prim), but if ONE prim is set to be undetachable, then the whole object is undetachable.

Link
Grab the viewer here :
http://www.erestraint.com/realrestraint

And the MD5 for the Windows installer is
374576d5cf34e4ddfbe084662b1e8921

Now I'm going to try out LL's latest viewer, with all their UI changes. It looks good so far !

Have fun !
Marine

Sunday, October 9, 2011

RLV Issue Tracker

Hi again,

It's been a long time I should have done this, but now it is official : the RLV has its own issue tracker now ! This comes directly from my blog post about opening the specification of the RLV : http://realrestraint.blogspot.com/2011/07/rlv-to-become-really-open.html

If you don't know what an issue tracker is, think of LL's JIRA dashboard, through which bugs and feature requests are filed by the users. The RLV issue tracker works exactly the same way, but is much simpler.


Issues are separated in four main categories (more may be added later) :

- Discussions : This category is meant to serve as an informal forum. Bugs and new features will be discussed here, like a big brainstorm before triaging and turning the good ideas into projects.

- RLVSPEC : This category is meant to contain all the bug reports and new features that impact the specification (the API). It is formal and features in that category are to be considered seriously.

- RLVORIG : This category is about bugs and features in my own RLV (not RLVa).

- RLVUNIF : This category is empty for now, since there is no "merged" RLV yet.


If you encounter a bug and you are sure it is tied to my RLV (the viewer, not the spec), please file it under "RLVORIG". If you are sure it is tied to the specification itself, tag it "RLVSPEC".

If you wish to share your new feature, please drop it on "Discussions" first so that you can discuss it with other people, because "RLVSPEC" and "RLVORIG" are meant to be more formal.

You can find the tracker here :
https://bitbucket.org/marinekelley/rlv/issues


Sorry again for the time it took. I should have done this looong ago !

Have fun !
Marine

Saturday, October 8, 2011

RLV news

Hello there,

Wow it's been two months since my last post... Sorry about that. Let me briefly explain why I've been so silent :

- The V2 SL viewer has been added more nasty bugs than fixes, and that hindered my ability (and motivation) to work on a new RLV, although it has been on "active waiting" mode for more than two months. The bugs are about very frequent crashes due to memory bloat (https://jira.secondlife.com/browse/SH-1650), invisiprims being totally useless when using dynamic shadows, breaking prim shoes (https://jira.secondlife.com/browse/SH-2181 , I think, it is marked as fixed but I had to back it out from my code if I wanted to see invisiprims again), and other countless bugs that, frankly, should have been fixed two years ago when V2 was still beta. This is a shame. Even now, you can't write in a notecard and be sure that what you write will be added where your cursor are. You can't use Mouselook either. Ctrl-W works when it wants. The Discard button is so invasive that you often press it by mistake, losing your purchase and wasting your money. What a joke.

- For more than a month now, the latest version was so bloated that the textures would suddenly start to re-rez repeatedly as soon as the memory limit was reached. It was sickening. First time the viewer made me wanna puke for real.

- I've been working at testing mesh on my RLV, so far so good, except... well, meshes are not resizable when rigged (i.e., when used as a piece of clothing). Apparently, it is too hard technically to allow for resizing a rigged mesh, but this limitation is a fatal blow to the mesh clothing and restraint market. This is so disappointing, I was working on some new mesh restraints, well this project has been shelved now. The official ETA for the fix is "Someday/Maybe". Just take a look at the JIRA entry to see for yourself : https://jira.secondlife.com/browse/SH-2374

- Third party viewers like the RLV are still unable to upload mesh, because the library is proprietary. I've been trying the open-source version, but had less success than others.

- I am currently working on overhauling the animation system in my products, to give more choices to the user without breaking the existing RR plugins. I'll blog more about this later, when it's ready.

So right now the RLV is on standby, but almost ready for a release should something new happen. It is just that for now, I have nothing new to offer compared to 2.7.3.2, which is more stable and usable than 2.7.3.3.

Ok, this post sounded like a rant... And not at all what I was supposed to talk about in the first place. No worries, I'll blog about the next thing shortly :)

Have fun,
Marine

Monday, August 15, 2011

A new brand and a new item !

Hello there,

Over the years I have been working on many projects in SL. Some very much on the kinky side, like restraints, others totally different. Among the restraints, some were (in my opinion) good enough to share with others, and that's the reason why I have created the RealRestraint brand. However I never got to share some of my other projects with the community, because they were so far away from my main business that I was afraid of confusing my customers.

But I have a lot to share... Some of my private projects are, I think, good enough to be enjoyed by others and although I know they won't be as mainstream as my restraints, it would be a shame to keep them for myself :)

So here is me creating a new brand that I have called "Marine's Goodies". It's a little like visiting an attic, without the spiders. In this brand you will find several items that have nothing to do with each other, and very little to do with BDSM.



For now there is only one item to sell in this brand, a HUD that is meant to be used by ponygirls/ponyboys and their trainers. It is very versatile, a trainer can command as many ponies as they want, even with other teams around, it is very resistant to lag, and a pony can even use this HUD while blind ! Have you ever tried to pull a cart while blind, without hitting a wall ? I know a few ponies who are good at that now, thanks to this HUD :)

Several friends of mine have been nagging me for over a year to release it, so here it is !


For now there are only two vendors in this new brand. One is at my shop in Pak, the other one is at the Little Shop of Kink, in Lineside. If it works well, I will add vendors across the grid.

Have fun !
Marine

Saturday, August 13, 2011

Restrained Love v2.7.3.2

Hi there,

Here is the latest version of the RLV, no new features this time but an updated codebase and a few bug fixes. The change I like the most in the new codebase is being able to focus on any object without having this "zoom effect" we've had for years. You can now focus on a hollow prim at will.

This new codebase also added a "feature" that I personally disliked very much, and therefore changed back to how it was before : the Build window used to have a drop-down list that would allow you to change the way objects were moved and rotated : World/Local/Reference/Screen/Attachment. It was VERY useful for a builder and I used it like all the time. I don't know why, but Linden Lab moved this list box to an annex window (the "Build Options" one). However this window is meant to be used only once in a while, now the SL viewer requires a builder to have it open at all times. It eats more screen real estate and makes you click more, for no gain. Worse, this list box was replaced by the "Link" and "Unlink" buttons... Imagine clicking on "Unlink" by mistake, it would destroy your object with no undo available.

So I removed those two buttons and re-added the list box and I'm a happy builder again.

Aside from that, here are the bug fixes :

- fixed : The Windlight shared region settings added by LL to the viewer recently introduced a way around the prevention against changing environment settings.

- fixed : @getinvworn would sometimes give weird results when a single no-mod item was under a folder which name did not begin with "."

- fixed : When prevented from seeing the location, right-clicking on the ground (Linden land not a prim ground) would make the viewer slow down to a crawl, eventually crashing. Same thing when trying to open the "About Land" window.

Download the viewer here :
http://www.erestraint.com/realrestraint

And the MD5 hash of the Windows installer is :
320c1045a227f23dd4d8e5d11e20c42b


Have fun !
Marine

Thursday, August 4, 2011

New RR product : The Jammer

Hello there !

I am proud to announce the release of a new product in the RealRestraint brand : the Jammer !

Unlike the other products of my brand, this one is not really a restraint. It is... far worse. Those who heard about the Banishment Program know that I am very interested in all kinds of behavioral control devices in SL, and the Jammer is the result of my research.

Out of the box, it looks like a mundane bluetooth headset, that everyone owns nowadays.




But make no mistake ! This is not at all what it is meant for. Under this disguise lie a few high-tech, low power control devices :

- Headphones : Filling the wearer's ears and employing active noise cancellation, they completely suppress the hearing while acting like actual earphones.

- Vocal chords suppressor : Pressed against the wearer's trachea, this small device issues active noise cancellation as well to suppress any sound coming from the wearer's throat, effectively muting her. It also contains a mic, in order to record what was going to be said and send it to the central unit.

- Contact lenses : Applied directly on the eyes, they react to the radio signals sent by the central unit, and polarize themselves accordingly, effectively blinding the wearer when needed.

- Speaker : Disguised into the microphone part of the headset, it is used to speak on behalf of the wearer, using advanced voice morphing technology to perfectly imitate the wearer's voice. It also contains an actual microphone that hears what is said within chat range.

- Central unit : This is the nexus of the system, it is embedded inside the plastic part of the device. It comprises several sub-units :
- A radar to detect who is around
- An antenna to communicate with the Dominant's remote
- A very high frequency, very low power radio emitter to control the opacity of the contact lenses
- A central micro-processor to execute the program uploaded by the Dominant


With this device and the remote control that goes with it, you, as the Dominant, are able to control what your sub says, what she hears, what she sees, you can even speak through her device and hear the chat around her. Or limit the amount of chat she says, suppress it, censor it, or even censor what she hears, making her hear totally different things...

And last but not least, you can actually program her like a computer ! The Jammer has its own programming language that is flexible enough to give you plenty of leverage over your sub, and have her behave at all times, even when you are not around. With this programming language, you can automatically replace words that she says or hears, force her to say the things you want, report to you according to your wishes, and even trigger animations and sounds (that you upload from the remote control).

In the remote you find several predefined programmings, like one for a slave (not being able to speak unless spoken to first, being forced to say "Master" or "Mistress" when talking after you, etc), one for a ponygirl (not being able to understand human language, only common gestures), one for a puppygirl (being made to bark and overall act like an animal), one for a doll (obsessed with sex, eager to serve her owner) and one for a drone (acting like a robot, having her brain washed, being unable to even speak, only obey). Of course these are just examples, you can modifiy them and write your own programmings at will, without limit. You can even share them with fellow Dominants, since they are just contained in notecards.

You also find a few full-perms sounds and aninms (the famous "nadu" for example, but also some custom anims like a "girl in pain" one) that you can upload into the Jammer, and force your sub to play.


Now... Before you get all excited, know that this device is VERY complex stuff. The manual is big and divided in three parts :

- If you are just a casual user, you will have fun with its basic features such as acting like a renamer, limiting and suppressing the speech and hearing, and speaking and hearing through the sub.

- If you are more serious about it, you will learn through an extensive tutorial how to write a program for the Jammer and how to upload it. Mostly for its speech control features.

- And if you are an actual programmer in RL (or even just a scripter in SL), i.e. you have the mindset of a developer, you will enjoy reading the expert part of the manual, that details all the intricacies and features of the language itself, telling you how you need to know to come up with full-fledged programs.


In other words, into the right hands this device can prove to be very powerful. Mwahaha !


Have fun with this new weapon !
Marine

Thursday, July 21, 2011

RLV to become really open

Hi,

A big change is occurring on the RLV side of life. From the beginning I have been holding a tight control over it (how many times did I hear "too tight" !), it was painful and frustrating for some but necessary for the project to succeed.

Firstly because when it started by the end of 2007, third party viewers were still a new thing in SL and users needed to be reassured about the liability of the makers and maintainers of these viewers. We couldn't allow a password-stealing function hidden under some nice feature. I wanted to enhance the experience for the fetish community so I needed to make my own viewer, and I needed it accepted by said community. I committed my name to it, since I was already famous at that time. It was a successful move and the "Restrained Love Viewer", or "RLV", was quickly born and adopted. Note that at the time, it was still named "Restrained Life Viewer". It changed name only much later.

Over the years, suggestions came and were discussed (in private, mostly), features were added, but always with me staying in control of the project. Both because I was developing it and because I needed to make sure it stayed consistent, secure and backward compatible.

This is why the RLV is some kind of UFO in the world of third party viewers. While other third party viewers strive to give more power to the user, the RLV strives to give more power to scripts. Generally, commercial scripts. In other words, the RLV is a platform, a middleware between the user and the scripts included into the objects they would use daily. It was a challenge to build such a platform and the trust with both the users and the content creators. You don't risk your business lightly on some kind of new technology without being sure that it is there to stay. But it is a challenge that I took and won. The RLV is a success.

Nowadays, the RLV is mature. It is widely adopted by users and content creators, even outside the fetish community. Its wide exposure brings a lot of feedback, suggestions and bug reports, that I have to handle myself in my free time. And the more feedback the more features, the more features the more work for me.

Moreover, I had considered approaching Linden Lab with the idea of integrating a subset of the RLV inside their original viewer, in the past. For example the shared Windlight settings, the shared folders and so on. Things that are outside kink but yet very useful to a broad panel of users. Bots are made that use the RLV to let customers see demonstrations of the outfits they consider buying, for example. Combat sims use a number of RLV commands to ensure fairness during fights. Disabled people are helped by others when it comes to moving, teleporting, wearing outfits etc, all this thanks to their RLV. There are dozens of examples like that. But integrating the RLV into the SL viewer was never considered by LL (they have enough on their plate as it is), so my implementation of the RLV stayed a little like an outsider. The specification, however, was more and more adopted thanks to another viewer that was steadily seducing more and more users : Firestorm. It is to the point that half SL uses it now (and counting), so instead of maintaining the RLV for LL, why not do it for Firestorm ?

Now that the RLV specification is mature (as in "stable and usable", not "complete"), there is less momentum to add new features. There is more code, more testing, overall more work involved when I add something now than when I did back in 2007. And there are more and more pressing demands from other people to open the specification, in other words to give more power to discussion instead of letting me be a "bottleneck" in the process. I want to be part of the solution, not part of the problem.

Some of you might be aware of an effort that was undertaken months ago to make a group in order, a "think tank", to discuss of the directions where the RLV should be headed to. The RLV belongs to the community and not to me. It is my gift to the community after all, I am the guardian of it, but not its owner. My role is to ensure that any new feature will not break older ones, nor existing content in SL. The RLV is a platform for business, it is capital that the content creators know that their platform of choice won't bite them in the butt later and jeopardize their business.

However, this group is mainly Firestorm-centered. The maths are simple : the user base of Firestorm is multiple times bigger than that of any other third party viewer, so whatever feature they come up with becomes de facto standard when it's released. And that group is really pressing to adding new features to the RLV part of Firestorm.

So after giving it much thought, I have decided that it would be beneficial to everyone, especially content creators, to bring the specification to a new level of audience and reactivity.

This is why I am joining their team as one of the two RLV developers, the other being Kitty Barnett (whose own implementation is called RLVa, for "alternate", and was meant to be a testing grounds for new features before discussing with me to add them to the spec, precisely). And be part of that group as well, of course, for I am the most qualified to determine whether such and such change is beneficial to the spec, the most knowledgeable about the many pitfalls to avoid, and am the original author of the specification and first implementation.


So what does it mean in practice ?

I will keep developing and maintaining my own RLV on the side, as I always have. It has many features that are unique to it and I don't want to lose them. Moreso, other third party viewers use my code directly and I don't want to let them down. I also want to keep my testing grounds for new features (which is what my RLV has always been), so nothing changes there. However both my implementation of the RLV spec and Kitty's need to be merged into one, and that's not going to be an easy task. There is a chance that I drop my code completely and only use hers, since it is already in Firestorm, we'll see. My code is older and grew along with the specification, while hers is younger and was done when the specification was already mature. Both our codes are very different, mine is rather simple and to-the-point, while hers is completely object-oriented hence modular. But also much more convoluted.

On a side note, Kitty hasn't had the most enjoyable role until now. A different implementation implies different bugs, with users screaming at her because it "works in my viewer and not in hers". And she was always bound to wait for me to add new features to the spec. This was not a sane situation for her. Now we are going to work together instead of doing the same thing in two different ways each one on our side.

I am also coming into that group (again) with my own guidelines. There are three golden rules for the RLV spec, that I've been following to the letter so far :

1. Separation : A RLV shall not do what scripts can do. Otherwise it would stop being a platform and would become a competitor to the very projects it is supposed to support.

2. Compatibility : A RLV shall not break content. That means we must assume that each existing command is already widely used across SL, and that changing it will upset a lot of people. Likewise, a new command shall not contradict an existing one.

3. Security : A RLV shall never jeopardize the user's assets (be it inventory items, objects in-world, money or personal information).

These rules are the reason for its success. I will keep following them when discussing new features, and will systematically vote against a change that violates one of those rules. They are the reason why I have kept doing this alone until now, I trust the people in the group are adult and responsible enough to understand their value and subscribe to them. If they don't, I have nothing to do with that group.

The way I see it, the group is like a buffer between the community's suggestions and the inclusion of some of them in future versions of the spec. We (that means me included) will debate over interesting new features to add to the specification and decide whether to really include them or not, by voting. I am not going to be their coding slave though, nor is Kitty. There is no hierarchy involved. All equal, no leader (although the workload of actually coding the thing rests on our shoulders). Besides not all the members of the group are involved into Firestorm, it is a group of content creators, and of course not all Firestorm is involved into that group either. Lastly, the group should be open for joining, lest be regarded as some kind of "RLV elite group", which would be very much anti-community. The last thing I want is to see the RLV spec be used as a weapon by a select few content creators against the rest of the crowd, and I am here to ensure it won't happen.

But I want to make it clear that I will not tolerate a battle of egos. I come there to get things done. Petty politics are for petty people. The last (and only) meeting I had with this group months ago was less than pleasant. I got myself crowded and pressed with demands from all sides. If it happens again, I won't stay long.

Likewise, I am not being "assimilated" (eww). I am not committing myself to Firestorm, nor dropping anything else that I was doing. The way I am joining may not be the most ideal for me (those who know the story behind it understand why), but it is the most logical. It is capital that the RLV stays under the control of responsible people, including the original author of it (me), but one person cannot take the load of all the suggestions coming from all the Firestorm users. It's just too much.


I'll keep you posted about the developments.
Marine

Friday, July 15, 2011

Restrained Love v2.7.3.1

Hi !

Here is the latest version of the RLV, hopefully less crashy than the last one. There are a few bugfixes too, some of them to long-standing bugs :

- fixed : Could not Replace Outfits when under an @addoutfit or a @remoutfit restriction.
- fixed : When trying to teleport someone, we were not getting the automatic response if they were prevented from teleporting.
- fixed : Temporary uploads were broken in 2.7.3.

Grab the installer here :
http://www.erestraint.com/realrestraint

And the MD5 hash for the Windows installer is
a71225d8893e9cb77bffece0eed13c63

Note : If invisiprims render black on your screen (no matter whether you have Lighting and Shadows on or off), simply turn the "OctreeAttachmentSizeFactor" down to 1 (it is 4 by default). You can do this in the Advanced > Debug Settings menu.

Have fun !
Marine

Friday, July 1, 2011

Restrained Love v2.7.3

Hi !

Here is a new version of the RLV, with once again a few enhancements that you'll like, I'm sure :

- added : Now you can see "Typing" above the name of an avatar who is typing, regardless of whether their typing animation is hidden or not.
- changed : Now you can customize the automatic message people get when they IM you and you can't receive IMs. Requires a restart of your viewer.
- changed : Now you can customize the automatic message people get when you IM them but you can't send IMs. Requires a restart of your viewer.
- changed : You are given the choice whether you can send and receive OOC chat (chat between double parens : "((...))"). Default is TRUE, and it requires a restart of the viewer.
- fixed : Restrictions were removed silently (i.e. without a notification to scripts) when garbage-collected from an object that had disappeared.
- fixed : Allow to Replace an Outfit even when something is locked. This was a long-standing bug, glad it is fixed now.

The "Typing" feature was something I have been meaning to do for a long time now, but never found how to do it. 90% of the people in SL deactivate their typing animation because they think it makes them look like newbies, but they don't realize that it removes a crucial piece of information from the people around them. When they don't know whether you are typing a very long message or you're just afk for a bit (or crashing), they tend to become frustrated that the conversation is dragging.

I've had long conversations with friends that could have been much shorter if our typing animations were enabled, simply because we spent most of the time wondering if the other was typing or not. Because of that, I had deactivated mine as a sign of protest, after years of trying to convince them to activate theirs.

I believe that enabling the typing animation is a mark of respect to others, but being very vocal about it over the years didn't bring any result. Now with this new feature, the point is moot. People can keep their typing anim off, you can still see whether they are typing or not. Best of both worlds.



Following the release of 2.7.2 and much testing, it appears to be very crashy for a few people (like me) but not for others, and only when enabling Dynamic Shadows. If you don't enable it, it does not crash more than any other SL viewer. Therefore I have removed the link to 2.7.1, and this one becomes the normal RLV.

The Windows dowload is there :
http://www.erestraint.com/realrestraint

And the MD5 hash is :
e77197ec6fe620d184068385eb83879e

Have fun !
Marine

Addendum :
Forgot to mention it in the readme file, the debug settings to control the OOC and send/receive IMs features are the following :
- OOC : RestrainedLoveCanOoc
- Send IMs : RestrainedLoveSendimMessage
- Receive IMs : RestrainedLoveRecvimMessage

Wednesday, June 15, 2011

RLV 2.7.2 as an optional download

Hi there,

A couple days ago I have released RLV 2.7.1, with a few new features... No need to repeat them here, you can read all about them there.

I must admit, this release was a little rushed. Linden Lab had been working in their Mesh Viewer branch for more than a year (the first line of code of this branch is more than 2 years old), and had merged it with the "viewer-development" branch a few weeks ago.

Think of "branches" as full-fledged projects, usually requiring a full team of developers. On the LL side, Mesh, Windlight, Search etc are branches to the main SL viewer codebase. On the TPV side, Phoenix/Firestorm, Dolphin, Kirsten, Imprudence, RLV etc are "branches" to the main SL viewer codebase. Each branch drifting further and further off the official SL viewer as new features are added to them. Eventually, LL-side branches are bound to be merged to the main SL branch and be rendered available for download. This is how you benefit from the work of dozens of teams working on separate but complimentary projects. All these branches forming, in the end, the SL viewer.

There are two main branches : "viewer-release" and "viewer-development". The former is the one the official SL viewer is built from it is supposed to be stable because it went through all the QA testing, while the latter is more advanced (read : it has more features and more fixes, but also more bugs sometimes) and is the one I built my RLV from. It serves as a buffer and testing grounds for new features before they hit "viewer-release" and the general public.

In other words, the RLV was about to get the latest merge from the Mesh team right in the face. It was daunting. The Mesh team had been working not only on adding Mesh support to SL (the Beta grid had it live for a year now), but also on improving the visual effects dramatically. Dynamic shadows, that's them. Depth of Field, them too. Shadow smoothing, yup. Ambient Occlusion, ditto. And Mesh support, of course. They've been working hard and some of their work had been integrated into several TPVs over time (including RLV), but it was still beta.

Now that their work was about to go mainstream, I had to get the latest features into the RLV, test them and release them before taking the big leap. Because grabbing their own work to add it to the RLV was like adding Windlight and Sculpties in one move. It was bound to take some time and vacations are approaching. Hence the release of RLV 2.7.1 with those not-so-RLV enhancements.

Once the release was done, I thought I was out of the woods for a while, but I took a head-start and tried the Mesh code anyway. Just to see the damage it would do to my code. And it went... surprisingly well (thanks to Mercurial). Many things that had been annoying me for months have been fixed (small prims not rezzing, horizontal scrollbar messing the text selection, alpha-sorting not done properly, and dozens others), and more importantly it's SMOOTH ! I had received a powerful graphics card for xmas, just so I could run the dynamic shadows on my machine and had been less than impressed at the improvement... But now it's smooth even with everything on (SSAO, sun & moon with projectors, depth of field). It looks GOOOOOD ! And the Depth of Field feature, although a marginal addition, has the nice side effect of making sub-standard looking structures look, well, less sub-standards. When a building has ugly seams but stays in the background, they won't ruin your snapshots anymore. For someone as snap-happy as I am, this is a nice perk.


All this to say... I actually love this new viewer. This is what I've been awaiting for so long, and I've heard here and there that LL has been listening to their users as to what needed to be improved first. Kudos to the team for their work !

The only downside is that it crashes a lot. I don't know if it comes from the "viewer-development" codebase or my computer, but taking snapshots or sometimes even playing with the sidebar would do funny things like crash to desktop.

However LL has just released their "Dynamic Shadows Viewer" as the official SL 2.7.2 yesterday. The corresponding RLV is ready, but does crash. That's why I am releasing it at the same time, but as an optional download, leaving 2.7.1 available for now. I don't know how it will behave on your computer. I do know that it crashes more than the last on mine. But it's too good to pass on so here it is.

The Windows dowload is at the same place :
http://www.erestraint.com/realrestraint

And the MD5 hash is :
199edbb5d3651e9be796b12c14177184

Attention, aside from the crashes there is a known bug : hearing an emote on the chat will display as "/me ..." if the chat history is not shown. This is not a RLV bug.

Have fun with it and don't forget, if it crashes too much you can still go back to RLV 2.7.1.
Marine


PS : I'm hearing Henri yell at me from here "Stop mapping your RLV version to the SLV version, it confuses the hell out of my users !" I didn't do it on purpose ! This is a coincidence again !

Saturday, June 11, 2011

Restrained Love v2.7.1

Hi !

Here is a new version of the RLV with a few bugfixes and enhancements (no new command this time), these are things I have been wanting to do for a long time.

During roleplay, a few times now I could still recognize a friend even when being unable to see names and despite her efforts to sound like a different person, simply because I knew nobody else bearing her "dummy name" ("An agent" in her case). I have stated years ago, when introducing the @shownames command, that every avatar had a dummy name that was calculated from their user name, and that this dummy name never changed. This is not true anymore because making it static like this would eventually ruin the very purpose of hiding names. One would go "Oh her name is 'this individual' ? That must be Jane again !" and blow the surprise that Jane was making.

Now the viewer will make a new deal of dummy names every few hours (but not during a session). This means that every few hours, Jane's dummy name will change to something else on the next relog. It doesn't change at every relog because sometimes the environment can get crashy, and you need to relog several times during your roleplay. Dealing new dummy names every time you log on would confuse you unnecessarily.

Second big enhancement, I have added a menu item called "Restart All Animations", in the "Me > Movement" menu. This item allows you to restart all the animations you are playing, as well as all the animations every avatar around is playing too, resulting in all the animations starting at the same time again. This is very handy when you're involved in couple animations with your partner, but both are out of sync because one needed more time to start than the other. With this menu item, animations will be perfectly in sync again.

Third big enhancement, this was kind of a popular request... I have long wanted to add a "@say" command to force the avatar to say something. While interesting at first glance, this command would open a big can of worms because of the amount of griefing it allows. Imagine for instance your RLV relay forcing you to insult someone on the chat in a public place that you visit often, resulting in you getting banned. This is why no such command has been added, despite many requests.

So I flipped the problem around, and made it so that when an object speaks, it would look like avatar chat to the RLV users around. Even if the wearer herself is not a RLV user. This is purely a cosmetic change, no new command to handle this, and can be controlled with a debug setting anyway. This makes it much safer while still allowing "fake avatar chat". The conditions for being able to make an object sound like an avatar are these :

- It must be attached (it won't work if it is on the ground).
- Its name must be equal to its wearer's user name, or dummy name, or first name or last name.
- People hearing it must have their "RestrainedLoveImitateAvatarSpeech" debug setting set to TRUE (this debug setting is introduced in this version), which is the default value.

Notice that this behavior occurs in the RLV of the users AROUND the object, not the RLV of the object's wearer themselves (if any). In other words, if the captor wants to make her gagged victim sound like she is talking gagspeak herself and not through green chat, they must use this RLV.

There is an important bugfix as well. When some folders are locked or specifically allowed, moving folders and items in or out of them would be problematic (if your top doesn't want you to wear this particular dress, there was a way to move the dress elsewhere and wear it anyway).

Now the behavior is simpler :

- You cannot rename a folder if it is locked and under #RLV.
- You cannot move a folder or an item if it is locked or the destination folder is locked.
- You can always move or rename a folder or an item if the source and destination folders are not under #RLV.

By "locked" I mean "allowed" or "denied", not exactly "locked on you". This refers to the recent feature of locking folders on, off, or adding exceptions to these locks.

There are a couple other bugfixes, such as a slowdown on the Nearby tab when prevented from seeing names, and refreshing the status bar on startup so that the sliders won't appear twice if your navigation bar is open.


So there, here it is :
http://www.erestraint.com/realrestraint

The MD5 hash for the windows installer is
aa392c0f8d92e6f691f8ae7653579131

And the full change list :

- added : "Me" > "Movement" > "Restart All" Animations menu item, to restart every animation you and other avatars are currently playing around you. This is local to the viewer only and has no consequence on the sim or other people. This is handy for synchronizing couple animations, especially when one takes a lot more time to download than the other.

- changed : When someone else's attachment speaks and its name matches its wearer's (user name, dummy name, first name or last name), the viewer will show it as if it were avatar chat instead of object chat. This makes gagspeak look more natural. This behavior can be turned on or off by the "RestrainedLoveImitateAvatarSpeech" debug setting.

- changed : "Dummy names" ("a person", "this individual"...) are now scrambled every few hours when unable to see names. This allows even a close friend whose dummy name is well known to still be able to surprise you during roleplay. They are not scrambled at every relog though, to avoid confusing the user under crashy conditions.

- fixed : Copy/pasting items from/to a locked folder (a folder to which a lock or an exception to a lock has been issued). Renaming folders and moving objects from an unshared folder to another one is ok though.

- fixed : A slowdown of the viewer when having the Nearby tab open and restricted from seeing names.

- fixed : Refresh the draw distance and avatar height offset sliders in the top status bar when starting.


Have fun !
Marine

PS : If you experienced weird errors about a notification called "HintView" in the RLV, spamming you with so many dialogs that it was unusable, please download again. This was a strange issue with non-English languages.

Saturday, June 4, 2011

RealRestraint update to 1.21.2

Hello there,

I have updated all my brand of products to 1.21.2, it is mostly to catch up with the latest additions in the RLV. Although benign at first glance, this update will really add to the features of the RR products !

See for yourself :

* Touch plugin
- Added the latest RLV commands restricting touch (self, other people and in-world objects).

* Outfit plugin
- Added the ability to restrict some folders and their children, as well as to allow some folders and their children. Very useful if you want to precisely control your sub's ability to dress.

* Wear plugin (new plugin)
- Handles the ability to wear specific clothes and attachments (like the old Outfit plugin did in a coarser way).

* Unwear plugin (new plugin)
- Handles the ability to unwear specific clothes and attachments (like the old Outfit plugin did in a coarser way).

* LockShoes plugin (Vixen ankle cuffs only)
- Changed its access scheme, to allow the wearer to be able to resize the heel strap if needed.


Plus, two new tutorials to teach you how to use the Touch, Control, Wear, Unwear and Outfit plugins :

Touch/Control/Wear/Unwear plugins tutorial
Outfit plugin tutorial

You can update your restraints by going at any of these locations :

Marine's little shop
Little Shop of Kink
S&M Castle (*)

Once there, just touch the updater (it looks like an orb mounted on a pedestal), and follow the instructions.

(*) You may have to walk to the castle, find my vendor (you can't miss it), the updater is in a corner.

Have fun !
Marine

Outfit plugin

Hello there,

Today I am going to tell you about a plugin I use all the time : the Outfit plugin. This one relies on RLV to work, it won't do anything if the captive is not using the RLV.

This is complex stuff, so please bear with me. There are a lot of things to explain, but fortunately they could be split into two posts. This one will talk about how to handle shared folders (restricting them, forcing them on or off etc), while the other post is about its child plugins Wear and Unwear, which work exactly the same way as Touch and Control, that's why they are melded into one post only (you can read that one here).

For this tutorial I will wear these pieces of clothing : a jacket, a shirt, a bra, a skirt, panties and boots.



Yeah, I know, it looks like I am just missing my umbrella for a walk under the rain. Har har.



First off, I am going to talk about the two buttons named "Detach at" and "Remove at". These buttons are on the main page of the Outfit plugin, and are meant to detach things that the captive is wearing, quickly. Let's see... Right now I am wearing shoes, boots to be exact. Let's say my top wants to force me to remove them but does not want to browse my folders. All he has to do is to tell the plugin to make me remove "whatever outfit containing the shoes layer". So he clicks on "Remove at" and chooses "shoes". And immediately my shoes layer, as well as my left lower leg, right lower leg, left foot and right foot attachments are detached. Simple, easy. It would have done the same thing if he had pressed "Detach at" and chose, say, the left foot.




Now, let's head to the really interesting part : handling the shared folders through the Outfit plugin. You already know the RLV handles what is called "shared folders". In a nutshell, a shared folder is a folder in the inventory that is "exposed" to the scripts, so they can manipulate it. I won't detail how shared folders work here, there are tutorials on this blog, but let's see how to use the Outfit plugin to exploit them to the best of its abilities.

Browsing through the shared folders is easy. Shared folders are just that, folders, and as such they are organized in a hierarchical way, exactly like your files on your computer. And like in every hierarchical structure, there is a root that is the entry point to the whole data. So I click I click on my cuffs, I go to Plugins, select "Outfit", then "Root"...



I'd like to find one particular outfit I am wearing, without knowing much about its name. It happens when your shared folders are beginning to become a bit populated, like mine... And I'd like to find my jacket.

Did you notice that little "(w)" sign before "> Glamour" ? This sign means "something is being worn somewhere in that general direction". So I press on this button, and get shown all the folders contained in it. Once again one of them shows "(w)". I press on "> Casual", I see that the "Jackets" button has the "(w)" sign, so I press it and...



Found it ! The "Black bomber" is the outfit I am wearing. I know it because it shows a "(W)" sign now, not a "(w)" anymore. The capital "W" means "this outfit is worn". So I click on it and will decide what to do with it.





Before I go any further, let's say I am distracted by RL for more than 10 minutes. Since the Outfit menu has a 10 minutes timeout, when I come back it will have expired so it won't do anything when I press a button. So I press "Ignore" to close this now useless menu, but I do not want to walk all the way down to the jacket again ! That's what the "Selected" button is for : I click on my cuff, press "Last Plug" to go to the Outfit plugin again, and then choose "Selected". And I am lead right to where I left ! "Selected" means "the last folder I was on", as opposed to "Root" which means "the topmost folder" (in our case, "#RLV" itself).

Now, what options do I have ? Not many. There is no outfit contained in the "Black bomber" one so I cannot keep browsing that way (the shared folders are a hierarchy after all, it is a tree with a root, branches and leaves, and this particular outfit is a leaf, a dead-end). All I can do is detach it or walk back, or change its mode (more on that later).

I press "DETACH" and right away my jacket and its prims vanish.





Naturally, if I pressed "ATTACH" now, it would come back, but this is not what I want.


This was pretty straightforward. Now on to the sexy stuff. No I'm not talking about lingerie ! I will show you how to allow and deny folders, and what it really means to do that.

Some of you might remember that in the past, the RLV was only able to restrict attaching and detaching clothes and attachments per name. For example, you could only prevent from attaching a jacket, a shirt, or something on spine, things like that. But you couldn't prevent from wearing one particular folder, or prevent everything except one particular folder. It can do that now, and this plugin is up to date to handle this new feature.

Before I begin, let me remind you exactly what this new feature is. You already know that your #RLV folder is a hierarchy of folders and items. By default you are able to wear and unwear what you want, except what is locked. The RLV is able to completely lock a folder and all its children out from you, making you incapable of wearing it (or removing it, depends on the option), renaming it, moving items in or out of it... It is secure. It is also able to prevent you from wearing or unwearing things that are NOT in your #RLV folder. In other words, it allows the top to control the captive's ability to wear things totally.

This is the theory. Let's see it in practice. Let's say my Mistress wants me to be able to wear only heels. Only N-Core heels, for that matter, and nothing else. No boots, no flatties, no sandals, nothing but high heels.

You may have noticed the "Mode" button on the menu. When clicking on it, it switches between "Normal", "Allow" and "Deny". And on the top of the menu, you see the current mode as well. Redundant you say ? Not really, let me explain why.

I click on my cuffs again, Plugins, Outfit, then I go to the Root folder, and Shoes.



This folder contains all my shoes, and I have lots. Ankle-high boots, knee-high boots, thigh-high boots etc... and all these must be restricted except on particular brand of one particular kind of boots.

Here is the folder in my inventory, entirely expanded :



What I want is the top "Shoes" folder to be locked out, but NOT the "N-Core" folder. I am in the "Shoes" folder now, let's press "Mode" twice to set it to "Deny".



There, what I have just done is this :


The red overlay indicates what I am prevented from wearing or unwearing.

But this means I cannot wear my n-core heels, right ? Yes, for now. I go to the "n-core" folder, it is contained in "prim heels" :



Oh, interesting here. The "Mode" button pretends it is "Normal", but I can try as I might, I won't be able to wear any of these shoes, or any other shoes whatsoever. But what is the top part of the menu saying ? "OUTFIT DENIED BY INHERITANCE"... What the hell does that mean... Remember that the "Shoes" folder and all its children was red, in the picture above ? Including "N-core" and the rest ? I denied only "Shoes" though, I did not deny the other folders one by one (imagine the task it would be). This means that since one of its parents is denied, this folder "n-core" is denied too. By, uh, inheritance.

Now I want to specifically lift the lock for this folder. So I click on "Mode" once, to switch to "Allow". And in the process, the top part of the menu indicates "ALLOWED". How convenient. Here is what the menu looks like now :



And my inventory is now treated like this :


The red still indicates what I am prevented from wearing, but there is an isle of green folders, that I am allowed to wear.

And I can now wear my n-core Pinup shoes ! These are the pumps I am wearing on my Vixen Leather vendor pic, btw. Lost of people asked.


Lastly, managing all the allowed and denied folders can become tedious, when there are a lot. Fortunately the Outfit plugin gives you a way to check the lists, and to actually use them as shortcuts if you like.

I click on my cuff, and go to the main page of the Outfit plugin, then I click on "Allowed" :



It shows the list of allowed folders, for now there is only one but this is really a list. And it also gives me a wall of numbers, plus a "Clear" button. If I pressed "Clear", it would clear the list instantly, and my Pinup shoes would be locked away from me again (to be exact, they would be locked ON me right now, since I am wearing them).

But instead of pressing "Clear", I press "1", which is the number of the N-core folder... and it brings me straight to that particular folder :



From there, I can change its mode or navigate at will, it saves a lot of time.



Now, if you are interested in the internals, here is what the RLV actually does when you ask it to wear or unwear an outfit :

- It checks if the folder is locked, if so, bail.
- It looks at all the parents, from that folder up to the root folder, and stops as soon as it finds one that is not "normal" (i.e. one that is either "allowed" or "denied", well, the RLV equivalent anyway). If it stops on a non-normal folder and that folder is "denied", then you can't wear the outfit. If it is "allowed", you can (even if one of its parents is "denied").
- If it went up to the root without finding a non-normal folder, all is well, the requested outfit can be worn or unworn.

There, it's pretty simple to understand but not so simple to explain. I find the red and green overlays on the pictures to be a lot more self-explanatory.

Have fun !
Marine

Touch plugin... and its siblings Control, Wear and Unwear

Hi !
Today I am going to talk about not one but four plugins at the same time ! These plugins, although having apparently nothing in common, share the exact same architecture and it is easy to understand what they all do (and how to use them efficiently) when you understand this very architecture.

Let's go. For this tutorial I will use the Touch plugin as an example, but keep in mind that the others work the same way. I will highlight the differences at the end of this post.

If your own Touch and Control plugins do not look like this one, please update your RR products. These versions are still fairly new at the time of this writing.

The Touch plugin is meant to prevent the captive from touching objects, and is normally found in arms restraints (when your hands are restrained, you can't use devices). In the past, it was used only to restrict touching far, since the arms restraints could "block" the captive (i.e. raise a HUD that would take the entire screen, blocking clicks, edit and rez). But recently the RLV has been added a few commands to control what could be touched and what could not, in a much finer grain than before. Hence the new Touch plugin.

Moreso, depending on the way her cuffs are locked, the captive may or may not be able to touch this or that. For example, with her cuffs locked in front, she may still be able to touch someone else's attachments, whereas she couldn't if her hands were cuffed in the back.

So for every lock type (hands in front, hands in back...), the top might wants to be able to decide what can be touched and what cannot, and to not have to set these restrictions everytime the lock changes.

In other words, the restrictions are organized like a matrix. For each lock, indicate which restrictions are to be in effect. And to represent this matrix, locks would be on the X axis, while restrictions would be on the Y axis. Does that make any sense to you ? Don't worry, it will soon.

I click on my Vixen leather handcuffs, and I go to the Touch plugin.


Oh, see ? A matrix ! Surprise ! A full square means "the captive is able to..." while an empty square means "the captive is restricted from...". For now all the squares are full because the restraint is new.

By default all the restrictions are lifted. This means that if you've just bought your restraints, your touch won't be restricted in any way even when you lock them on you. How to set a restriction then ?

Before we do anything, let me explain what is displayed a little. There is a small "x", followed by a row of numbers from 1 to 8, then a "L", and then a "A". And an arrow pointing to the "A".

This row represents the locks. "x" means "unlocked" (but all the restrictions are lifted when the restraint is unlocked, so you don't need to bother with that one, it is displayed for a reason I will explain later), the numbers "1" to "8" correspond to the 8 locks, "L" means simply "locked" (without a pose), and finally "A" means "All locks".

Aha. The arrow points to "A", and the "ALL LOCKS" button is "on". This is because by default the restrictions you set are applied whatever lock you choose.

Wait, doesn't it defeat the very idea of "one different set of restrictions per lock" ? Yes it does, but not everyone wants the fine-grain control that this matrix offers. Although you might want the realism of not being able to touch someone else's attachments only when your hands are cuffed behind your back, you're no here to punch holes into a matrix. You're here to have fun ! Therefore, by default, you simply decide what restrictions to apply, and that's it. If you want finer control, it is as simple as pressing the "ALL LOCKS" button. You'll see in a minute.

But enough talk ! Let's try it. I am wearing my Vixen cuffs now, and I click on them and lock them behind my back. As I didn't change anything on the Touch plugin, I am still able to touch objects in-world, whether they are near or far, and I can touch my own attachments and those worn by other people. As if I wasn't restrained at all.

I click on them and go to the Touch plugin, then press "Touch far". What happens ? Let's see the matrix now :


The matrix has a hole in it now, the square at the intersection of "A" and "Far" is now empty. This means "For ALL the locks, the captive cannot touch objects that are FAR". Farther than arms reach, that is. That's farther than 1.5 meter away, folks. Let's check this... I touch the door over there, nothing happens (it normally opens when touched). I walk closer and try again, ok that works now, I must just be near it. When I touch my collar it gives me its own menu. I can touch everything around me EXCEPT objects that too far away. It makes it feel more realistic, goodbye telekinesis !

Since my hands are cuffed behind my back, it would make sense that I'd be unable to overpower someone nearby, therefore I should be unable to click on their attachments as well. However I should still be able to touch my own attachments (for example a gag, you can still raise your hands at mouth level when cuffed like this, it does not require much flexibility), and objects that are not worn by anyone, like doors. I should be able to open a door in this kind of bondage, I just have to be very close that's all.

So I press the "Touch other" button to set this restriction, and another hole is punched into the matrix, still under "A". This now means "For ALL the locks, the captive cannot touch objects that are FAR, or objects that are worn by OTHER people". Hmm, this bondage is starting to feel real, now...


Ok, this is all good and well, but what if my hands were cuffed in front of me instead of behind my back ? I still wouldn't be able to reach objects that are far, but should I be able to, say, lock someone else's cuffs ? I think so. But how ? If I pressed "Touch far" again now, I would be able to touch far regardless of how my hands are cuffed, that's not very realistic...

This is where I must disengage "ALL LOCKS". This button acts like an override to simplify the handling of restrictions for people who don't want to bother about realism. But I do, so I press it to remove the override. And now the plugin goes from 1D to 2D (no there is no 3D yet :p ).



Notice that the arrow has shifted from the "A" column to the "2" column. Why "2" ? Because my hands are cuffed behind my back, and that is the second lock on the main menu. The first one being "hands in front".

And guess what ? I am totally unrestricted again. I can touch far, and I can touch other people's attachments. Great, did I do all this for nothing ? Not really. Let's see what happened here.

The "A" column has two holes, the ones we've set earlier, "touch other" and "touch far". This has not changed, but the arrow is not on "A" anymore, it is on "2", and "2" has no holes in it. In other words, the restrictions are all lifted again. Now suppose I am lazy and... no wait, scratch the "suppose" part, I AM lazy. I don't want to set the restrictions for every lock, that would be a waste of time that could be better used, for example on having fun. Let's do a little magic that is called copy/pasting. Remember the restrictions are more or less ok when the "ALL LOCKS" override is engaged. I will copy them and paste them to all the locks, individually.

I press "ALL LOCKS" again, engaging the override. Then I press "PASTE TO ALL", and...


What just happened ? The "A" column has been copied and pasted over all the other columns. Now I can tweak each individual lock if I want to. I press "ALL LOCKS" one more time to disengage the override again, and the arrow goes back to "2", the current lock.

 

On a side note, I can do this the other way around too, by copying the settings of the current lock (when "ALL LOCKS" is disengaged, "PASTE TO ALL" becomes "COPY", which actually pastes the current column to the "A" one, and then I can paste the latter to every column with the method I have shown above), but no need to do this now.

Now, I lock my hands in front. I am still unable to touch far (this is normal), but I would like to be able to touch other people's attachments.

 

Nothing's easier, I press the "Touch other" button to lift that restriction. And now the matrix looks like this :


A square has been filled, I can now touch other people's attachments again... but only when my hands are cuffed in front. If I cuff them behind my back again, that ability is removed. This is fine-grain control !

Now you know the most part of how the Touch plugin works, and by extension, how the Control plugin works (with its Edit, Rez, Map, Inventory and other restrictions), as well as how Wear and Unwear work (they restrict from wearing or unwearing clothing layers and attachments). Also, since the Touch plugin may be in the same restraint than the Control plugin, there is a shortcut to switch from one to the other. Same for Wear and Unwear (and their common parent "Outfit", for which I will write a full tutorial too).


There are a few things to note though, I know this has been a long read, but you might be interested in this...

I have said that the "x" column was unused. This is not entirely true. The top is actually able to set the restrictions on the captive even when the restraint is unlocked. Although this doesn't make sense at first glance, this is actually very handy when used in conjunction with, say, an autolock. When the restraint is unlocked, every button pressed on the Touch plugin will modify the "x" column. When the restraint is finally locked, the contents of the "x" column are pasted onto the current lock, or on the "A" column, depending on the override. But this happens only if the "x" column has been changed since the last unlock. Long story short, if you modify the restrictions while the restraint is unlocked, no problem. They will be applied next time it is locked, as intended. You won't even have to bother about it.

Lastly, it is possible to save the matrix and to load it again. After all, this matrix is just a series of 0s and 1s, right ? It is just text. And as such it can be copied to a text file and said on the chat.

I press the "Save/Load" button, and immediately I hear this from the cuffs :

Leather right wrist cuff (r forearm) whispers: Current configuration (save it in a text file for later) :
111111111110010000000011111111111000000000001111111111111111111111111111111111111111111111111111111,0
If you want to load another configuration, please type it on the public chat channel.

This is the contents of the memory at this time, after I have set the restrictions how I like them. So I copy them to a text file somewhere on my computer.


Now let's assume some time passed and the plugin was reset for some reason (for example after an update), the restrictions would be clear again, and I don't want to set them one by one again. The menu would look like this, leaving me a whole lot of work to do again :


This is where the "Save/Load" button helps me again, I press it, and I hear this :

Leather right wrist cuff (r forearm) whispers: Current configuration (save it in a text file for later) :
111111111110000000000011111111111010000000001111111111111111111111111111111111111111111111111111111,0
If you want to load another configuration, please type it on the public chat channel.

Now it's telling me the contents of its memory again, but it's clear. However it also tells me that it is listening to my chat, in case I'd have some data to give it. It just so happens, I do ! I copy the contents of my text file directly on the chat :

Me: 111111111110000000000011111111111010000000001111111111111111111111111111111111111111111111111111111,0

Yeah, I speak binary fluently. Hehe. At least binary that this plugin can understand. And it does understand it, because now the matrix shown on the menu is exactly the same as it was before it got reset. I just loaded the old configuration :



Personally, here is the configuration I use on the Vixen cuffs :

 

This means that with the hands in front (first and third locks), I can touch other people's attachments, and with the hands chained simply together (front or back, that's first and second locks), I can touch my own. In all other locks, I can neither touch my attachments not other people's, and under no circumstances can I touch objects that are far. But since the Vixen cuffs do not cover the hands (contrary to, say, the armbinder), I can always touch objects in-world.

If you're interested, here are my favorite configurations for different arms restraints of mine. Just press "Save/Load" on the plugin menu and say one of these on the chat, and you'll get the same configuration :

Elegance cuffs : 111100011110000000000011010001111110000011111111111111111111111111111111111111111111111111111111111,0

Armbinder : 010000000000000000000000000000000000000000001111111111111111111111111111111111111111111111111111111,0

Police cuffs : 111101011110000000000011010001111110000011111111111111111111111111111111111111111111111111111111111,0

Vixen cuffs : 111111111110000000000001100000000110100000001111111111111111111111111111111111111111111111111111111,0





You're still here ? Oh, yes, forgive me I forgot. This post is about 4 plugins, not just Touch... Well there is not much else to say, what I have explained for Touch also applies to Control, Wear and Unwear. Here are the main differences though :

- Control also allows the top to add exceptions to the channels restriction (which prevents the captive from sending messages on non-public channels).
- Wear prevents not only from wearing clothing layers and attachments, but also all the folders that contain anything that is meant to be worn on said layers and attachment points. For example, if you restrict "top", the captive will not only be unable to wear a shirt, undershirt or jacket, or anything on spine or chest, but even folders that contain shirts, undershirts etc. You don't want her to wear anything to cover the upper part of her body, that's what this option means.
- Likewise, Unwear prevents not only from removing clothing layers and attachments, but also any folder that contains clothes or attachments worn on the specified points. If you restrict "top", she will be unable to detach her spine and chest attachments, as well as remove her shirt, undershirt or jacket, as well as any accessory contained in a folder that also contains one of these parts.


There, I think that's it. Whew ! Thank you for reading this far !

Have fun,
Marine