RealRestraint update to v1.29

Hi !

As promised in this post, here is an update to all the restraints in the RealRestraint brand to v1.29 !

The highlight of this update is the ability to detach items that are not necessary for a particular lock, and to reattach them later even after the lock has changed. That's what I call "late-detaching" and "late-attaching", in other words "detach after locked" and "attach after locked" respectively. The purpose is double. It is about decreasing the rendering cost of what your avatar by letting you detach what is not needed, and sparing attachment slots at the same time. You can wear 38 attachments at any given time and mesh bodies tend to take a lot of those slots (one for the body, one for the HUD, usually two for the feet and two more for the hands, add one for the head and one for its HUD if you use a mesh head, that's a total of 8 slots just to look good). So any way to spare slots is welcome, especially when wearing full sets of restraints that can take more than 10 slots for some.

For example, if you wear the Vixen cuffs and lock them in "U-binder", like this :

... you do not need to wear the chain parts nor the left wrist as they're not used by this lock. You can see these parts in "highlight invisible" (Ctrl Alt T), in red :

The chain parts are the little spheres around the waist and over the crotch.

You can also see the left wrist cuff in red around the left wrist, partly hidden by the u-binder part.

Those parts can be detached even though the cuffs are locked.

After having detached those unnecessary parts, that's at least 3 attachment slots freed !

Now suppose you have indeed detached those parts and changed the texture from the default black to a mix of pink and white :

Then you get locked into another pose, let's say ""H+E front", which features chains around the torso and you are not wearing them, plus the left wrist cuff that you are not wearing either. There's no chain, the left cuff is missing, it is a mess :

 

No back chain, no crotch chain...

... and no left wrist cuff.

All you have to do is wear those missing parts (and you can detach the u-binder part since it is not used by this lock), the missing cuffs automatically appear, change texture to become white and pink like the rest, and the chains appear, without you having to do anything. And now everything looks fine again :

All fixed !

To obtain this result, however, a full replacement of each set is required. Of course this update is not mandatory, and of course any new product bought after the update is live will already be updated. I am very aware of how annoying it is to resize all the parts of a set, which is why I have made the copy/paste shape scripts.

Please note that it is not because a part is invisible that it can be detached. Some parts are invisible and yet necessary for the current lock. For example, the right wrist part of most of the RR sets is where the main scripts are located, so of course this part is always required and therefore RLV-locked. A few other parts are always needed too, such as the light harness and crotchrope of the Siren set, because those two parts may be made visible at any time, regardless of the lock.

Conversely, it is not because a part is visible that it cannot be detached. For example, there has been a popular request for the Vixen and Elegance sets to let the elbow parts show while locked without a pose. I had considered making a Style plugin for them, but this would have been useful only for one particular lock, not very efficient. Instead, I have made it so the elbow parts are visible while on the "Lock" lock, but not RLV-locked. That way you have the choice to wear them or not.


There is another new feature included in this update : the ability for any third-party plugin to register itself to Vulnerable, and be given access to whoever clicks on the restraint while not being the keyholder. Until now only the *Leash, *Outfit and *Sit plugins could be accessed, but now if your third-party plugin has one of its parameters set to "vuln" (case unimportant), then Vulnerable will show it on its menu. Only the name of the plugin will be displayed, not its parameters. For example, if your third-party plugin is named "*MyThirdPartyPlugin.param1.param2.vuln", then Vulnerable will show "MyThirdPartyPlugin" on its menu. I realize as I am writing these lines that there is no "..." after the name to indicate that it opens another menu, but it's ok, that doesn't keep it from working. I'll add the ellipsis in a future update, it is only a cosmetic issue.


Aside from the "late-detaching" and "late-attaching" and the addition to Vulnerable, the update includes a few other changes and fixes, so let me write the whole list of changes here :

* Late-detaching, late-attaching
- Ability to detach any item that is not necessary for the current lock.
- Attaching items that were not worn but necessary for the current lock will automatically synchronize themselves for the textures, tints, leashes and particle chains as soon as they are worn.
- Known issues : The "Pet" pose in Mummy Legs and Deluxe Straps Legs re-locks the arms in "Pony" whenever rezzed (not a real issue, but can be surprising);  Mummy plays a lock sound when rezzed, once again harmless but can be surprising. I will work on those issues later and see if I can fix them, as they area a side-effect of the feature above.

