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
Thursday, July 21, 2011
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
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
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 !
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.
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
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
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
Subscribe to:
Posts (Atom)
Posts
