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
Posts
