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

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

Saturday, January 31, 2009

RestrainedLife 1.16 is out

Hi there,

As promised, the new 1.16 version of the RLV is out today, with many back-end improvements and a few new features. Let's recap :

* @getdebug, @setdebug to get and set debug settings (for now only AvatarSex and RenderResolutionDivisor, allowing to get/set the gender and to change the "blurriness" of the screen, useful to simulate drugs).
* @getpath, a very handy tool to know the path from the #RLV folder to the object that issues this command. If a parameter is set, it can be either an attachment point or a clothing layer, and in that case the command will return the path to the object/clothing worn there instead.
* @attachthis, @attachallthis, @detachthis, @detachallthis commands, which are shortcuts to a @getpath call followed by an @attach, @attachall, @detach or @detachall command respectively. Very handy to manage outfits without breaking the privacy of the user's inventory !
* @redirchat to redirect public chat spoken on channel 0, to whatever private channel. Useful for gags !
* More "dummy names". Many more.
* llGetAgentLanguage() called from a script to a RLV user will now return the version of the viewer instead of the language setting (which could be just made private anyway). The user is not able to hide it, so the scripts can rely on it. It is much easier than the traditional "@version + listen + timer" way of checking the viewer. This feature is under trial for now, if it bothers too many people before the next big version, I will remove it (otherwise it's here to stay).
* @acceptpermission to automatically accept permissions to attach and to take controls, @denypermission to automatically deny those permissions (the latter takes precedence over the former, of course).

Download it there :
http://www.erestraint.com/realrestraint

I stupidly closed Windows before calculating the hash... so no hash for this version. Next time !

This release is exceptional in a way though : it is based on a Release Candidate SL viewer. I generally avoid doing this as RC viewers change so often, but it has been so long, and RLV 1.16 was ready anyway. SL 1.22.7 is quite enjoyable now (at least for me, compared to 1.22.3 and even worse, 1.21 ! Read the previous post and you'll know why), and I think even this RLV used along with a regular SL 1.22, once it becomes gold and ceases to be a RC, will work without a glitch.

As for my own scripts, as you can see there are 3 new commands that could prove themselves handy... I am in the process of issuing an update to the arms restraints and the blindfold, as well as the Outfit plugin. No rush, but it is in the works.

Have fun !
Marine

Saturday, January 10, 2009

Been quite busy lately !

Hello there and happy new year ! (a bit late I know)

I've been so silent lately, once again that's because I was working hard on the Restrained Life viewer and on a personal project. But before I tell you what I did on the viewer, let me tell you a bit about my own misadventures...

One year ago I had bought a new computer, a brand new Macbook Pro SantaRosa, paid with some of the money I got from SL, in order to extract myself away from Windows and to be able to compile a SL viewer from the source code. In fact I almost bought that computer solely to make the RLV (one week after buying it I could release RLV 1.0a !). My older PC was still on Windows 2000 and that system does not support all the tools needed to compile a SL viewer.

Well, "extracting myself from Windows" was a total failure because I immediately installed WinXP on BootCamp and stayed with it for a year. The MacOS X part had been totally left alone because all my favorite tools were on Windows. But three weeks ago, my Windows system crashed completely and could not be restored. Fortunately all my data could be saved, but it took me more than a week to install a fully working OS X system. And that's where disappointment came : the SL viewer on OS X.4 was totally unusable, at least on my machine. I could only get 1 FPS whatever I did. Being stuck with faulty NVidia drivers sucks, I can tell you that !

Finally I bought Leopard (codename for Mac OS X.5) in which lies new improved NVidia drivers and Hallelujah ! Works like a charm now ! But I have to run SL 1.22 because SL 1.21 is still a slideshow for me. Now what about the RLV ? I mean, I can't live without it ! So I started with Mo's Mac version of RLV 1.15.2 but it was too slow for me (not Mo's fault but my graphic card's), then switched to Hyang's CV for RC 1.22.4, which works fine but I'm not a fan of the old UI. And what if the Lindens suddenly decided to make SL 1.22 the official viewer ?

That's why I got a RLV of my own to compile on SL 1.22.4, and started to work hard on it. So what does it leave me ? I'm now fully on Mac OS X, compiling RLV on Mac, but only for myself. In fact it won't make any difference for the user, because I will still compile and release it for Windows only (through Parallels and a new Windows XP that hopefully won't crash on me again). Why not for Mac too now that I can ? Because it must be done for PowerPC and Intel platforms, has to be stripped from its proprietary libraries... I'm an amateur at it, I'll leave the experts like Mo do it instead :)

So now that I'm operational again, and that you know why I'm not working on SL 1.21 anymore (because I can't, simple as that), here are the improvements I've been working on so far for the next version 1.16 :

* Improve touch and @fartouch, by checking the actual coordinates of the click rather than the center of geometry of the root prim you click on. Thanks to Lindens who overhauled the way the SL viewer handles touches, because it could not be done that way before
* Plugged a loophole around @sittp on some special objects
* Improved speed when under heavy and numerous restrictions. You won't see the difference when unrestricted, but I went from 10 to 20 FPS while completely restrained and restricted (for the sake of testing, y'know *winks*)
* Extended @accepttp to accept tp offers from anyone (before, "@accepttp=add" would not work, on purpose)
* Hide location and names on hovertexts too, exactly like in chat messages. Now radars will have a tougher time overcoming @showloc and @shownames !
* Dots in mini-map won't turn yellow when under @shownames so you can't tell if the person in front of you is a friend or not by looking at the mini-map :)
* Added a way to force a few debug settings, so far AvatarSex and RenderResolutionDivisor. More on debug settings below, because that's an important feature
* Added chat redirect with the "@redirchat:channel=add" command. That was a very popular request ! This restriction will redirect whatever you say on channel 0 to every channel specified with @redirchat (there can be several), without triggering typing nor nodding once the message is sent. Useful for gags !
* Could force sit someone anywhere even when under @sittp
* @getstatus and @getstatusall now prepend a slash ("/") before the actual list of restrictions. I do believe this should not break content (because it won't confuse a llParseString2List command), but if you think it would break a product that you sell, please send me a notecard !

So this is what you can expect for RLV 1.16, which will be released on SL 1.22. Now, 1.22 is still on Release Candidate status so I won't release the RLV yet (it's not even completely finished), but at least you know I'll be ready when it goes gold :) Of course I might make a 1.16 over a RC if it takes too long before going gold, but that would be an exception, not the rule. Release Candidates are far too unstable to be worked from.

