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 : 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 :
The Linux and Mac versions are proposed by Chorazin at this address :
Have fun !