* Vixen and Elegance sets
- Elbow cuffs are now visible on "Lock", but can be detached manually.

* Vixen set
- There was a script error when struggling in "Hogtie Tight", a missing animation (thanks JimHC Lykin)
- The "Black+silver" button in the "Saves" menu of the VixenTex plugin was oddly placed (cosmetic change, but it was annoying).

* Vulnerable plugin
- Any third-party plugin that has "vuln" as one of its parameters (the part between "." in the name, if any) will be on the Vulnerable menu like *Leash, *Outfit and *Sit.

* Deluxe Gag & Blindfold
- Removed the "bridge" script that made textures be changed on both items at the same time, as it would cause issues when applying a preset (the item the preset is applied to would look fine, but the other one would look only partly textured, due to SL throttling the messages, as there are so many).

* Siren & Shibari ropes
- Replaced the original colors with the ones used in the Latex catsuits, socks & gloves, Highbinder, Deluxe Straps, Body Harness, Deluxe Gag and Pretty Mummy.

* Deluxe Straps legs
- For some reason the waist part was no-mod. I'm surprised nobody called me about it. Of course if your waist strap is no-mod and you don't want to update just for that, send me an IM and I will give you a mod one.


Please note : The following products do not benefit from this update as they either do not have secondary items or their secondary items are always used. So no need to update these if you don't want to.

Armbinder
Scarf Blindfold
Body Harness
Isolation Hood & Blindfold
Jammer
Serious Shackles
Slave Crate
Tape Gag & Blindfold

I repeat, this update is in no way mandatory, it is just a convenience for you if you need to free some attachment slots when you are heavily bound, or if you are concerned with your own avatar rendering cost.


You can find an updater at the following places in-world :

My little shop

The Little Shop of Kink

Roper's Dark Playground

Chorazin's main store

It looks like an orb floating above a pedestal, just click on it and follow the instructions.


Have fun !

Marine

RLV 2.9.19.2

Hi !

This version of the RLV only contains a hotfix for a very recent bug, making it so you couldn't touch anything when under the @edit restriction. D'oh !

Anyway it's fixed in 2.9.19.2, sorry for the inconvenience !

You can grab the RLV for Windows here :

www.erestraints.com/realrestraint

Direct download :
www.erestraints.com/realrestraint/RestrainedLoveSetup.exe

And the MD5 hash for the executable is
4f61031d7bc18fd07bc1629516ccb2be

Have fun !

Marine

ARC and what to do about it

Hello again,

Lately Linden Lab added a new feature to the SL viewer that would automatically simplify the rendering of all avatars which rendering cost is above a threshold that you set in your preferences. Every avatar above that threshold is rendered without its attachments, save for their rigged ones, and without any texture. Instead the look like gummy bears, or jelly dolls, or whatever the term is. Although the calculation of the rendering cost is rather old (5 years old at the time of this writing), it had always been purely informative. Now the viewer automatically acts upon the result of this calculation.

