RLV 2.9.30.1

 Hi !

First of all, apologies for being quiet for so long, all my time is taken by an RL project these days. It might be tied to SL actually but I won't comment on it yet. All I can say is that it's big so it's taking all my time for now. But no worries, there's a lot of work on my plate in SL as well, for example Xuxu needs a bit of love because there are bugs that still need to be fixed. So I'll get to that when I can.

Here is the latest version of the RLV with a few bug fixes and the latest code from LL. This RLV has been ready for release for a month already and I... kind of forgot to ship it. Sorryyy !

 

 

- fixed : couldn't @attach an item located inside a temporary RLV folder (thank you Jenna Huntsman for the heads-up)

- fixed : #RLV/~a/b/c became #RLV/~a/b/c at the next login

- fixed : declining #RLV/~a/b/c created the folders anyway

 

You can download the Windows version from http://www.erestraints.com/realrestraint/

The MD5 hash for the Windows version is :
3dd6953c1e34436f78a8819a1083ea81

The Linux and Mac versions are proposed by Chorazin at this address :
https://sourceforge.net/projects/kokua.team-purple.p/files/RLV/

Have fun !

Marine

Update for all the RR blindfolds

Hi there,

Following the recent addition of @setsphere to the RLV (in v2.9.30), I have updated all the RR blindfolds to add the ability to choose between three methods of blinding, in their "Blindfold" plugin :

- HUD : This is the old-school pre-RLV method, a big prim takes all your view and has only a tiny hole in the middle to let you click through it. It obscures all your view, including your avatar.

- CamDraw : This is the RLV 2.9 vision restriction spheres that you already know.

- SetSphere : This is the RLV 2.9.30 and RLVa 3.4.3 vision restriction sphere that was recently introduced.

The way it works is simple. You choose your preferred method (even while blindfolded, you can change on-the-fly) and the plugin decides which method to use according to the version of your RLV. If the version or your RLV actually supports the method you chose, no problem, the plugin will use it. Otherwise, it chooses another method like this :

- If you chose CamDraw and are not using a RLV 2.9 but are on a RLVa version 3.4.3 or above (in Firestorm or otherwise), then it will choose Setsphere.

- If you chose SetSphere and you are using a RLV 2.9 but not 2.9.30 or above (in which case what are you waiting for, grab the latest version !), then it will choose CamDraw.

- Otherwise it will choose HUD.

 

If you wonder, the blindfolds in the RR line are :

- Scarf Blindfold

- Deluxe Blindfold

- Tape Blindfold

- Iso Blindfold

- Mummy Blindfold

- Remvision

Note : If you are reading this and are a creator of RLV blindfolds yourself, let me help by recapitulating all the versions and what they mean for you when you get a response to your @versionnum request : 

