Having troubles running RLV 1.19 on Windows ?

Hi !

I have been told of a rare problem occuring to some people when trying to run the latest Restrained Life Viewer (1.19) on Windows. Despite installing it normally, all they get is an error message saying this :

"This application failed to start because the
application configuration is incorrect. Reinstalling the application
may fix the problem."

Not only this message is unclear and vague, but following its only advice does not help at all, it just wastes your time to reinstall everything. I will be frank with you, I have no clue why nobody had that problem before, nor why only a few people do now, and not me. It seems to be happening on freshly installed systems mostly. RLV 1.19 has been built exactly like 1.18, which has been built exactly like 1.17, which has been... well you get the point. I did not change anything to the way it is built.

There is a quick fix to overcome that problem for good and enjoy the latest RLV if you run into this. Simply download this file on the Microsoft website

If you have problems to download it from there, here is another source where you can find the same file :
http://www.softdevlabs.com/Hercules/vcredist_x86.exe

Run a virus check on it, then run it if everything is ok. This executable is supposed to install all the missing Visual Studio C++ runtime libraries that should have been shipped on your operating system. Now, I do not guarantee it will work, it did on the sytem of a friend of mine who experienced that problem, and all is okay now.

Long story short, if you're having this problem, download and run the executable and it should be solved for good.

Marine

PS : Thanks Cleo Collins for the link to the microsoft repository. I only had the softdevlabs one before.

RestrainedLife 1.19

Hello there,

As promised, and actually it took a bit longer than planned because I didn't want to rush it, here is the latest version of the Restrained Life Viewer, v1.19. This one is compatible only with the Second Life Viewer v1.23.4, but I have also uploaded an older version of the RLV on the same page as well for those of you who really dislike the latest SLV (the version I have uploaded is v1.16.1 because I don't have any more recent version of it, sorry about this. I'll try to find one later if I can).

Here is the list of features :

- added : now allows to hide the hovertext floating over one prim in particular (not necessarily the one that issues the command), or all the hovertexts, or only the ones on the HUD, or only the ones in-world. Thank you Lyllani Bellic for the idea.
- added : @rediremote to redirect emotes to private channels like @redirchat does. Now that one was a popular request !
- added : @recvemote to prevent hearing emotes like @recvchat prevents hearing chat, also with exceptions. Not as popular but as handy !
- changed : Now the hovertexts are refreshed immediately when issuing some of the RLV commands (sounds easy, but it was a pain in the **** to implement).
- fixed : @acceptpermission was broken in 1.18. Partly my fault, sorry.
- fixed : chat messages in history were showing a weird dot (".") on a single line when prevented from hearing chat. An old bug.
- fixed : @getpath didn't work in a child prim. Thank you Henri Beauchamp for the tip.
- fixed : "@attach:main=force" unified with ".Backup (main)" !

As usual, you can grab it here : http://www.erestraint.com/realrestraint

The hash for the latest windows zip file is 75c0a1778bfba3906e5e3a758c4ca8b0
The hash for the older version is fd873779f5d5debe839b546f14c6e4fb

Have fun !
Marine

A bit of news

Hi there,

Let me just say that I am still alive and working on the RLV, a few features are giving me a hard time... more on this later. But first let me share a bit of news with you : the former licensing on the code is no more and is now replaced by another one at a higher level. In short, the code of the RLV I publish is now GPL, while the API stays proprietary (in other words maintained by myself). It will calm everyone down (the former license has been the cause of the useless sacrifice of many innocent bytes across the world) and will allow me to focus on more... important matters. You can read it here.

Secondly, and this is the actual purpose of this post, I want to keep you informed with what RLV 1.19 will contain :

- fix : @getpath was not working when called within a child prim (done)
- fix : messages in history were appened a weird dot character on an empty line when prevented from hearing chat (done)
- fix : crash when taking a snapshot... it may be just me, nobody has reported this but so far I can't find a way to fix this. This bug also occurs to me with 1.18.1
- new : @recvemote, works like @recvchat but with... emotes (done, still needs testing, works with exceptions as well)
- new : @rediremote to redirect emotes like @redirchat redirects chat (done)
- new : @showhovertextall to hide all hovertexts (done)
- new : @showhovertext to hide the text floating over one prim in particular (not done yet)
- new : @showhovertexthud to hide the text floating over every prim of a HUD object (not done yet)

So this is why I am so busy again...

Marine

PS : Yes I am aware of @acceptpermission being broken in 1.18, I have just fixed it and tested the fix a few minutes ago, this bugfix will force me to expedite the release so maybe all the new features will not be there yet in the next issue.

RestrainedLife 1.18

Hi !

With the new SL viewer out just yesterday (now 1.23.4), I must hurry and release a compatible RLV as quickly as possible, so here it is. I did some maintenance and integrated Henri's code cleanups, but aside from that there is nothing new. Here are the changes :

- changed : now showing (PG), (Mature) or (Adult) even when the location is hidden.
- changed : the viewer was hiding any llOwnerSay starting with two spaces purposedly, but it seemed to confuse people, it is now only hiding messages that start with a Tab ("\t").
- changed : integrated Henri Beauchamp's code cleanup (I do that every once in a while).
- fixed : the world map and minimap buttons were not turning themselves off properly when @showloc was issued while they were activated.
- fixed : now unable to chat on CHANNEL_DEBUG while under @sendchat (thank you Sophia Barrett).
- fixed : "so and so gave you..." now hides the name while under @shownames.

As always you will find it there :

http://www.erestraint.com/realrestraint

And the MD5 hash is 9a225d9eb08a5d3b3e9779feaf148401

Have fun while I'll work at adding a few new things soon !
Marine

RestrainedLife 1.17

Hiya,

A new version of the RLV is out, with a few improvements and a new command :

- fixed : visual clues about the map and minimap were a bit... clueless at times.
- fixed : llGiveInventoryList with a "#RLV/~..." folder was crashing the viewer if no #RLV folder was present. Thank you MissPony Pelous for the info.
- changed : don't go to third view while in Mouselook and switching back to SL from another application. Doesn't work if the window was minimized or hidden (on MacOS X for example).
- changed : don't allow partial matches on folders prefixes with a "~" character anymore, to avoid taking precedence over the "regular" folders. Thank you Mo Noel for the heads up.
- changed : now PERMISSION_TRIGGER_ANIMATION is also granted when sitting while @acceptpermission is active, even if the object we are sitting on does not actually contain the animation. Useful for rezzable poseballs.
- added : @setrot:angle=force. This command allows you to make the avatar turn to a direction, in radians from the north. This is not possible through a LSL function call so here it is. Be aware that this command is not more precise than the llGetRot() LSL call (for instance the avatar won't rotate if the rotation is less than a few degrees), but it is better than nothing. It is much more precise while in Mouselook, and does not do anything while sitting.

Go get it at
http://www.erestraint.com/realrestraint

MD5 hash for the Windows zip file :
c44b544f9f8626d6c63af7503a4dbf4d

Note : once again the webpage is not up to date, but the windows file is (and the source code). Please be patient, I'm really trying to work around that problem.

Have fun !
Marine

RestrainedLife 1.16.2

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

@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