Hi there,
RLV 2.9 had a few bugs and quirks that needed some taking care of ASAP, especially the color of the fog and the bugs in Mouselook, so here it is, RLV 2.9.1 which will hopefully work better for you !
See for yourself :
- added : Now when an item has been given by someone else or some object (such as a furniture), the user will be able to wear it and unwear it at will, regardless of the restrictions, until the next relog. This should help keeping the clothing restrictions from getting in the way of play.
- changed : Default to "Unconstrained" when opening a texture, whereas the viewer used to try to guess the proportions of the picture from its dimensions... but the server always serves textures as squares, so the default ratio was always 1:1.
- fixed... ish : RenderResolutionDivisor was broken, and is still broken, when turning the simulated fog on. It is not fixed yet, but now when using this debug setting while @camdrawXXX commands are active, the blur is set to be very high (256 for now), in order to prevent cheating.
- fixed : Mouselook was bugged when clicking on Alt, sitting down or teleporting, leaving the avatar stuck.
- fixed : The simulated fog introduced in 2.9 was not opaque enough, and it got worse when increasing the number of gradients.
- fixed : The color of the fog was wrong, too much greyish.
- fixed : @camavdist broke when impostors were turned off (thank you Vanilla Meili for the heads-up).
- fixed : Request teleport wasn't scrambling the attached message under @sendim.
- fixed : @tplure was preventing from receiving teleport requests, which was odd.
- fixed : The "Report" button on the context menu when right-clicking on an avatar was still working under @shownames and @shownametags, while it shouldn't be (you can AR someone through other means anyway).
As usual, you can grab the viewer here :
www.erestraint.com/realrestraint
And the MD5 hash for the Windows executable is :
0297cd8a2cfec77332a373ff8d66048d
Have fun !
Marine
Monday, June 30, 2014
Thursday, June 19, 2014
Upcoming changes in RealRestraint products
Hello there,
I have been thinking about this for a while, and I am writing this blog post to ask for your opinion (and opening comments for this so feel free to give me your opinion, but please make it constructive, thank you).
To me, a restrained sub should be vulnerable when out and about. I know SL is a virtual world and we are safe and all, but I am striving to make it feel as real as possible, so it strikes me as odd that a bound sub can walk everywhere without feeling helpless, and at the mercy of anyone who wants to overpower them, regardless whether they have a key to their restraints or not.
In fact, it may very well be something that some, if not most, serious players would agree with. Suppose you're outdoors with your hands cuffed behind your back, trying for example to slip out unnoticed (it could actually be a game, with the recent changes to the RLV...). But if you fail to go unnoticed and someone catches you, currently what can they do to you ? Nothing at all unless you permit it with an RLV relay or whatever attachment that has nothing to do with your restraints. That's not very realistic. If you're bound, you're vulnerable and people can do things to you whether you want it or not, that's the way I see it.
So here comes my idea. Suppose the person who caught you clicked on your cuffs, currently they would get a slightly condescending "you are not authorized" message and a suggestion to use a RealKey. Most people don't know what a RealKey is about, so they just assume they can't do anything to the sub and walk away. Opportunities of fun are missed. Even if the restraints are locked, there are many things that can be done to the sub, right ?
What I want to do is to provide the captor with a small menu, a little like the plugins browser, giving limited access to some plugins. These plugins would be Outfit, Sit and Leash. Because when you stumble on someone who cannot defend themselves, you can strip (or dress) them, you can snap a chain to their restraints (provided there isn't one already) and you can force them to sit somewhere.
This solution makes it safe for plugins such as "Public" (which immediately hands the key to the person touching the cuff), because only a handful of plugins would be available.
Currently what I'm trying to do is to add some code into the "Sit" plugin, which is present only in arms restraints, so that it triggers the menu I mentioned above. That preserves collars, legs and gags from this feature, and allows me to add this feature without adding a script for it. Notice that I didn't mention adding it as an option, if the sub is restrained, she is de facto vulnerable.
It makes sense to me, but does it make sense to you too ? Would you actually like such a feature ?
Thanks for your input,
Marine
PS : From the short but rich chat in the group immediately after I posted this article, it seems the general consensus is to have a plugin dedicated to it, that will be called "Vulnerable" (unless a better name is found), and that will give two switches : one for the sub only, to allow her keyholder(s) to make her vulnerable while bound, and one for the keyholder to actually make the sub vulnerable while bound or not. Only if both switches are turned on (they will be off by default, to let the restraints behave like they did until now), will someone get access to the Outfit, Sit and Leash plugins when clicking without having the key.
PS 2 : I'm sorry for taking so long to let the comments show... for once I will blame the tools because Blogger does not bother telling me when someone comments and that the comment is awaiting moderation. The consensus here is the same as on my group : such a feature needs a toggle, so there will be a toggle, as explained in the PS above. Thank you all for your comments !
I have been thinking about this for a while, and I am writing this blog post to ask for your opinion (and opening comments for this so feel free to give me your opinion, but please make it constructive, thank you).
To me, a restrained sub should be vulnerable when out and about. I know SL is a virtual world and we are safe and all, but I am striving to make it feel as real as possible, so it strikes me as odd that a bound sub can walk everywhere without feeling helpless, and at the mercy of anyone who wants to overpower them, regardless whether they have a key to their restraints or not.
In fact, it may very well be something that some, if not most, serious players would agree with. Suppose you're outdoors with your hands cuffed behind your back, trying for example to slip out unnoticed (it could actually be a game, with the recent changes to the RLV...). But if you fail to go unnoticed and someone catches you, currently what can they do to you ? Nothing at all unless you permit it with an RLV relay or whatever attachment that has nothing to do with your restraints. That's not very realistic. If you're bound, you're vulnerable and people can do things to you whether you want it or not, that's the way I see it.
So here comes my idea. Suppose the person who caught you clicked on your cuffs, currently they would get a slightly condescending "you are not authorized" message and a suggestion to use a RealKey. Most people don't know what a RealKey is about, so they just assume they can't do anything to the sub and walk away. Opportunities of fun are missed. Even if the restraints are locked, there are many things that can be done to the sub, right ?
What I want to do is to provide the captor with a small menu, a little like the plugins browser, giving limited access to some plugins. These plugins would be Outfit, Sit and Leash. Because when you stumble on someone who cannot defend themselves, you can strip (or dress) them, you can snap a chain to their restraints (provided there isn't one already) and you can force them to sit somewhere.
This solution makes it safe for plugins such as "Public" (which immediately hands the key to the person touching the cuff), because only a handful of plugins would be available.
Currently what I'm trying to do is to add some code into the "Sit" plugin, which is present only in arms restraints, so that it triggers the menu I mentioned above. That preserves collars, legs and gags from this feature, and allows me to add this feature without adding a script for it. Notice that I didn't mention adding it as an option, if the sub is restrained, she is de facto vulnerable.
It makes sense to me, but does it make sense to you too ? Would you actually like such a feature ?
Thanks for your input,
Marine
PS : From the short but rich chat in the group immediately after I posted this article, it seems the general consensus is to have a plugin dedicated to it, that will be called "Vulnerable" (unless a better name is found), and that will give two switches : one for the sub only, to allow her keyholder(s) to make her vulnerable while bound, and one for the keyholder to actually make the sub vulnerable while bound or not. Only if both switches are turned on (they will be off by default, to let the restraints behave like they did until now), will someone get access to the Outfit, Sit and Leash plugins when clicking without having the key.
PS 2 : I'm sorry for taking so long to let the comments show... for once I will blame the tools because Blogger does not bother telling me when someone comments and that the comment is awaiting moderation. The consensus here is the same as on my group : such a feature needs a toggle, so there will be a toggle, as explained in the PS above. Thank you all for your comments !
Monday, June 16, 2014
Restrained Love Viewer v2.9
Hi there,
As promised, here is the latest version of the Restrained Love Viewer (RLV if you lived under a rock for the last 7 years), with the brand new camera-related commands !
I won't detail all the commands here, the RLV API is meant for that kind of technical stuff, but let me just paste the release notes :
- added : @camzoommin and @camzoommax to prevent from zooming in or zooming out too far. This is great in games where the avatar is not supposed to have binoculars integrated directly in the eyes.
- added : @camdistmin and @camdistmax to force the camera to stay within a range, or at a certain distance from the avatar (or both). Set @camdistmax to 0 to force the view to Mouselook, and @camdistmin > 0 to prevent from going to Mouselook at all. This is great for games where you don't want the players to be able to cam around the sim, like in mazes.
- added : @camdrawmin and @camdrawmax to simulate fog or even blindness, by obscuring the world around the avatar (not around the camera like windlight settings do). Best used along with @camtextures. The camera is restricted to be inside @camdrawmin * 0.75 on top of it. This is especially fitting for blindfolds.
- added : @camdrawalphamin and @camdrawalphamax to indicate the closest and farthest opacities of the fog defined by @camdrawmin and @camdrawmax. When @camdrawalphamin is 0 (whicih is the value by default), you are assured that the world beyond @camdrawmax will be behind an opacity of @camdrawalphamax, regardless of the number of spheres rendered (which is decided by the new debug setting "RestrainedLoveCamDistNbGradients", which default value is 10).
- added : @camdrawcolor to set the color of the fog (default is black).
- added : @camunlock to prevent the camera from being unlocked from the avatar (it is unlocked when focusing elsewhere, or panning or orbiting the camera). This is great when you don't want the let the user see through walls.
- added : @camavdist to specify the maximum distance beyond which avatars look like shadows. This is great when blind or partially blind, to let the user know what the other avatars do, but not too clearly.
- added : @camtextures to make the whole world grey, except the avatars and the water. This is great when used along with @camdrawmin/max, to simulate blindness while still having a "feel" for the world immediately around the avatar. Please note that bump mapping and shininess stay untouched, because the avatar can "feel" whether a surface is smopoth, rough or slippery. (thanks Nicky Perian for the help !)
- added : @shownametags act exactly like @shownames, except it does not censor the chat with dummy names (but it does hide the radar, the name tags, prevents from doing things to an avatar through the context menu, etc). This is great for games where you have to find your opponents who may be hidden, and who don't want to be betrayed by their name tags.
- added : 3 more camera presets : left, right, top. This is to account for the lack of freedom we experience when @camunlock is set (since we can't move the camera much in that case).
- changed : now when you minimize a window in your viewer, its minimized shade stays where your window was, and the window reappears where the shade is when you restore it, so that the "Close" and the "Minimize/Restore" buttons stay at the same place. It was annoying when building and scripting to have windows move all over the place when minimized.
- changed : increase the limit of the avatar Z offset from -0.5/+0.5 to -1.0/+1.0.
- fixed : @detachall commands will not make the viewer stall anymore, they are now actually usable even when called on the top of the #RLV folder hierarchy.
- fixed : right click and selecting "Detach" on a temporary item in world did nothing (thanks Kyrah Abattoir for the heads-up).
- fixed : crash under @shownames, when a HUD owned by someone else spoke while imitating the name of its wearer. This was especially irritating when speaking to someone using a translator.
- known issue : RenderResolutionDivisor does not work well when @camdrawmin or @camdrawmax is set. No idea why.
- known issue : @camtextures won't hide the colors of the prim (the tint), only its textures. If someone knows how to fix this, I'm all ears !
Let me tell you a little about the camera restrictions. In essence, the goal is to let a script restrict the camera and the view : how far and how close the camera can go, how clearly and how far the user can see, and whether to let the camera go through walls or not. Here are a few pictures of how it looks with a "RestrainedLoveCamDistNbGradients" debug setting set to 40 :
You can also make all the avatars around look like dark silhouettes (or only beyond a certain distance), you can hide all the textures from sight to remove the visual feeling of the surroundings without cutting the whole picture (after all, a blindfolded captive can rebuild a visual image of her surroundings by the sounds, the touch and the smell, right ?).
As usual, you can grab the viewer here :
www.erestraint.com/realrestraint
And the MD5 hash for the Windows executable is :
852056e6f3ec2e7a406cb15507743fd7
On a side note, I am planning on updating all my RR blindfolds with this new feature (but users who are not on a RLV 2.9 will still have the old HUD so the products won't break), but it will take some time. Not because it's difficult (the script is already updated and tested) but because I have many more things to update in my brand, so I will take my time.
Have fun !
Marine
As promised, here is the latest version of the Restrained Love Viewer (RLV if you lived under a rock for the last 7 years), with the brand new camera-related commands !
I won't detail all the commands here, the RLV API is meant for that kind of technical stuff, but let me just paste the release notes :
- added : @camzoommin and @camzoommax to prevent from zooming in or zooming out too far. This is great in games where the avatar is not supposed to have binoculars integrated directly in the eyes.
- added : @camdistmin and @camdistmax to force the camera to stay within a range, or at a certain distance from the avatar (or both). Set @camdistmax to 0 to force the view to Mouselook, and @camdistmin > 0 to prevent from going to Mouselook at all. This is great for games where you don't want the players to be able to cam around the sim, like in mazes.
- added : @camdrawmin and @camdrawmax to simulate fog or even blindness, by obscuring the world around the avatar (not around the camera like windlight settings do). Best used along with @camtextures. The camera is restricted to be inside @camdrawmin * 0.75 on top of it. This is especially fitting for blindfolds.
- added : @camdrawalphamin and @camdrawalphamax to indicate the closest and farthest opacities of the fog defined by @camdrawmin and @camdrawmax. When @camdrawalphamin is 0 (whicih is the value by default), you are assured that the world beyond @camdrawmax will be behind an opacity of @camdrawalphamax, regardless of the number of spheres rendered (which is decided by the new debug setting "RestrainedLoveCamDistNbGradients", which default value is 10).
- added : @camdrawcolor to set the color of the fog (default is black).
- added : @camunlock to prevent the camera from being unlocked from the avatar (it is unlocked when focusing elsewhere, or panning or orbiting the camera). This is great when you don't want the let the user see through walls.
- added : @camavdist to specify the maximum distance beyond which avatars look like shadows. This is great when blind or partially blind, to let the user know what the other avatars do, but not too clearly.
- added : @camtextures to make the whole world grey, except the avatars and the water. This is great when used along with @camdrawmin/max, to simulate blindness while still having a "feel" for the world immediately around the avatar. Please note that bump mapping and shininess stay untouched, because the avatar can "feel" whether a surface is smopoth, rough or slippery. (thanks Nicky Perian for the help !)
- added : @shownametags act exactly like @shownames, except it does not censor the chat with dummy names (but it does hide the radar, the name tags, prevents from doing things to an avatar through the context menu, etc). This is great for games where you have to find your opponents who may be hidden, and who don't want to be betrayed by their name tags.
- added : 3 more camera presets : left, right, top. This is to account for the lack of freedom we experience when @camunlock is set (since we can't move the camera much in that case).
- changed : now when you minimize a window in your viewer, its minimized shade stays where your window was, and the window reappears where the shade is when you restore it, so that the "Close" and the "Minimize/Restore" buttons stay at the same place. It was annoying when building and scripting to have windows move all over the place when minimized.
- changed : increase the limit of the avatar Z offset from -0.5/+0.5 to -1.0/+1.0.
- fixed : @detachall commands will not make the viewer stall anymore, they are now actually usable even when called on the top of the #RLV folder hierarchy.
- fixed : right click and selecting "Detach" on a temporary item in world did nothing (thanks Kyrah Abattoir for the heads-up).
- fixed : crash under @shownames, when a HUD owned by someone else spoke while imitating the name of its wearer. This was especially irritating when speaking to someone using a translator.
- known issue : RenderResolutionDivisor does not work well when @camdrawmin or @camdrawmax is set. No idea why.
- known issue : @camtextures won't hide the colors of the prim (the tint), only its textures. If someone knows how to fix this, I'm all ears !
Let me tell you a little about the camera restrictions. In essence, the goal is to let a script restrict the camera and the view : how far and how close the camera can go, how clearly and how far the user can see, and whether to let the camera go through walls or not. Here are a few pictures of how it looks with a "RestrainedLoveCamDistNbGradients" debug setting set to 40 :
From 3 to 10 m, with an alpha going from 0 to 0.8
From 0 to 10 m, with an alpha going from 0 to 0.5
From 3 to 5 m, with an alpha going from 0 to 1
You can also make all the avatars around look like dark silhouettes (or only beyond a certain distance), you can hide all the textures from sight to remove the visual feeling of the surroundings without cutting the whole picture (after all, a blindfolded captive can rebuild a visual image of her surroundings by the sounds, the touch and the smell, right ?).
As usual, you can grab the viewer here :
www.erestraint.com/realrestraint
And the MD5 hash for the Windows executable is :
852056e6f3ec2e7a406cb15507743fd7
On a side note, I am planning on updating all my RR blindfolds with this new feature (but users who are not on a RLV 2.9 will still have the old HUD so the products won't break), but it will take some time. Not because it's difficult (the script is already updated and tested) but because I have many more things to update in my brand, so I will take my time.
Have fun !
Marine
Tuesday, June 10, 2014
Upcoming RLV 2.9
Hiya,
This is just a heads-up, I am currently working on a few new commands for the RLV (I know, it's been a while, right ?), specifically aimed at handling the camera and the view range. It doesn't sound very glamour said like this, but here is what these commands can do :
- You can restrict the camera within a sphere around the head of the avatar, and if you restrict the distance to zero, it forces the view to Mouselook, without any way to get out of it until the restriction is lifted.
- You can also prevent the camera from going under a certain distance of the avatar's head. It prevents from going into Mouselook as well.
- You can specify a view range... that alone deserves some explanation. It has nothing to do with the draw range of the viewer, which lets you decide how far the objects rez. Here, it "simply" draws a hollow sphere around your avatar's head, at a specified radius, with a specified color and more importantly, a specified alpha. The camera is automatically restricted within that sphere so that your avatar looks normal to you, but the rest of the world may look darkened (or completely hidden). Even better, it can draw a gradient of spheres going from the specified alpha at a specified range, up to 1 at another specified (higher) range. The effect is good enough to simulate gradual darkness or fog. It does not look as good as Windlight fog, of course, but at least that simulated fog is centered on the avatar, not on the camera (but nothing keeps you from using fog on top of it, of course).
These features are great for blindfolds, with or without a gradient of darkness, because you can't see anything around you but you have heightened senses about your own body. I never really liked to obstruct the HUD with a prim to simulate blindness, since SL is mostly a visual world, take out the visuals and it becomes a lot less interesting. So now you will be able to make blindfolds that obstruct the world but not your avatar and not the immediate vicinity (for example the chair you are sitting on, or the bed you are laying on, or the wall you are trying to follow). Couple that with a clever use of RenderResolutionDivisor and/or Windlight parameters, and you can make some nice effects.
The camera and view restrictions are also great for mazes, or overall keeping the avatar from camming around. I know it is already possible through a script, but at the expense of a fast timer, hence a lot of lag for a single feature. Plus, a script would never be able to catch up quickly enough when you go outside the allowed range, so you can see things you are not supposed to see for a short moment. With the RLV handling that internally, the camera simply cannot move further than the limit.
I said earlier that it had nothing to do with the draw distance that decided whether a prim is rezzed or not. This because artificially forcing the draw distance to a low value does not look good, and removes some interesting prims such as lights, walls casting shadows, and the like. It would look, well, broken.
Here is a couple pictures to illustrate what I have been talking about :
Of course, those spheres are visible to the user only, not to other people. It is a local thing, as it should be. It would have been possible to simulate all that with attachments, but then everyone would have seen those black spheres, right ?
On a side note, all the limits (camera and view alike) are set to be the most restrictive among those specified. Suppose you have several attachments imposing different view limits, the minimum range will be taken into account, so no way to cheat there. Same for the alpha, the highest alpha is retained. As for the color, it is a mix of all the specified colors (default is black).
There are some other things I'd like to work on if I find out how to do them. For example, I'd really like to be able to restrict the camera to points in space that are directly in the line of sight of the avatar's head. But that requires some heavy computation that cannot take place in a frame update. I'd also like to let the user choose how many steps in the gradient of alpha to render, because the more layers of alpha to stack onto each other, the slower the rendering. Lastly, for now the spheres that are supposed to obstruct the view, do not appear on snapshots. I'm currently working on a way to make them show (the snapshots I took here are not taken with the SL snapshot feature, but with a classic screen capture).
There is no ETA for the release, but it is nearly satisfying as it is, so it should come out soon. I'm also trying to keep the code clear in my repository so that it will be easy to port, for example to RLVa.
Have fun !
Marine
This is just a heads-up, I am currently working on a few new commands for the RLV (I know, it's been a while, right ?), specifically aimed at handling the camera and the view range. It doesn't sound very glamour said like this, but here is what these commands can do :
- You can restrict the camera within a sphere around the head of the avatar, and if you restrict the distance to zero, it forces the view to Mouselook, without any way to get out of it until the restriction is lifted.
- You can also prevent the camera from going under a certain distance of the avatar's head. It prevents from going into Mouselook as well.
- You can specify a view range... that alone deserves some explanation. It has nothing to do with the draw range of the viewer, which lets you decide how far the objects rez. Here, it "simply" draws a hollow sphere around your avatar's head, at a specified radius, with a specified color and more importantly, a specified alpha. The camera is automatically restricted within that sphere so that your avatar looks normal to you, but the rest of the world may look darkened (or completely hidden). Even better, it can draw a gradient of spheres going from the specified alpha at a specified range, up to 1 at another specified (higher) range. The effect is good enough to simulate gradual darkness or fog. It does not look as good as Windlight fog, of course, but at least that simulated fog is centered on the avatar, not on the camera (but nothing keeps you from using fog on top of it, of course).
These features are great for blindfolds, with or without a gradient of darkness, because you can't see anything around you but you have heightened senses about your own body. I never really liked to obstruct the HUD with a prim to simulate blindness, since SL is mostly a visual world, take out the visuals and it becomes a lot less interesting. So now you will be able to make blindfolds that obstruct the world but not your avatar and not the immediate vicinity (for example the chair you are sitting on, or the bed you are laying on, or the wall you are trying to follow). Couple that with a clever use of RenderResolutionDivisor and/or Windlight parameters, and you can make some nice effects.
The camera and view restrictions are also great for mazes, or overall keeping the avatar from camming around. I know it is already possible through a script, but at the expense of a fast timer, hence a lot of lag for a single feature. Plus, a script would never be able to catch up quickly enough when you go outside the allowed range, so you can see things you are not supposed to see for a short moment. With the RLV handling that internally, the camera simply cannot move further than the limit.
I said earlier that it had nothing to do with the draw distance that decided whether a prim is rezzed or not. This because artificially forcing the draw distance to a low value does not look good, and removes some interesting prims such as lights, walls casting shadows, and the like. It would look, well, broken.
Here is a couple pictures to illustrate what I have been talking about :
With just a semi-transparent bubble around the avatar, set to alpha 0.5. No max draw specified means we can see through. The camera cannot go outside this bubble, by the way.
With both a min and a max draw specified, you can see (barely) a gradient. Beyond the max draw limit, everything is black. Once again, the camera cannot go beyond the min draw limit (where the world starts getting blackened a little).
Of course, those spheres are visible to the user only, not to other people. It is a local thing, as it should be. It would have been possible to simulate all that with attachments, but then everyone would have seen those black spheres, right ?
On a side note, all the limits (camera and view alike) are set to be the most restrictive among those specified. Suppose you have several attachments imposing different view limits, the minimum range will be taken into account, so no way to cheat there. Same for the alpha, the highest alpha is retained. As for the color, it is a mix of all the specified colors (default is black).
There are some other things I'd like to work on if I find out how to do them. For example, I'd really like to be able to restrict the camera to points in space that are directly in the line of sight of the avatar's head. But that requires some heavy computation that cannot take place in a frame update. I'd also like to let the user choose how many steps in the gradient of alpha to render, because the more layers of alpha to stack onto each other, the slower the rendering. Lastly, for now the spheres that are supposed to obstruct the view, do not appear on snapshots. I'm currently working on a way to make them show (the snapshots I took here are not taken with the SL snapshot feature, but with a classic screen capture).
There is no ETA for the release, but it is nearly satisfying as it is, so it should come out soon. I'm also trying to keep the code clear in my repository so that it will be easy to port, for example to RLVa.
Have fun !
Marine
Subscribe to:
Posts (Atom)
Posts