This is all good and well as it lightens the load on the rendering part of your viewer, meaning more FPS for you. Very useful in clubs, it helps trimming down the costly attachments that you might not be aware of, and motivates content creators to optimize their stuff (I'm talking about future products, of course, it is very difficult to optimize what has already been made and released since you must make the customers update, when at all possible).


The formula and invisible surfaces

Only, the formula used for the calculation gives alpha-blended textures a high weight. I understand the reasoning behind this, as alpha-blended textures (aka 32-bit textures, textures with a 8-bit alpha channel so they can be partly transparent, as opposed to 24-bit textures that can only be opaque) are very heavy on the rendering, and not only on the SL rendering engine. If you've played a game with explosions that are rendered with sprites of fire and smoke, your computer would likely slow down when you were close enough. This is because of a high number of partly transparent textures stacked upon each other, which makes the renderer suffer, even worse as they are close to your camera.

What I find weird is that completely invisible surfaces (i.e. surfaces which alpha is 0, or "Transparency 100" in the viewer, regardless of whether the actual texture is 24 or 32 bits) are also rendered. Why ? No clue. Why render what you can't see in the first place, right ? But it doesn't matter, the formula punishes invisible surfaces the same as partly transparent ones.

Now, I'm not saying that invisible surfaces should not be counted in the formula at all, because even if they are not rendered, they are still managed by the viewer every frame. It has to decompose the scene into objects, objects into prims, prims into surfaces, group surfaces into pools, and only then can it check whether a surface is invisible or not. The rendering is only a part of the computation cost of a surface. So to me invisible surfaces should be counted in the formula, but not as high as partly transparent ones.

This has a direct impact on some of my products like the Deluxe Straps and the Deluxe Gag. These are the two products with the most invisible surfaces, simply because they morph a lot (they are the products offering you the most customization). Their rendering cost, according to the formula, is rather high : individual attachments in this set are worth 34k average. This is not due to a poor design though, I have optimized the topology of the deluxe straps prior to release, knowing that there would be a LOT of straps. There could certainly be fewer triangles but not a lot fewer or the straps would look blocky. So why the high cost ? Because most surfaces are invisible, so they are taken as transparent surfaces, regardless of whether their textures are opaque or not.

But there is no reason to render these surfaces at all unless they are actually visible, right ? Yet they are rendered anyway and this makes people think those items are badly optimized because it sounds like there are many times more triangles to render than there really are. And it makes other people around you derender you automatically if their threshold is set too low. It is detrimental to my work in the long run.

I am not the only creator to be harmed by that formula. Any item that has options (for example weapons) have parts that hide and show themselves, most use transparency to do that, very few actually shrink prims and move them inside the bulk of the object. Some do, but it isn't always possible for technical and usability reasons.


So what to do about it ?


Update of my products

I mentioned a way to mitigate that in this post. In short, I said that I was thinking of a way to let the user detach the items that are not used in the current lock. For example, when you are locked in "Arms tight" in the Deluxe Straps, you do not need to actually wear the chest part, so this would let you remove it. Problem is, what if you got yourself locked in "Box" afterwards ? Well, you'd be able to re-attach the chest part after being locked, it would become visible and what's more, its textures would synchronize if the colors were changed in the meantime. And you'd be able to remove the upper arm part afterwards since it would not be locked anymore, always allowing you to wear only the required attachments but not necessarily the whole set all the time. This has the added benefit of sparing some attachment slots for you to use otherwise.

This works well now, after days of coding and testing, I have yet to release that update to all my products, it will take a few more days because there are a few other things to do first. The downside is that it will require full replacements, including the secondary items. I know it is a pain, and I'm afraid there is no way around that since the "slave" script of every single secondary item needs an update. And since they are no-mod and their names contain their parameters, I cannot not give away a template script for you to replace the old ones with. Of course that update will not be mandatory, it's just for convenience. Another downside is that this trick does not help the Deluxe Gag at all since it is in one piece. A third downside is that it doesn't help other creators, since it is an update to my products only.

I had been suggested to transform my "set alpha to 0 when unlocked" to "set texture to transparent and alpha blend mode to alpha mask when unlocked". While this is a good idea because fully alpha masked textures are not rendered (not even with "highlight invisible", which is also beyond me), this requires me to make a script that retains all the textures to set when the item is locked again. After giving it much thought, I decided not to do it, because it would make the products a lot more fragile. It would be very difficult to resit a reset, a relink or a texture change with such a feature. Possible, but very costly and error-prone, and would not allow you to customize with your own textures anymore (some people like to do that and I hope they continue).


Update of the RLV

I have just released a new version of the RLV that does not render invisible surfaces at all, i.e. surfaces which alpha is 0, or "transparency" is 100 in the viewer. Well, except when "highlight invisible" is active (that's Ctrl-Alt-T, to see invisible surfaces in red). Really, it is as simple as that. I have detailed the change here with a patch file that is very small, and to my knowledge, without any side-effects. I have run benchmarks and they do demonstrate that invisible surfaces are indeed not rendered. I have also tested that it doesn't interfere with the ability to touch such a surface. It makes sense not to render invisible surfaces anyway, because invisible surfaces on rigged mesh attachments are already not rendered and therefore do not have as high a weight in the ARC formula.

Please note that if a surface does not have its transparency set to 100 but bears a fully invisible texture (such as the "*Default transparent texture" one in the Library), it WILL be rendered even if you won't see it. The change only checks the alpha, not the actual data of the texture, it would be too slow and defeat the purpose. This makes sense, also, because such a texture may be useful when you want to render clear plastic. The texture itself is invisible but may shine in the light.

I understand what modifying this formula means though. There is at least one LSL function that uses it (llGetObjectDetails with OBJECT_RENDER_WEIGHT), so suddenly it would return different results... So if LL decided to make that change to the formula, they would have to modify the viewer and possibly the sim software at the same time, after thinking hard about the consequences on the values fed to the scripts. I have also no idea how much lighter invisible surfaces are on the viewer when you include my modification, all I have is some FPS benchmarks which are a bit extreme (more than 100 surfaces stacked upon each other, you don't see that in public places unless someone wants to grief you). Which means tests have to be made and it takes time and money.

Of course, I will be the first to admit that the modification I made is pretty basic, if LL decided to implement this change they would certainly not do it the same way. But they know the rendering engine well, I don't. I know other parts but the rendering engine is like black magic to me. I didn't really pay much attention during my OpenGL classes, I admit.



So, to recapitulate :

- My whole RealRestraint line of products will get a full update in the near future. This update won't be mandatory (no update is), but if you want the ability to lower the number of attachments in a set, and by extension your rendering cost, this is the way to go. The update is not available yet, I will send a notice and write a blog post when it is.

- The RLV no longer renders invisible surfaces unless you highlight them. It may increase your FPS a little, depending on the amount of invisible surfaces around you. Frankly, I did not see a difference unless I had a hundred surfaces stacked upon each other, but I'm pretty sure it will help in clubs. Unlike my products, the update of the RLV is available already so have at it (you can download it here).


Have fun !

Marine

RLV 2.9.19.1

Heya,

Despite my many tests, it just so happens that the rendering fix I introduced in RLV 2.9.19 had a little (but annoying) bug in some special circumstances. So special that I could barely reproduce them, let alone see them occur during the tests in the first place as those special circumstances did not occur in my sim. Namely, some transparent but non-invisible surfaces could vanish from the view depending on the angle of your view. But not all surfaces, they had to be part of an object with transparent, opaque and invisible surfaces, all of them at the same time. The best example of that would be mesh windows, but then again, not all of them (and seemingly not the ones in my region).

So I had to completely redo the fix, switching back to the first technique I used in the JIRA ticket, with an addition to make sure the surfaces update themselves when necessary (it has to be done when you activate and deactivate "highlight invisible", and in a way that doesn't freeze the viewer even though it requires a visual update of all the prims around). And even as of now, I have no clue why my former fix didn't work in all cases, as it was pretty much a copy/paste of some LL code with very little change. At least it works now. Let's just hope I will not discover some silly bug like "transparent surfaces will not show when you are higher than 1024 m, facing West, at night, on a Sunday, wearing black shoes". I kid but the bug in RLV 2.9.19 was almost that specific !

There is another bug I stumbled upon and that I fixed in this version : apparently you couldn't alt-click to focus in world through a HUD anymore. Slightly puzzling but it's fixed now.

So, to recap :

You can grab the RLV for Windows here :

www.erestraints.com/realrestraint

Direct download :
www.erestraints.com/realrestraint/RestrainedLoveSetup.exe

And the MD5 hash for the executable is
e78889251652dcb4353fcc0c5b7bb7cf

Have fun !

Marine

RLV 2.9.19

Hi !

Here is the latest version of the RLV with a few interesting changes, including the one I discussed lately. I will not go into details about the rendering change here, I prefer to write a full blog post about it later, because it goes hand in hand with a change in my own products. Even though both changes are, actually, independent. I know, I'm being vague, don't worry everything will become clear soon, I just don't want to dwell on this in these release notes. In short, the change is about not rendering surfaces which alpha is 0.0, to avoid rendering things that we cannot see anyway, making the viewer a bit faster. This change is related to the new Avatar Rendering Complexity changes that came to the SL viewer.

Apart from the small (but important) rendering optimization that will be discussed in a later post, there are a couple additions to the list of IM commands the viewer responds to. You already know that if the other party types "@version" in an IM to you, they get the version of your RLV. Likewise, if they type "@getblacklist", they get the list of RLV commands you have blacklisted (it is empty by default).

Starting from this version, if they type "@list" in the IM window they get the list of RLV restrictions you are currently under (as if you had clicked on the RLV > List Restrictions menu item), and if they type "@stopim", your IM window will automatically close, but only if you are under the "@startim" restriction at that moment (wouldn't make sense otherwise). That way they control when the conversation ends, and not you.

I want to point out that these IM commands are not part of the RLV API specification like script commands, but recommended. I will add such a note to the API soon. They're there for convenience, but since they do not change how the viewer responds to RLV commands coming from scripts, they are not mandatory.

And if you don't want to have to remember all those commands, I have added shortcuts to them to the small menu of the IM window :

Of course these menu entries (and the commands that go with them) are available only in P2P conversations. Not group chat, not conferences and not nearby chat, where they are greyed out. Thanks Angelina Sinclair for suggesting to add those menu entries.


Here is the list of changes :

- added : If someone types "@list" in an IM with you, they get the list of RLV restrictions you are currently under (exactly like the "List RLV restrictions" menu item in the RLV menu).

- added : If someone types "@stopim" in an IM with you and you are under the "@startim" RLV restriction (preventing you from starting IMs), your IM window is closed automatically and both of you get feedback. If you are not under a "@startim" restriction, then the other party gets feedback too to show that it didn't work.

- added : 4 menu items in the small menu button for each IM window, to automatically send "@version", "@getblacklist", "@list" and "@stopim" in IM so you don't have to remember them and type them manually.

- improved : The viewer no longer renders surfaces which alpha is 0.0 except when "highlight invisible" is active. See BUG-20168 for details.

- fixed : @touchme did not allow you to touch the object issuing this command when you were under @touchall (thanks Kyrah Abattoir for the heads-up).

- fixed : Prevent click-dragging when @edit is active.


You can grab the RLV for Windows here :

www.erestraints.com/realrestraint

Direct download :
www.erestraints.com/realrestraint/RestrainedLoveSetup.exe

And the MD5 hash for the executable is
5ce1ccdf5cb36a949b6254dba012edfa

Have fun !

Marine

RLV 2.9.18.2

Hi,

Another day, another bug fix... Only this time the bug wasn't introduced in a recent version. In fact I think it has been there for a while, but I only heard about it now from a friend, and I do believe that it requires an urgent fix. The bug caused a crash when someone sent you an item or a teleport offer while you were under the @startim RLV restriction, and didn't have a session with this person. I did not notice it before because I seldom use @startim myself, but with the latest version of my Gag plugin I suspect it will be used more often, and I don't want to see a surge of crashes because of it, hence the urgent fix.

In my defense, the crash did not occur in my own code, but was indirectly caused by it. To be perfectly exact, the function that opens an IM session is supposed to be called only after an action of your own (you give an item, or you open a new IM session, etc), and it is restricted by @startim. Meaning that when @startim is active, the session is not created. Only in some cases (when someone gave you an item or a TP offer, but NOT an IM), that function was called too and expected to always return a new session. As @startim prevents it the session was not created but the viewer didn't check for its validity, tried to use it anyway, failed, freaked out and crashed.

I'm sorry for the flurry of new versions lately, but I felt that those two bugs (this one and the one before it) were serious enough to deserve an immediate bug fix.

You can grab the RLV for Windows here :

www.erestraints.com/realrestraint

Direct download :
www.erestraints.com/realrestraint/RestrainedLoveSetup.exe

And the MD5 hash for the executable is
ca72c35573caffcc183e4294a1ca5a42

Have fun !

Marine

PS : Happy 4th of July to all Americans !

RLV 2.9.18.1

Heya !

So it seems that the latest version of the RLV (before this one) introduced a new bug after a bug fix. Namely the "can't alt-right-click on an object to sit on it when in Mouselook, through a HUD prim". This had the unfortunate side-effect of not being able to left-click on any HUD while in Mouselook. D'oh.

So here is a new version with a bug fix for the bugged bug fix. *nods*


You can grab the RLV for Windows here :

www.erestraints.com/realrestraint

Direct download :
www.erestraints.com/realrestraint/RestrainedLoveSetup.exe

And the MD5 hash for the executable is 
c4026b106afc28faaf34a2c794082b43

Have fun and sorry for the inconvenience,

Marine

RLV 2.9.18

Hi !

Here is the latest version of the RLV, to get up-to-date with the latest official SL viewer, with avatar rendering complexity and all, as well as a few bug fixes and improvements (in my opinion and experience). Plus, I notice this version is solid with outfits, I did not notice one outfit error at all in a week of testing ! No ghosted attachment upon TP, no missing attachment upon relog, let alone locked ones, and no "incorrect CoF version" message on the console either. It finally feels reliable (*).

I also added a debug setting named "RestrainedLoveAutoTempAttach" (menu "Advanced", "Show debug settings", type "RestrainedLoveAutoTempAttach" and change its value) to automatically allow a temporary attachment to attach, you can switch it to TRUE and FALSE at will without needing a relog, knowing that it won't let a "debit" permission (or any other) get through.


Here is the change list :

- added : Debug setting "RestrainedLoveAutoTempAttach" (default to FALSE) to automatically accept attachment permission requests coming from a temporary attachment. Please note that this does NOT allow a temporary attachment to automatically be granted any other permission, even if it is bundled into the same request, to protect against griefing and fraud.

- changed : Improved the way silhouettes are rendered (now faster and cleaner).

- changed : When forced into Mouselook and sitting on an object, moving the mouse wheel back resets the pitch of the view, like it does when standing.

- fixed : @attachallthis and its siblings did not seem to prevent attaching a wearable or body part.

- fixed : "Add to Current Outfit" wasn't working anymore.

- fixed : We couldn't Alt-right-click on an object to sit on it while in Mouselook, with a prim blocking the view (even a transparent one).


You can grab the RLV for Windows here :

www.erestraints.com/realrestraint

Direct download :
www.erestraints.com/realrestraint/RestrainedLoveSetup.exe

And the MD5 hash for the executable is :

a23a25b531daec17330cf9e1b3819d05



On a side note...

I want to talk about the new avatar rendering complexity (aka "jelly dolls") feature. It is a new-old one because it has been there for a while (we already knew it under the codename "ARC"), but now it is no longer just a score, it actually makes the viewer react to it by hiding the avatars around you that have a score higher than a threshold that you define. This is good when you are in a club, surrounded with many avatars and some of them wear a lot of stuff. I won't go into detail, it is all explained here, but I would like to point out that the formula used to calculate complexity is strongly biased against transparent surfaces, even fully transparent (invisible) ones. Like each transparent triangle counts for four.

Problem is, my products rely heavily on hiding and showing parts of restraint sets, especially the Deluxe Straps. Now before you ask, no the Deluxe Straps (or any other restraint I make) do not slow down your viewer or the viewers of the people looking at you. Well to be perfectly honest, I do go from 80 FPS down to 78 when wearing them (locked or not), so there is a rendering cost, but it is very small and to be expected.

But it doesn't matter, the formula says that transparent stuff must be punished, and punished it is. And I am not even talking about sculpties which are punished even more due to their high triangle count even for a 64x64 texture. So imagine an invisible scultpy ! Which means that I have to work on a solution to avoid making people think that my products are poorly designed. They're not, their complexity is perfectly acceptable when visible, because I took care of optimizing them when I designed them. It's just that the formula increases their rendering "score" when unlocked simply because they are invisible. As a result, you have a risk of being viewed as a "jelly doll" when wearing them unlocked, so I have to do something about it.

Such a "feature" may be detrimental to business, and not only to mine.

My idea at the moment is to "simply" allow the user to detach secondary items in a set that are not used by the current lock. For example the u-binder of the Vixen set when locked in "hands back", or the left leg straps of the Deluxe Straps when locked in "Tight". It isn't difficult and would allow you to spare some attachment slots even when locked, so it would definitely be an improvement and not just a defensive action on my part. It would however require you to get a replacement of the whole set you'd want to update, and to use only the new set (meaning you'd have to resize it again, either manually or with the copy/paste shape scripts).

I need to think long and hard before I even start working on it, because although allowing to detach what is not locked is rather easy, there is the problem of attaching a part after locking the set, if that part is supposed to be used by the current lock. It has to request all kinds of data from the main part (visibility, lock state, textures, leash...). So it is not as trivial as it looks, it may require significant changes to a number of scripts.

We're not there yet anyway so for now, if you really care about your own avatar complexity score and want to trim it down, simply don't wear the parts you won't need, before getting locked in your favorite restraints.

Or if you're like me, you won't care about it at all and will wear whatever you like when you're with your friends. You and your friends will likely decide to bump the slider all the way up to "No Limit" in the Graphics Preferences anyway and quickly forget about that "feature".

Have fun !

Marine


(*) Famous last words.