Lastly, and yes that post is very long I know (sorry !), here is a word about the debug settings :
As you might know, going to Advanced > Debug Settings in the viewer opens a small window full of exotic words such as "RenderResolutionDivisor", "RenderGlow" and such... they are actually internal variables that can modify the behaviour of the viewer a lot. Some of them are useless, some are crucial, and some are just... fun.

In order to not break someone's viewer (by setting a variable that would make it lag or something, we never know), my approach is a "white list" one, which only accepts some well known settings. At the time of this writing, there are only 2 : "AvatarSex" and "RenderResolutionDivisor". Here is what they do :

* AvatarSex : This one does... nothing by itself. It is "just" the variable that decides your gender, the one you chose when you signed up, remember ? As avatars don't really have a gender, scripts always have to ask the user what gender they are, or rely on "they", "their" and "them" generic words... Now the viewer can be interrogated directly with a @getdebug_avatarsex=2222 command. It can also be set, for example for forced feminization.
* RenderResolutionDivisor : This one is fun, it simulates a lower screen resolution. The higher the number, the lower the resolution. In-world, that makes you see all blurry, like if you were drunk or something. Combined with clever use of @setenv commands, it allows nice effects for sure !

Note : one can set these settings through a script, retrieve their values and also lock them out, exactly like Windlight settings.

Whew ! That's it for now, folks. Hope it does not make you drool too much. Hehe.

Marine

Saturday, December 13, 2008

RestrainedLife 1.15.2

Hi there,

Even more bug fixed in this release, and now the user will be unable to see invisible objects while under an edit restriction (makes sense, if you can't edit you don't have to see any overlay... do you ?). This will be easier for the prison and trap makers out there.

* Invisible folders (starting with ".") were taken into account in the @attachall command
* Items that are neither objects nor pieces of clothing were taken into account in the @getinvwon command
* Skin and hair did not register in the @getinvworn command
* Viewer was freezing when using @getinvworn while RLV debug is active.
* @getinvworn was seeing every item contained directly under #RLV, but did not allow the user to attach nor detach them. As #RLV is not an outfit, now @getinvworn ignores them
* Now when the user is unable to edit things, they are also unable to see any beacon, including invisible objects

Download the viewer and the sources there :
http://www.erestraint.com/realrestraint

MD5 hash for the windows zip :
100e51a3a719bdb6c639b0b97e512e27

Have fun !
Marine

Thursday, December 4, 2008

RestrainedLife 1.15.1

Hi again...

It seems the last version of the RLV had a few (small but annoying) bugs, so here is a v1.15.1 update that fixes them :

* An empty shared folder would, in certain cases, mess the information provided by @getinvworn (saying nothing to wear while there are items there).
* A piece of clothing alone in a folder, and no-mod would be treated as a no-mod object.
* A no-mod object which name contains the name of an attachment point would use it even if it was contained inside a folder which name contains another attachment point.

Get it here :
http://www.erestraint.com/realrestraint

Hash of the viewer for windows : 95e8f42301a64a4aef690fd7165b5f5a

Have fun !
Marine

Sunday, November 30, 2008

RestrainedLife 1.15

Hi !

Here it is, the latest update to the RestrainedLife viewer, and this one is big ! Here is the list of changes, additions and bugfixes :

* Added @accepttp to force the sub to accept a teleport offer sent by an avatar by clicking on "Offer Teleport" on their profile. It will be like being summoned by a Linden, no confirmation box, no message, no Cancel button. Note : this does not deprecate @tpto which teleports to a location instead.

* Added @getinvworn that gives the list of sub-folders under a shared folder like @getinv, but with additional information about which folder contains worn items.

* Added @chatwhisper, @chatnormal and @chatshout to prevent the sub from whispering, chatting normally and shouting respectively. It does not prevent sending the message, it just falls back to another "volume", usually lower (except @chatwhisper that falls back to normal chat). Useful in crowded RP areas like prisons where some inmates like to shout.

* Added @attachall and @detachall to attach/detach shared folders recursively.

* Added @getstatusall to get the list of all the restrictions currently put on the sub, compared to @getstatus which would only give the list of the restrictions issued by the object that sends that command.

* Added @getinv_... to get a current Windlight setting. It was eagerly awaited.

* Reinstated Whisper, for some reason it was gone from the previous version.

* Now, when prevented from standing up, the sub is also unable to teleport.

* The viewer will now even if the settings.xml file is missing the RestrainedLife and RestrainedLifeDebug debug settings. The former is always forced to True anyway, and the latter
will be available to those who have installed the settings.xml file correctly, but most people don't use it (only content creators do).

* The order of HUD attachment points has been tweaked a little so that a HUD that should attach to Top Left will stop attaching to Top and same for Bottom Right and Bottom.

* And a few bugfixes here and there...

Go grab it at :

http://www.erestraint.com/realrestraint

MD5 hash (windows viewer) : ce888d925df030c8916e87d810710715

Have fun !
Marine