< 2090000 : No camdraw, no setsphere available (that's before RLV 2.9).

< 2093000 : Camdraw only, no setsphere (that's RLV 2.9 but before 2.9.30).

< 3000000 : Camdraw and setsphere are available (that's RLV 2.9.30 and above).

< 3040300 : No camdraw, no setsphere available (that's RLVa prior to 3.4.3).

Other numbers : Setsphere only, no camdraw available (that's RLVa 3.4.3 and above).

I hear often that this update makes your vision spheres white. This is not a bug but a feature actually, the vision spheres take the same color as the root prim of your blindfold. To change that, simply edit your blindfold, check "edit linked" on the edit window, select only the root prim (that's the one highlighted yellow) and set its color to whatever you prefer, the vision spheres will follow. It's a nice hidden little feature if you're tired of the black.

As an extra, there is also an update to the Vixen legs cuffs : their D-rings would not hide when selecting the Invisible style while unlocked. You need a replacement to benefit from this update though.

If you don't want to replace your Vixen cuffs (which I understand, they're a pain to resize), you can fix the bug yourself by following this procedure :

1. Edit the right ankle cuff and check "edit linked" on the edit window.

2. Click on the main part of the cuff only (the one with the strap and rings) so it selects only this part.

3. It should have a weird name. Replace the weird name with another weird name such as this :

$2%Lw:1/0 $3%Lw:1/0 $4%!Lw:1/0 $1567%w:1/0 $0%Lkw:1/0

4. Do the same with the left ankle cuff.

No need to reset or anything, this fixes the bug once and for all.

To update, simply go to any of the following locations :

My Little Shop
Chorazin's store
Roper's Dark Playground
Dark Wishes


Once there, click on the updater and follow the instructions. You do not need to choose "REPLACE" for this one as the Blindfold plugin is the only thing that changes and is a single script, so a simple "UPDATE" is fine. You do need to replace your Vixen legs cuffs though.

 

 

Have fun !

Marine

RLV 2.9.30

Hi !

Here is a new version of the RLV which is dedicated to taking a couple features from RLVa, namely "@setsphere" and the ability to create sub-folders when giving a folder to #RLV directly.

I said in my last post that this was the last time I integrated proofs of concept RLVa commands that make their way into Firestorm without filter. But that was without taking into account Kitty Barnett's new "@setsphere" commands which she worked on for a long time and that are now going to go into Firestorm, once again without any filter.

But I know that users have been eagerly waiting for years for an equivalent of the @cam commands to simulate blindfolds and other vision restrictions that are present in the RLV and Kokua viewers but not in Firestorm which is by far the most popular viewer. It was frustrating for them so I expect scripters will jump on the opportunity to use these commands as soon as they are released. That's why I can't just ignore this new set of commands since they will become popular in no time. Problem is, they are not in the RLV API so if they start using them and I don't do anything, there might be a significant difference once they actually make it to the API and it will be too late then.

So this version (2.9.30) includes Kitty's "@setsphere" commands, working the same way as in RLVa with two key differences that I will explain below.

The second feature is being able to create sub-folders when a script gives a folder to the user's #RLV folder. For example, before this version, giving a folder named "#RLV/~A/B/C" would create a folder "~A/B/C" and put it under #RLV, just like that. Not very handy especially since RLVa would actually create folders "~A", "B" and "C", and organize them the way you'd expect. Since this version here, RLV does the same now which is :

- Create a folder C (in all cases, the last folder in the path is created so we don't pollute an existing folder with new items).

- Create the other folders in turn and organize them, but only if they don't already exist. For example, if your inventory already contains "~A" and "B" inside "~A", it won't create them but it will reuse them, placing the new folder "C" under the existing folder "B" (regardless of the fact that there might already be a folder "C" there since, like I said, the last folder in the path is always created, never reused).

That way, RLV functions exactly like RLVa on these features from version 2.9.30.

Here is the change list :

- Added : Support for @setsphere like in RLVa (with a significant difference : "=force" commands become "=n" commands).

- Changed : Giving a folder to #RLV will now create nested sub-folders if the name of the folder contains slashes ("/").

- Fixed : Defensive fix against a potential crash when using @camtextures (thanks Henri Beauchamp for the heads-up).

You can download the Windows version from http://www.erestraints.com/realrestraint/

The MD5 hash for the Windows version is :
9dc39253a79954e3b926c8d8cc2127d3

The Linux and Mac versions are proposed by Chorazin at this address :
https://sourceforge.net/projects/kokua.team-purple.p/files/RLV/

 

Now, you might have noticed the "significant difference" part in the change list about @setsphere. Read on if you want to know more.

All the "=force" commands designed by Kitty are turned into "=n" commands (*). The reason for this is the way the parameters must be mixed when two or more objects issue identical "@setsphere_mode" commands but with different parameters. In RLVa the result is random, whoever comes last wins or something like that. In RLV they are properly mixed to retain the most restrictive parameters.

For example, if two objects issue "@setsphere_mode:0=n" (that's "restrict the vision with a plain color gradually becoming more opaque over the distance) then one issues "@setsphere_distmax:3=n" and the other @setsphere_distmax:10=n" afterwards, the second command will be retained like the first one but the actual distmax parameter that will be applied will be "3" because it is more restrictive.

(*) Actually the RLV accepts both because there might be scripts already using @setsphere the way Kitty designed it, but the RLV API will only specify "=n", not "=force" because the latter is bound to cause issues and is not consistent with the way the RLV works.

The "force" commands are not retained in the main RLV map, they are forgotten as soon as they are executed, so they cannot be consulted afterwards by scripts. Those "force" commands are "one-shot" commands that are meant to force the avatar to do something, like sit somewhere or teleport, but not configure a command that itself sticks around.

Another difference is the separators in the "@setsphere_param" command. The API will specify that ";" is needed but RLVa takes "/" for the time being. However, "/" is more reserved for folders than actual separators than for multiple parameters (I know, "@tpto" seems to be an exception, it was done this way to facilitate turning an slurl into an actual RLV command, it sounded like a good idea at the time) so ";" it is.

 

Also, it is too soon to add anything to the RLV API about @setsphere. I don't know yet if it is a good idea, for example there are issues with alpha-blending which I am not sure Kitty will be able to solve. I would also like @camdraw commands to be replicated in RLVa, at least becoming synonyms for @setsphere commands. In short, "@setsphere" is still more or less a command in testing.

However Kitty raised an issue with @camdraw commands in RLV : the view seems darkened far before the actual outer limit. There is a reason for this, the spheres are alpha-blended and stack one after the other in a linear way (that's 40 concentric spheres between @camdistmin and @camdistmax).

Problem is, when two alpha-blended surfaces overlap each other, the resulting transparency is a multiplication of both transparencies. As a result, the concentric spheres blend in an exponential way, resulting in an apparent darkness occurring a lot closer than it should. The spheres are placed correctly though and the initial requirement was to make it so @camdrawalpha commands were exact. If you specify that the outer alpha should be 75% (hence 25% transparent), then any white fullbright surface beyond that distance should appear 75% grey, and it works. The reason for this apparent bug is that the spheres are placed linearly. I could place them differently (logarithmically for example) but then this would break existing products using those commands. Adding new @camdraw commands would require to think long and hard on how to mix them.

Anyway, this is the reason why @setsphere is a different set of commands from @camdraw but it would be great to find a way to set a bridge between them, after all they both do the same thing.

 

Have fun !

Marine

RLV 2.9.29

Hi there,

Here is a new version of the RLV, this one is a big one because it includes many new RLV commands on top of a few bug fixes and changes.

Normally it should have been 2.10 but none of the new RLV commands is a real game changer like the vision restriction spheres in 2.9 so it stays a 2.9. It's not really important anyway.

Here is my personal take on the matter of most of the new commands included in 2.9.29. The technical stuff and the actual release notes follow after the part in italics.

Most of the new commands were actually already present in Catznip and I've added them to the RLV for consistency concerns. They're mostly about EEP and how to keep controlling the environment settings with EEP the same way we used to with Windlight, without having to rewrite any script. Problem is, RLVa 2.3 brought in commands with a different syntax than those in the RLV API 2.9.27.

As a result, RLVa was forking even further from RLV and for the sake of the scripters (and their sanity), it is not good to have two nearly but not entirely identical APIs. On top of it, RLVa goes straight into Firestorm (without filter as far as I know, but I'd love to be corrected on that) which is by far the most popular viewer so when a command is added to RLVa, some people assume they are in the RLV as well. This is why most of the new RLV commands in 2.9.29 are taken from RLVa.

There is one simple rule though : if a command is not in the RLV API, it is not an RLV command and scripts should not assume they are.

This is the last time I do this. In order to keep RLV a single API which scripters can rely on for its consistency, all the people working on different implementations of the RLV API must understand that forking is not the most sensible thing to do. Having different implementations that interpret the API differently, or even having commands that are part only of some implementations only confuses users (scripters and end users alike) and increases everybody's workload.

I do understand that when someone wants to add a new command to the RLV API, they have to ask me and I'm the one to do the work on the specification and first implementation (because it has to be tested, right ?), which is not always possible. I consider every suggestion carefully and I say no more times than I say yes, provided I have time at all. So I do understand that other viewers implement their own "test" commands on their side as proofs of concept. I have no problem with that as long as they stay test commands and proofs of concept, but injecting them into popular viewers without getting back to me first is bound to cause issues because suddenly the proofs of concept become mainstream commands without being in the API. That's when things become ugly for scripters and end users.

This applies to Catznip because that's the one that I know about, but there are perhaps others. Of course, if the test commands in Catznip are not transferred into Firestorm when the latter publishes a release, then this whole rant personal take is moot and to be ignored.

Alright, on to the interesting stuff.

- added : A slew of new "setenv" and "getenv" RLV commands, some of them to match the new ones in Catznip : asset, cloudtexture, sunscale, suntexture, sunazimuth, sunelevation, moonazimuth, moonelevation, moonbrightness, moonscale, moontexture.

- added : Support for vectors in the following "setenv/getenv" commands : ambient, bluedensity, bluehorizon, cloudcolor, cloud, clouddetail, cloudscroll, sunlightcolor. Attention : although ";" and "/" are acceptable as separators in the "setenv" command, the "getenv" command will separate the numbers with ";" only to remain consistent with other RLV commands ("/" is supposed to be for folders, it is not a separator).

- added : Show "Typing" above the head of the avatar even when its chat is redirected (this brings a new debug setting named "RestrainedLoveShowRedirectChatTyping").

- added : New RLV command @shownearby (thank you Chorazin Allen for the code).

- added : New RLV command @touchattachother:UUID to prevent from touching a specific avatar's attachments.

- added : New RLV command @share (with its _sec variant as well as share:UUID exceptions) to prevent the user from giving anything to anyone, with exceptions.

- added : New RLV command @sitground to force the avatar to sit on the ground where it stands (in fact it will just sit where it is, even if it is flying, it's not necessarily going to sit on the ground below).

- added : New RLV command @editworld to prevent the user from editing objects rezzed in-world but not their own attachments (no exceptions).

- added : New RLV command @editattach to prevent the user from editing their own attachments but not objects rezzed in-world (no exceptions).

- added : New notification when sitting and unsitting on/from an object or the ground : the viewer says "/sat object legally", "/unsat ground legally" etc.

- added : New RLV command @sendim:<group_name> to add exceptions to @sendim by group. If <group_name> is "allgroups", then all the groups are exceptions.

- added : New RLV command @recvim:<group_name> to add exceptions to @recvim by group. If <group_name> is "allgroups", then all the groups are exceptions.

- added : New RLV command @sendimto:<group_name> to prevent from sending IMs to a specific group. If <group_name> is "allgroups", then all the groups are restricted.

- added : New RLV command @recvimfrom:<group_name> to prevent from receiving IMs from a specific group. If <group_name> is "allgroups", then all the groups are restricted.

- changed : When we press the Esc key, the camera returns to its default position without moving the avatar (this was the case in the past but since EEP it would move the avatar to match the camera instead). To move the avatar to match the camera, simply press one of the arrow keys, like before.

- fixed : Receving a "#RLV/~" folder no longer created the folder under RLV (thank you Sabrina Dumont for the heads-up).

- fixed : Since EEP, the shine was too bright when the camera was outside the light radius (https://jira.secondlife.com/browse/BUG-229436). This is an SL viewer bug, I'm just applying Sovereign Engineer's fix minus the materialF.glsl file because that one makes the shine way too weak.

- fixed : Looking at the Experiences window would show the slurls even when under @showloc

- fixed : Sometimes, moving the camera at certain angles while not rendering the avatar would not render the vision spheres either.

- fixed : @edit should not block spin and grab (thank you Chorazin Allen for the fix).

- fixed : The white flash over the icon of a user in the Communication is now a faded orange, much more readable (thank you Chorazin Allen for the fix).

- fixed : An SL bug blocking the loading of landmarks under certain conditions : https://jira.secondlife.com/browse/BUG-230139. Thank you Chorazin Allen for the fix.

A word about the EEP shine fix. The initial bug arose after some LL fixes about the shine on any surface, namely the shine was now way too bright when you moved your camera outside the light radius (see https://jira.secondlife.com/browse/BUG-229436 for details).

Sovereign Engineer brought a fix for this new bug that fixed it beautifully... except that the shine was now way too low specifically on alpha-blended surfaces, on parts of the surface where the specular map was not completely white. It does not sound like much but it breaks a lot of content that relies on precise materials such as sweat appliers. Suddenly the background shine of the skin became invisible.

To fix this was easy, I could just ignore the materialF.glsl file in Sovereign's commit and all was well. Problem is, Sovereign's commit was also taken by LL, materialF.glsl included, which means soon the SL viewer will show a very weak shine on alpha-blended surfaces, breaking content. After discussing with Sovereign about it, I know that the calculation of the shine after the fix is correct and it was incorrect before, but it has been incorrect since 2015, when materials were introduced in SL, and a lot of content was developed using this flawed specular curve. In my opinion it is too late to go back now. Keeping the fix the way it is now in the SL viewer is bound to make a lot of people, creators and customers alike (who paid for those products) very angry.

For now the RLV keeps the shine the way it always was, even though it is not consistent with how the SL viewer will render it in one of its next iterations. I have yet to decide what I'll do if LL keeps it like this. I'm certainly not going to rework nearly all my products to match the new calculation.

You can download the Windows version from http://www.erestraints.com/realrestraint/

The MD5 hash for the Windows version is :
aaf07aca0eca908025005f3b9818b293

The Linux and Mac versions are proposed by Chorazin at this address :
https://sourceforge.net/projects/kokua.team-purple.p/files/RLV/

Have fun !

Marine