Restrained Love 2.8.3.4

... And it's about freakin' time... Oh, this thing was live ?

Hi !

Here is the latest version of the RLV, at last... I've been waiting for a while before being able to release this, because there was always something that was too wrong to make it acceptable for public use. The code from the official SL viewer has changed quite a bit in the last month, and many new features have been brought to SL. The two most important ones are Pathfinding and Temporary Attachments.

I have no clue how Pathfinding will work yet. I do know the viewer has to be able to handle them, but from what I understand, for the moment every third party viewers such as the RLV is unable to control it yet. The user interfaces are there, but they are just stubs so they won't do anything. A little like mesh upload back when it was new.

Speaking of mesh upload, it seemed that the new Pathfinding stub library for third party viewers included the code for mesh upload, at least the one given by Linden Lab, which is a stub as well. In other words, to release this "Pathfinding-enabled" (with big quotes because it cannot handle it yet) meant to not being able to upload mesh once again. Unacceptable, so I had to skim through the code to reinstate the open-source mesh upload library. This explains the delay in part.

The other big new feature for SL is "temporary attachments", which means that any object is now able to attach itself on you, whether you own it or not. If you do not own it, the attachment is "temporary" : you do not have it in your inventory and it will be destroyed when you detach it or when you log off. Problem is, the viewer is not given any way to tell a temporary attachment from a regular one. Not being present in your inventory is not good enough, because your inventory could still be loading so even regular attachments would not appear. Worse, a temporary attachment could issue RLV restrictions and commands. To at least err on the safe side, this RLV will not permit an unowned object to use the @acceptpermission command to attach itself on you automatically. It will always have to ask your permission, regardless of how restricted you are. I can only recommend to be extremely careful what you allow to attach on you. I am also convinced that eventually the viewer will be able to tell a temporary attachment from a regular one, but for the moment that is not the case yet, hence this precaution.

Another reason for the delay is that I am fed up, as in really really fed up, of all those viewer crashes. It is unbearable. Unusable. Pathetic. Part of the crashes are due to the open-source JPEG library (the official SL viewer doesn't use it since it has KDU, but Linden Lab does not own a redistributable license for it so we are condemned to using OpenJpeg instead). That library is good, but has severe shortcomings when it comes to handling degraded cases such as corrupt textures, huge textures or memory allocation. All those things are edge cases from this library's standpoint, but routine from the viewer's standpoint. As the crashes are not coming from the viewer, LL would not fix them, and as they are edge cases for the library, the team in charge for maintaining the library would not fix them either. Catch-22. So I worked on strengthening both the library and the viewer myself. It is not perfect, but I have a crash rate way lower than before. This is better than nothing, I guess.

Also I noticed that when @addoutfit was active, the viewer would sometimes have trouble reattaching bodyparts after logging on, resulting in making you a permanent cloud. I tried to fix that, it looks good from the tests I ran, but I'll still keep an eye on it.

Finally I wanted to make aiming in Mouselook even more efficient. Holding the Control key down while aiming now makes your aim more precise (speed x0.25), but not as much as when you're holing the Shift key (speed x0.1). Both keys are cumulative, which means that if you're pressing both, your speed goes down to x0.025 ! Now you can score a shot when zoomed to the max !

Anyway... enough blathering. The features themselves are few but significant I think :

- added : Press Ctrl while in Mouselook to make your aim more precise but still faster than with Shift. Combine Ctrl+Shift for an extreme precision.
- added : Handle the new temporary attachments by not letting @acceptpermission automatically accept attachment requests from objects you don't own.
- changed : Strengthened the viewer against texture crashes (this is most of the work that has been put into this version actually). As a result, it takes at least an hour to crash in crowded areas while on deferred rendering ("lighting & shadows") while it took a few minutes before. There are still artifacts on textures after a while, but at least we are not crashing as often.
- fixed : Alpha textures were not casting or receiving shadows.
- fixed : Made @addoutfit let bodyparts be worn while we are a cloud.


As usual, you can grab the viewer here :
http://www.erestraint.com/realrestraint

And the MD5 hash for the Windows installer is
4436bfdd8e7d7018dc66eb34066baa13

Have fun !
Marine

About temporary attachments and RLV...

Hi there,

I have not posted in a while, because not much has been happening lately. But lately Linden Lab has released their newest feature, "temporary attachments".

In short, temporary attachments are attachments that do not belong to you but attach on your avatar anyway. This is a nice feature for many use cases, but it is problematic with the RLV.

If you are a scripter, see for yourself : http://wiki.secondlife.com/wiki/LlAttachToAvatarTemp

Why is it problematic ? The way I understand it, what distinguishes temporary attachments from regular attachments is this :

1. You do not own them (that's the whole point), but your viewer thinks you do (somewhat).


2. They are destroyed when you log off (hence the "temporary" part).

If a temporary attachment was able to send commands to your RLV, Point 1 would be a real can of worms, a dream for any griefer because they wouldn't need you to wear an open RLV relay to send commands to you, nor to give you an object that you'd have to rez yourself. All they would have to do is to ask for your permission (and then maybe that permission can even be auto-granted, I'm not sure about that yet), and then it is open season.

Furthermore, if a temporary attachment was able to send commands to your RLV, Point 2 would make its interest rather limited, because as soon as the user relogs, all the restrictions would be lost (since the object would be destroyed).

Finally, I cannot think of a use case that would need a temporary attachment to send a RLV command, that would not be possible with a regular attachment or a RLV relay.

In consequence, it seems important to me not to let a RLV execute any command sent by any temporary attachment. Unless (and until) proved wrong, this is the route I'm taking about this new feature.

I just wanted to make that clear early enough so that scripters do not start projects that involve temporary attachments and rely on them sending RLV commands, it wouldn't work and they would be confused.

Feel free to discuss about it on my issue tracker here : https://bitbucket.org/marinekelley/rlv/issue/67/llattachtoavatartemp-and-rlv


Have fun !
Marine