Hi there,
As promised, here is the latest version of the RLV, with many small bugfixes thanks to Kitty Barnett, and the infamous "putinv feature"... which is no longer a command but just a inventory offer redirection. And also two new commands : @sit=n to prevent you from sitting (useful for cages) and @detachme=force to just detach the object that issues that command (useful when streamed after a @clear, just in case you want to avoid race conditions).
Go get it at
http://www.erestraint.com/realrestraint
MD5 hash for the Windows zip file :
dbb12ab3e7d4c6d770b09ae2a9158215
Note : at the time of this writing the webpage still shows the old version and the old (and wrong) date, but the files are up-to-date nonetheless. Please be patient, the page will be updated soon.
Have fun !
Marine
Sunday, April 19, 2009
Saturday, April 11, 2009
@putinv
Hi there,
Sorry for staying silent for so long, I have been working at ironing out a few bugs in the viewer that I had overlooked until now (thanks to Kitty Barnett who made an outstanding job at tracking them down), and also thinking hard about the @putinv command. This is what this post will be about.
What exactly is @putinv ? It is a command that allows one to give you a folder, which would be automatically be put into your #RLV folder without you having to move it manually (sometimes you can't even do that if you don't have access to your inventory anyway). It can be very useful for places that must transform you one way or another, or even just furnitures that need to give you cuffs to work. Problem is, shared folders are based on the principle that whatever is shared is done so *voluntarily* by the user. What is not shared is out of the scope. Plain and simple. @putinv violates this principle in more than one way.
So let me explain my point of view about this command : it is a *dangerous*, but *very nice feature* to have. I do want it into the viewer, but am very cautious about its implementation. Despite my relative silence, I have been lurking all the forums and watching all the discussions about it for some time, one day deciding not to implement it then changing my mind the day after. This one was a real roller-coaster. At the time of this writing (but I am pretty much decided by now), I want to implement it for the next version, but with a lot of safety guards to avoid serious griefing.
Now why exactly is it dangerous ? What in the world could happen ? Well let's say I make an object that locks itself on you after I give it to you and sends outrageous particles around (racist, pornographic, you name it), then you would be tagged as a griefer while you would actually be a victim. And no way you could defend yourself, the Lindens are well known in the "shoot first, ask questions later" community.
So we need safeties. @putinv is a command that acts as a "whitelist", to filter out all rogue inventory offers in the first place and only accept to put into #RLV/whatever the offers coming from objects owned by the avatar specified into the UUID part of the command. And this safety is... pointless. Basically an object that is not owned by the user is allowing itself (through their relay) to mess with their #RLV folder. The only use I see into this command is to prevent someone in another sim from sending inventory that way. If I find a way to check that the inventory offer comes from the same sim, @putinv will have no point anymore. There has been a discussion about preventing @putinv from being accepted if it comes from an object contained into the "drop box" (more on that later), but it would not work either. The object can just use the relay channel to work around this restriction. So in my opinion, the whole feature of "dropping directly into #RLV" does not need a command like @putinv as a safety check, because it would be easy to fool.
Where does this lead us ? Actually the core part of the feature is not @putinv (which is just a safety check) but the inventory redirection itself. When a script calls llGiveInventoryList with a "#RLV/~"-like path (as Henri suggested), the folder does not go to "My Inventory" but to "#RLV/~blahblah". This is a "drop box" in which would go all folders given through that technique. A drop box is necessary because the user does not want their shared root to be cluttered with obsolete folders they didn't even put there themselves. It is also necessary because it is a check in itself : no drop box, no redirection.
The inventory offer must also trigger the dialog box with the Accept/Decline/Mute buttons. I have thought about it through and through, I don't see a safe way to go without it. While the dialog is showing, the folder will have a special character added to its name (yes, another special character I know), to tag it as "do not allow me to be worn yet". Because you know that the folder is already in the inventory while the user has not accepted it yet. It would be moved to the trash should the user press Decline or Mute, but there is a short moment during which the folder is ready and waiting, even if it has not been accepted. Only when the user presses Accept will the special character be removed, rendering the folder totally available for wearing.
Yet another special character could also be used in the name of the folder (oh yeah), this time added by the maker of the object which gave the folder, in order to automatically wear it once Accepted. Just a nice addition to simplify the scripts a little, since most of the time this folder will be worn right away anyway.
The "drop box" (name pending) would be created by the user and not by the viewer itself, very much like #RLV. Sub-folders would be created automatically though, if the drop box exists. By creating it the user will acknowledge that they are to be wary of all inventory offers which name begins with "#RLV/~" because they will be worn automatically. A lot of communication needs to be done about that step, which is crucial to the whole automatic inventory sharing feature.
So to recap :
* @putinv might not even be necessary if I find a way to check the inventory comes from the same sim.
* The name provided in llGiveInventoryList is all we need to know what to do with the folder and where to put it.
* Creating the drop box would be a manual step the user has to take. Using a debug setting would have given the same result, but would be harder and less intuitive for the user. And would be machine-dependent.
* Folders would go into that drop box only.
* Folders would not be wearable until the user has Accepted the inventory offer.
* Pressing Mute would mute the object and trash the folder even if @shownames is active (hiding the name on the dialog box).
* The inventory offer dialog box is necessary. Without it many things could happen behind the scenes, without anybody noticing anything. This would open the door to "worm-like" objects. Remember : to the Lindens, the user is responsible for accepting and using inventory items. Being forced to do so by a custom viewer like the RLV is no excuse.
* While I like Henri's idea of rejecting @putinv commands issued from objects contained into the drop box (assuming I use @putinv at all), it is very easy to overcome if the user is wearing a relay. So I'm not sure I will implement that check.
Ok, so this is where I am now. If nothing comes up I should implement it soon, but as you can see this is pretty close to Henri's chosen solution. Therefore it should not be far from what he already tested in his Cool Viewer.
And last but not least, that would end this awkward situation of having a feature in another RLV which is not in mine. And this particular one is very controversial, I could have rejected it altogether if I were lazier.
Marine
Sorry for staying silent for so long, I have been working at ironing out a few bugs in the viewer that I had overlooked until now (thanks to Kitty Barnett who made an outstanding job at tracking them down), and also thinking hard about the @putinv command. This is what this post will be about.
What exactly is @putinv ? It is a command that allows one to give you a folder, which would be automatically be put into your #RLV folder without you having to move it manually (sometimes you can't even do that if you don't have access to your inventory anyway). It can be very useful for places that must transform you one way or another, or even just furnitures that need to give you cuffs to work. Problem is, shared folders are based on the principle that whatever is shared is done so *voluntarily* by the user. What is not shared is out of the scope. Plain and simple. @putinv violates this principle in more than one way.
So let me explain my point of view about this command : it is a *dangerous*, but *very nice feature* to have. I do want it into the viewer, but am very cautious about its implementation. Despite my relative silence, I have been lurking all the forums and watching all the discussions about it for some time, one day deciding not to implement it then changing my mind the day after. This one was a real roller-coaster. At the time of this writing (but I am pretty much decided by now), I want to implement it for the next version, but with a lot of safety guards to avoid serious griefing.
Now why exactly is it dangerous ? What in the world could happen ? Well let's say I make an object that locks itself on you after I give it to you and sends outrageous particles around (racist, pornographic, you name it), then you would be tagged as a griefer while you would actually be a victim. And no way you could defend yourself, the Lindens are well known in the "shoot first, ask questions later" community.
So we need safeties. @putinv is a command that acts as a "whitelist", to filter out all rogue inventory offers in the first place and only accept to put into #RLV/whatever the offers coming from objects owned by the avatar specified into the UUID part of the command. And this safety is... pointless. Basically an object that is not owned by the user is allowing itself (through their relay) to mess with their #RLV folder. The only use I see into this command is to prevent someone in another sim from sending inventory that way. If I find a way to check that the inventory offer comes from the same sim, @putinv will have no point anymore. There has been a discussion about preventing @putinv from being accepted if it comes from an object contained into the "drop box" (more on that later), but it would not work either. The object can just use the relay channel to work around this restriction. So in my opinion, the whole feature of "dropping directly into #RLV" does not need a command like @putinv as a safety check, because it would be easy to fool.
Where does this lead us ? Actually the core part of the feature is not @putinv (which is just a safety check) but the inventory redirection itself. When a script calls llGiveInventoryList with a "#RLV/~"-like path (as Henri suggested), the folder does not go to "My Inventory" but to "#RLV/~blahblah". This is a "drop box" in which would go all folders given through that technique. A drop box is necessary because the user does not want their shared root to be cluttered with obsolete folders they didn't even put there themselves. It is also necessary because it is a check in itself : no drop box, no redirection.
The inventory offer must also trigger the dialog box with the Accept/Decline/Mute buttons. I have thought about it through and through, I don't see a safe way to go without it. While the dialog is showing, the folder will have a special character added to its name (yes, another special character I know), to tag it as "do not allow me to be worn yet". Because you know that the folder is already in the inventory while the user has not accepted it yet. It would be moved to the trash should the user press Decline or Mute, but there is a short moment during which the folder is ready and waiting, even if it has not been accepted. Only when the user presses Accept will the special character be removed, rendering the folder totally available for wearing.
Yet another special character could also be used in the name of the folder (oh yeah), this time added by the maker of the object which gave the folder, in order to automatically wear it once Accepted. Just a nice addition to simplify the scripts a little, since most of the time this folder will be worn right away anyway.
The "drop box" (name pending) would be created by the user and not by the viewer itself, very much like #RLV. Sub-folders would be created automatically though, if the drop box exists. By creating it the user will acknowledge that they are to be wary of all inventory offers which name begins with "#RLV/~" because they will be worn automatically. A lot of communication needs to be done about that step, which is crucial to the whole automatic inventory sharing feature.
So to recap :
* @putinv might not even be necessary if I find a way to check the inventory comes from the same sim.
* The name provided in llGiveInventoryList is all we need to know what to do with the folder and where to put it.
* Creating the drop box would be a manual step the user has to take. Using a debug setting would have given the same result, but would be harder and less intuitive for the user. And would be machine-dependent.
* Folders would go into that drop box only.
* Folders would not be wearable until the user has Accepted the inventory offer.
* Pressing Mute would mute the object and trash the folder even if @shownames is active (hiding the name on the dialog box).
* The inventory offer dialog box is necessary. Without it many things could happen behind the scenes, without anybody noticing anything. This would open the door to "worm-like" objects. Remember : to the Lindens, the user is responsible for accepting and using inventory items. Being forced to do so by a custom viewer like the RLV is no excuse.
* While I like Henri's idea of rejecting @putinv commands issued from objects contained into the drop box (assuming I use @putinv at all), it is very easy to overcome if the user is wearing a relay. So I'm not sure I will implement that check.
Ok, so this is where I am now. If nothing comes up I should implement it soon, but as you can see this is pretty close to Henri's chosen solution. Therefore it should not be far from what he already tested in his Cool Viewer.
And last but not least, that would end this awkward situation of having a feature in another RLV which is not in mine. And this particular one is very controversial, I could have rejected it altogether if I were lazier.
Marine
Tuesday, March 24, 2009
A useful piece of advice
Hello there,
I have just received a message from a Linden asking me to encourage all of you who are building RestrainedLife viewers for any platform, to change llversionviewer.h to set the correct "Restrained Life" channel instead of the original "Second Life" one. This is because Linden Lab is gathering statistics on how spread each custom viewer is used, according to the channel used on login.
This is important because it will help LL decide whom to include in the "early disclosure" list of custom viewer maintainers, which members are able to receive warnings about security holes before the public, hence allowing them to publish patched viewers before the wave hits the shore. In other words, you and your users would not have to wait several days before getting an updated version.
For the same reason, please do not incitate your users to put a "--channel" in the shortcut they use to run the Restrained Life Viewer, or that would defeat the code hereunder.
So please, don't forget to apply this change to your code before releasing a new viewer :
In llcommon/llversionviewer.h
- const char * const LL_CHANNEL = "Second Life Release";
+ const char * const LL_CHANNEL = "Restrained Life Release";
Thank you for your attention !
Marine
I have just received a message from a Linden asking me to encourage all of you who are building RestrainedLife viewers for any platform, to change llversionviewer.h to set the correct "Restrained Life" channel instead of the original "Second Life" one. This is because Linden Lab is gathering statistics on how spread each custom viewer is used, according to the channel used on login.
This is important because it will help LL decide whom to include in the "early disclosure" list of custom viewer maintainers, which members are able to receive warnings about security holes before the public, hence allowing them to publish patched viewers before the wave hits the shore. In other words, you and your users would not have to wait several days before getting an updated version.
For the same reason, please do not incitate your users to put a "--channel" in the shortcut they use to run the Restrained Life Viewer, or that would defeat the code hereunder.
So please, don't forget to apply this change to your code before releasing a new viewer :
In llcommon/llversionviewer.h
- const char * const LL_CHANNEL = "Second Life Release";
+ const char * const LL_CHANNEL = "Restrained Life Release";
Thank you for your attention !
Marine
Wednesday, March 18, 2009
RLV license
This post is meant to be a bit formal, because I feel I have to remind a few things about how the Restrained Life Viewer ("RLV" for short) is licensed. It has a double purpose : to protect my work and to reassure the users and scripters about the consistency and the unicity of the RLV.
First of all, let me make a distinction between the RLV and its implementation (source code and executable). This license only applies to the RLV itself, neither to its source code nor to its executable, which are both licensed underthe GPL v2 (see http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt) whatever license the source code of the original SL viewer, that the RLV modifies, says it is (at the time of this writing, it is licensed under LGPL v2.1), in short you have the right to read the source code, modify it, build it and redistribute it at will. The source code used to be licensed under a loose copyright but it was upsetting a lot of people for no real benefit on my side, and was not practical to defend. It was just there to fulfill the purpose of this very post, but it was done at the wrong level.
Being the original author and maintainer of the Restrained Life Viewer, and recognized by everybody as such, I am legally granted authors' rights on its concept (and have been since the beginning, see http://en.wikipedia.org/wiki/Authors%27_rights). I will not even attempt to rephrase what "authors' rights" stands for in plain English, the definition and scope are already complex enough, but this post is meant to state ground rules about what third-parties can do with the RLV, and what they cannot do, in other words it is focusing on my moral rights upon this project and not at all on my economic rights. In Europe moral rights are strongly enforced while in the USA they are not bound to copyright. This is not a problem since all I want to do is to protect my work from defamation and unfair competition.
The Restrained Life Viewer is a modification of the original open-source Second Life Viewer to allow in-world scripts to control some of the behaviours of the Viewer (as in "send commands and requests to it"). The following rules state what a third-party viewer must comply to in order to pretend to be a Restrained Life Viewer :
* It must implement every command specified in the RLV API and no other (see https://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLifeAPI), and this API is written and maintained by Marine Kelley (me) only. It may improve a command by "making it better" (for instance fixing a bug) as long as it doesn't change the way scripts use it through the API. The key concept here is "interoperability", which means that a script designed to be RLV-enabled should work the same with all the RLVs built by different developers, regardless of their implementations. If it does not work the same with one viewer that claims to be a RLV, then that viewer cannot claim to be a RLV, even remotely (it would have to be clearly distinguishable from my work by any user).
* It must not do what a script or a set of scripts can do. This is to protect scripters from being threatened by viewer developers when it comes to making and selling SL content. The exception to this rule is : it is allowed to do what a script can do if the regular SL viewer can do it as well.
* It must not break content. In other words, when a command is implemented, you must assume that some people are selling products that rely on it and are making a living from it. If the command is flawed, repair it. If it is not broken, don't fix it.
* It must not compromise the privacy of its user or of any other person. This means the RLV must *not* and shall *never* send your IMs to whatever third-party object or server, log your password, force you to send money to something or someone, or delete your inventory items.
If your viewer cannot comply with at least one of the points stated hereabove, you do not have the right to make it pretend it is a RLV, or even related to it. The fact that you base it on my code or not is irrelevant.
Please note : All the points above are only applicable if you are within the scope of the RLV. For instance, adding a button to teleport to a favorite location without using a landmark is ok for me, since it is not related to the concept of RLV, even if a script can actually do that.
To address potential concerns, I am not licensing the source code of the RLV under anything else than the same license as the SL viewer, but only making sure that the RLV stays consistent regardless of whoever publishes it, so that in-world scripts do not have to wonder whether they are interacting with one flavor of the viewer or another. This is the key concept and the most important thing to keep in mind when implementing a RLV. I will never claim royalties on any kind of use of the RLV either, it is meant to stay free (I couldn't even if I wanted to anyway).
I also do know that a few concepts inside the RLV are not my ideas in the first place, for instance sending a folder to the viewer inside the #RLV folder directly. There are a few other examples and I am not claiming authors' rights on any of them.
A good idea would be to identify different flavors of the RLV by recognizable names, the one I publish being "Marine Kelley's RLV" for instance (people who publish a RLV identical to mine but on other platforms are also welcome to use the same name if they want, so that the end-user knows what viewer they are using, but this is not an obligation). But don't forget to put credit where credit is due (as stated by the GPL & LGPL) and to tag your changes to the original source code clearly.
This post is also not meant to "paralyze" the creativity of other people who would like to work on the RLV. In fact it is the exact opposite : like the code of the SL viewer, they are free to modify it and redistribute it at will, and I am going to be more flexible regarding patches that people send me (this is a different matter that will be explained in another post).
To sum it all up, this "license" is not really one. It is merely here to define what a RLV is, rather than to tell you what you can do with its code. These are two totally different things. The older license was saying "you can't distribute a modified version of my code" while this new one is saying "you can't call the viewer you distribute a RLV if it is not working like the original RLV". Although both sound identical, they are not applying to the same level of abstraction.
Finally, a word to those who believe I am doing this "for the glory" : I am not. I was already well-known before even launching the RLV, and the latter has been successful because my name was on it, not the other way around. This viewer is my gift to the community, I have been putting my reputation at stake in it, so I am just asking people to show respect to the accomplished work. If you want to be acknowledged, work with the project, not against it.
PS : I am a very busy person, and this post is very likely to bring me a lot of concerned messages. If you try to contact me to ask whether you can do this and that without infringing this license and I don't respond, please assume the answer is "I have certainly already answered this before and if it becomes a popular concern I will communicate about it on this blog". But until I effectively communicate about it, either in a private or a public fashion, please assume the answer is simply "I'm afraid not".
Please note : Since v2.8 the RLV is able to manage a blacklist of commands. This means the user has a way to make their viewer ignore the commands that could potentially break their fun, and they do this through a debug setting. I am fully aware that this conflicts with the following rule, that I therefore removed :
" * It must not provide a way to inhibit or ignore a command by using a Debug Setting or other customization means, because the scripts must be able to safely assume that every single command they send will be executed once they are aware the user is using a RLV. The exceptions to this rule are potentially harmful commands (those which can be abused by griefers, like giving inventory directly inside the #RLV folder), commands that some system configurations cannot handle (such as @setenv) and the "RestrainedLife" Debug Setting itself since it makes the viewer cease to be a RLV totally when set to False. "
I know that modifying the license just to add a feature is bad, but this feature was so popular a request, that I sensed that this clause was actually getting in the way. That's why it's removed. I apologize in advance for any unintended confusion it might create.
First of all, let me make a distinction between the RLV and its implementation (source code and executable). This license only applies to the RLV itself, neither to its source code nor to its executable, which are both licensed under
Being the original author and maintainer of the Restrained Life Viewer, and recognized by everybody as such, I am legally granted authors' rights on its concept (and have been since the beginning, see http://en.wikipedia.org/wiki/Authors%27_rights). I will not even attempt to rephrase what "authors' rights" stands for in plain English, the definition and scope are already complex enough, but this post is meant to state ground rules about what third-parties can do with the RLV, and what they cannot do, in other words it is focusing on my moral rights upon this project and not at all on my economic rights. In Europe moral rights are strongly enforced while in the USA they are not bound to copyright. This is not a problem since all I want to do is to protect my work from defamation and unfair competition.
The Restrained Life Viewer is a modification of the original open-source Second Life Viewer to allow in-world scripts to control some of the behaviours of the Viewer (as in "send commands and requests to it"). The following rules state what a third-party viewer must comply to in order to pretend to be a Restrained Life Viewer :
* It must implement every command specified in the RLV API and no other (see https://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLifeAPI), and this API is written and maintained by Marine Kelley (me) only. It may improve a command by "making it better" (for instance fixing a bug) as long as it doesn't change the way scripts use it through the API. The key concept here is "interoperability", which means that a script designed to be RLV-enabled should work the same with all the RLVs built by different developers, regardless of their implementations. If it does not work the same with one viewer that claims to be a RLV, then that viewer cannot claim to be a RLV, even remotely (it would have to be clearly distinguishable from my work by any user).
* It must not do what a script or a set of scripts can do. This is to protect scripters from being threatened by viewer developers when it comes to making and selling SL content. The exception to this rule is : it is allowed to do what a script can do if the regular SL viewer can do it as well.
* It must not break content. In other words, when a command is implemented, you must assume that some people are selling products that rely on it and are making a living from it. If the command is flawed, repair it. If it is not broken, don't fix it.
* It must not compromise the privacy of its user or of any other person. This means the RLV must *not* and shall *never* send your IMs to whatever third-party object or server, log your password, force you to send money to something or someone, or delete your inventory items.
If your viewer cannot comply with at least one of the points stated hereabove, you do not have the right to make it pretend it is a RLV, or even related to it. The fact that you base it on my code or not is irrelevant.
Please note : All the points above are only applicable if you are within the scope of the RLV. For instance, adding a button to teleport to a favorite location without using a landmark is ok for me, since it is not related to the concept of RLV, even if a script can actually do that.
To address potential concerns, I am not licensing the source code of the RLV under anything else than the same license as the SL viewer, but only making sure that the RLV stays consistent regardless of whoever publishes it, so that in-world scripts do not have to wonder whether they are interacting with one flavor of the viewer or another. This is the key concept and the most important thing to keep in mind when implementing a RLV. I will never claim royalties on any kind of use of the RLV either, it is meant to stay free (I couldn't even if I wanted to anyway).
I also do know that a few concepts inside the RLV are not my ideas in the first place, for instance sending a folder to the viewer inside the #RLV folder directly. There are a few other examples and I am not claiming authors' rights on any of them.
A good idea would be to identify different flavors of the RLV by recognizable names, the one I publish being "Marine Kelley's RLV" for instance (people who publish a RLV identical to mine but on other platforms are also welcome to use the same name if they want, so that the end-user knows what viewer they are using, but this is not an obligation). But don't forget to put credit where credit is due (as stated by the GPL & LGPL) and to tag your changes to the original source code clearly.
This post is also not meant to "paralyze" the creativity of other people who would like to work on the RLV. In fact it is the exact opposite : like the code of the SL viewer, they are free to modify it and redistribute it at will, and I am going to be more flexible regarding patches that people send me (this is a different matter that will be explained in another post).
To sum it all up, this "license" is not really one. It is merely here to define what a RLV is, rather than to tell you what you can do with its code. These are two totally different things. The older license was saying "you can't distribute a modified version of my code" while this new one is saying "you can't call the viewer you distribute a RLV if it is not working like the original RLV". Although both sound identical, they are not applying to the same level of abstraction.
Finally, a word to those who believe I am doing this "for the glory" : I am not. I was already well-known before even launching the RLV, and the latter has been successful because my name was on it, not the other way around. This viewer is my gift to the community, I have been putting my reputation at stake in it, so I am just asking people to show respect to the accomplished work. If you want to be acknowledged, work with the project, not against it.
PS : I am a very busy person, and this post is very likely to bring me a lot of concerned messages. If you try to contact me to ask whether you can do this and that without infringing this license and I don't respond, please assume the answer is "I have certainly already answered this before and if it becomes a popular concern I will communicate about it on this blog". But until I effectively communicate about it, either in a private or a public fashion, please assume the answer is simply "I'm afraid not".
Please note : Since v2.8 the RLV is able to manage a blacklist of commands. This means the user has a way to make their viewer ignore the commands that could potentially break their fun, and they do this through a debug setting. I am fully aware that this conflicts with the following rule, that I therefore removed :
" * It must not provide a way to inhibit or ignore a command by using a Debug Setting or other customization means, because the scripts must be able to safely assume that every single command they send will be executed once they are aware the user is using a RLV. The exceptions to this rule are potentially harmful commands (those which can be abused by griefers, like giving inventory directly inside the #RLV folder), commands that some system configurations cannot handle (such as @setenv) and the "RestrainedLife" Debug Setting itself since it makes the viewer cease to be a RLV totally when set to False. "
I know that modifying the license just to add a feature is bad, but this feature was so popular a request, that I sensed that this clause was actually getting in the way. That's why it's removed. I apologize in advance for any unintended confusion it might create.
Friday, March 13, 2009
RestrainedLife 1.16.1
Hi there,
Finally LL released their latest viewer version 1.22, so here is the RLV that works with it : 1.16.1.
It is not only a "catch-up" version, it contains a lot of small improvements and bugfixes, plus reattaches locked items automatically when they are detached by a script... even by one they contain !
Grab the viewer here :
http://www.erestraint.com/realrestraint
The hash for the Windows zip file is fd873779f5d5debe839b546f14c6e4fb
Edit : If you had performance problems with this version, please download again. This was due to a settings.xml file that was not appropriate for a Windows viewer... since it was the one I used on my Macintosh. I was lazy and just pasted it in the zip, but it is not good enough. The new one is the one coming from the official SL viewer v1.22.11, so I expect it should work better. The executable itself and the patch have not changed one bit, only the settings.xml file.
Have fun !
Marine
Finally LL released their latest viewer version 1.22, so here is the RLV that works with it : 1.16.1.
It is not only a "catch-up" version, it contains a lot of small improvements and bugfixes, plus reattaches locked items automatically when they are detached by a script... even by one they contain !
Grab the viewer here :
http://www.erestraint.com/realrestraint
The hash for the Windows zip file is fd873779f5d5debe839b546f14c6e4fb
Edit : If you had performance problems with this version, please download again. This was due to a settings.xml file that was not appropriate for a Windows viewer... since it was the one I used on my Macintosh. I was lazy and just pasted it in the zip, but it is not good enough. The new one is the one coming from the official SL viewer v1.22.11, so I expect it should work better. The executable itself and the patch have not changed one bit, only the settings.xml file.
Have fun !
Marine
Monday, February 23, 2009
Denypermission woes
Hi,
A lot of people have expressed concerns about the latest addition to the RLV, and to my HUD system : the @denypermission command. For the layman, that command makes you automatically deny all attach permission requests, making your restraints totally secure (they could be kicked off with easy scripting otherwise). First of all, please understand that this is not a trivial problem at all, in fact it is quite fundamental. Secondly, be sure that I am putting myself into this dilemma, and will do all I can to find a solution soon. No ETA, just as soon as possible.
Here are my views on the subject, though :
* When an object is locked, nothing, absolutely nothing should be able to kick it off until it is unlocked. Without @denypermission there is a way, and nothing else can fix it.
* @denypermission does not break content, but it certainly makes using several auto-attaching HUDs a pain in the ....... , to the point of making it next to impossible to bear.
* The whole rewriting of my HUD system was actually triggered by the introduction of @denypermission. I won't enter into details, but that was a very fundamental change. Now I have to revert that, and that doesn't make me a happy bunny.
* I do want to make my HUD system plugin-based (to have a user menu), but not so soon, it's too early. I need to discuss a few things first, and to think it all thoroughly. So making this command optional would not be possible right now.
So... @denypermission is not the way to go. It breaks content. It makes the experience a pain for the user. It eats your babies. There must be another way. At the time of this writing, here is the solution I'm thinking of :
-> To have the viewer automatically re-attach a locked item that had been detached by a script. Although not trivial, the latest functions I have added to the RLV make this possible (namely the ones that I created to add @getpath). The only problem is... what would happen if the item gets kicked off by another one that immediately locks itself ? We would have a forever loop, that would either crash the sim or at least lag the viewer badly (or both). I would like to find a way to "delay" the locking of an item that has been attached by a script. If I can do that, then there will be no need for @denypermission anymore (although it will stay here, it might be useful in some cases where we need ultra security, namely when nothing should ever be detached at any time).
(Edit : I have found an elegant solution, now to find the time to implement and test it...)
In a nutshell, yes I hear ya, @denypermission is evil. It is necessary, but maybe overkill in the way I use it in my products. So there will be an update to my HUDs again, if you're annoyed by the current behaviour. Just be patient, I have many other things to do atm.
Marine
PS : For those who wonder whether it is the same girl who got herself spanked by several people at SH today... yes ! It is the same one. I get spanked and then I write technical stuff. Bear with me. lol
A lot of people have expressed concerns about the latest addition to the RLV, and to my HUD system : the @denypermission command. For the layman, that command makes you automatically deny all attach permission requests, making your restraints totally secure (they could be kicked off with easy scripting otherwise). First of all, please understand that this is not a trivial problem at all, in fact it is quite fundamental. Secondly, be sure that I am putting myself into this dilemma, and will do all I can to find a solution soon. No ETA, just as soon as possible.
Here are my views on the subject, though :
* When an object is locked, nothing, absolutely nothing should be able to kick it off until it is unlocked. Without @denypermission there is a way, and nothing else can fix it.
* @denypermission does not break content, but it certainly makes using several auto-attaching HUDs a pain in the ....... , to the point of making it next to impossible to bear.
* The whole rewriting of my HUD system was actually triggered by the introduction of @denypermission. I won't enter into details, but that was a very fundamental change. Now I have to revert that, and that doesn't make me a happy bunny.
* I do want to make my HUD system plugin-based (to have a user menu), but not so soon, it's too early. I need to discuss a few things first, and to think it all thoroughly. So making this command optional would not be possible right now.
So... @denypermission is not the way to go. It breaks content. It makes the experience a pain for the user. It eats your babies. There must be another way. At the time of this writing, here is the solution I'm thinking of :
-> To have the viewer automatically re-attach a locked item that had been detached by a script. Although not trivial, the latest functions I have added to the RLV make this possible (namely the ones that I created to add @getpath). The only problem is... what would happen if the item gets kicked off by another one that immediately locks itself ? We would have a forever loop, that would either crash the sim or at least lag the viewer badly (or both). I would like to find a way to "delay" the locking of an item that has been attached by a script. If I can do that, then there will be no need for @denypermission anymore (although it will stay here, it might be useful in some cases where we need ultra security, namely when nothing should ever be detached at any time).
(Edit : I have found an elegant solution, now to find the time to implement and test it...)
In a nutshell, yes I hear ya, @denypermission is evil. It is necessary, but maybe overkill in the way I use it in my products. So there will be an update to my HUDs again, if you're annoyed by the current behaviour. Just be patient, I have many other things to do atm.
Marine
PS : For those who wonder whether it is the same girl who got herself spanked by several people at SH today... yes ! It is the same one. I get spanked and then I write technical stuff. Bear with me. lol
Saturday, February 14, 2009
A few words about 1.16.1
Hello there,
Just a quick post to talk about RLV 1.16.1 that will be due when Linden Lab release their SL viewer v1.22 as the official version.
Firstly, it has been confirmed that RLV 1.16 does NOT work with SL 1.22.9 RC. It certainly did with 1.22.8, but it seems to be crashing now. Just to make one thing clear, I can NOT publish a new viewer every time a new RC hits the shelves. Otherwise I would spend my time building viewers. As you might know, it is now more difficult for me to compile on Windows than before. So please be patient, and if you really can't wait, the Cool Viewer is the tool of choice for you.
Secondly, after many discussions about llGetAgentLanguage, I have decided to make it back the way it was before, that is sharing the language settings of the user, and not the version of the RLV. There are several reasons, ethical and technical, the latter defeating all the advantages of actually using that function. Namely, llGetAgentLanguage does not return the version right away after logging on. It starts with an empty string. That would have led the script to be forced to wait (with a llSleep or something) before checking the version.
Thirdly, there was a bug with @getpath which would give away the exact path to whatever piece of clothing the user is wearing (not attachments), whether they were shared or not. If the point of sharing outfits is to "expose" them, the point of not sharing them is to NOT expose them, that makes some sense.
Fourthly, @set/getdebug_avatarsex was not working at all. Really not at all. Fixed now (thanks Henri).
Fifthly (?), while 1.16 was hiding the names of the avatars around under @shownames, then first names, then last names (if any), it was a little too intrusive, and could really mess some messages up. Mo Noel, for instance, had that problem because her first name, "Mo", was getting replaced by "an agent" or something. This lead to very difficult to read messages... I would like to use regular expressions to make the replacement smarter, unfortunately this "string replacement" is a function that is called a lot in the viewer, so it has to stay very basic.
Sixthly (??), and that has only a loose tie with the viewer, some people have complained about the latest update to the blindfold, which hides names and location when locked. While I do believe that seeing the names over the heads is unrealistic, recognizing the "voices" is not, so I hear ya, and have issued an update to the RealRestraint_HUD objects. This means that if you are annoyed with that behaviour, you just have to update your blindfold, but also all your arms restraints (wrist cuffs, wrist shackles, wrist ropes, wrist straps), because the change takes place in the HUD. This only requires a "Type 4" update ("Extensions only"). Then to detach your current HUD (because it does not detach by itself), and let the updated object rez its new one.
Hope this makes things clearer. Have fun !
Marine
Just a quick post to talk about RLV 1.16.1 that will be due when Linden Lab release their SL viewer v1.22 as the official version.
Firstly, it has been confirmed that RLV 1.16 does NOT work with SL 1.22.9 RC. It certainly did with 1.22.8, but it seems to be crashing now. Just to make one thing clear, I can NOT publish a new viewer every time a new RC hits the shelves. Otherwise I would spend my time building viewers. As you might know, it is now more difficult for me to compile on Windows than before. So please be patient, and if you really can't wait, the Cool Viewer is the tool of choice for you.
Secondly, after many discussions about llGetAgentLanguage, I have decided to make it back the way it was before, that is sharing the language settings of the user, and not the version of the RLV. There are several reasons, ethical and technical, the latter defeating all the advantages of actually using that function. Namely, llGetAgentLanguage does not return the version right away after logging on. It starts with an empty string. That would have led the script to be forced to wait (with a llSleep or something) before checking the version.
Thirdly, there was a bug with @getpath which would give away the exact path to whatever piece of clothing the user is wearing (not attachments), whether they were shared or not. If the point of sharing outfits is to "expose" them, the point of not sharing them is to NOT expose them, that makes some sense.
Fourthly, @set/getdebug_avatarsex was not working at all. Really not at all. Fixed now (thanks Henri).
Fifthly (?), while 1.16 was hiding the names of the avatars around under @shownames, then first names, then last names (if any), it was a little too intrusive, and could really mess some messages up. Mo Noel, for instance, had that problem because her first name, "Mo", was getting replaced by "an agent" or something. This lead to very difficult to read messages... I would like to use regular expressions to make the replacement smarter, unfortunately this "string replacement" is a function that is called a lot in the viewer, so it has to stay very basic.
Sixthly (??), and that has only a loose tie with the viewer, some people have complained about the latest update to the blindfold, which hides names and location when locked. While I do believe that seeing the names over the heads is unrealistic, recognizing the "voices" is not, so I hear ya, and have issued an update to the RealRestraint_HUD objects. This means that if you are annoyed with that behaviour, you just have to update your blindfold, but also all your arms restraints (wrist cuffs, wrist shackles, wrist ropes, wrist straps), because the change takes place in the HUD. This only requires a "Type 4" update ("Extensions only"). Then to detach your current HUD (because it does not detach by itself), and let the updated object rez its new one.
Hope this makes things clearer. Have fun !
Marine
Subscribe to:
Posts (Atom)
Posts
