Hello again,
Another day, another RLV.
Yesterday morning, I got an IM from Gibson Firehawk telling me that, well, the Z offset fix is well and all, but was only working locally...
*facepalm*
So, one sacrificed Sunday later, here is a new version of the RLV that, this time, does propagate the Z offset to other users around you. A little explanation is in order, though, because it now shows that it will certainly not work exactly the way it used to before SSA was rolled out across the grid. As close as possible, but not exactly the same.
Before the SSA rollout, you would just use your Z offset slider to decide how much higher or how much lower your avatar would appear to be (I say "appear" for a reason : in fact your avatar bounding box was taller or smaller, the change of altitude was only visual and only a side effect of it).
Now, the Z offset directly tweaks the Hover value of your shape. Which means your shape must be modifiable in the first place, and also that its new Hover value needs to be validated by the sim, and that takes some time.
So here is how I did this :
1. You use your Z offset slider like before, and it will in fact feel faster and smoother than before, simply because the change will be only local at first.
2. You leave your Z offset slider alone and one second later, things start getting interesting : your RLV will move your avatar a little lower or a little higher than what you wanted, don't fret, this is normal. It will stay there until the sim responds with a confirmation, updating your shape and putting you at the exact altitude you had requested. It's slow, it takes a few seconds, sometimes the sim will even refuse to update your shape with some excuses like "not found" or "service unavailable" but your viewer will keep insisting until the sim gives up and finally updates your shape. If it really doesn't want to update, you can move your Z slider again to retry, but that shouldn't be necessary too often.
3. You play with your Z offset slider again, say to go back to zero. Once again your altitude will change the way you want, then a second later will be off for a little while. I know this is annoying but this is the only way I found to overcome a nasty bug in the update : the altitude that is acknowledged by the sim is never the one you requested. It is the one you wanted, multiplied by 1.25. Don't ask me why, I have no clue, and it has wasted a lot of my time trying to figure that out. Note to Henri : I don't do things the same way you do in your viewer so I had to use a factor to correct that behavior. Please don't kill me. Hehe.
One thing you need to know : it also works when sitting (the former version didn't), but it just won't show in local, you have to wait until the sim updates your shape. This is annoying because it does not let you tweak your position as precisely as when you are standing, and I don't know how to make it work in local when sitting. Maybe I'll find a solution in the future, if any.
So there you have it. It works, but I must say I am not proud of the code I had to write to overcome this at all. It's dirty, it's hacky, it's messy and this factor thing just doesn't make sense. But it's there and it had to be fixed.
You can grab the viewer here :
http://www.erestraint.com/realrestraint
The MD5 hash for the Windows package is
256c0b003e315bebe3d433a72622e198
Have fun !
Marine
PS : You may have noticed there is no RLV 2.8.5.4... I have made an oops with the version number, 2.8.5.4 should be this one, but heh.
Monday, August 26, 2013
Saturday, August 24, 2013
RestrainedLove Viewer 2.8.5.3 with Z offset fix
Hi there,
So I was hoping Linden Lab would do something about our Z offset feature... you know, the slider on the top menu bar that lets you make your avatar hover above the ground or sink. It was handy for adjusting your position when sitting on a furniture, or when your avatar is simply not standing on its feet (sitting, kneeling, laying...). There is even an RLV command that uses this feature, to adjust your height automatically with a script.
This was very useful feature and the recent Server Side Appearance rollout across the grid broke it. Linden Lab were called out on this, and Nyx Linden took it on his personal time to provide us a replacement, by adding a "Hover" value in the avatar's shape, that does more or less what the old Z offset did. Problem is, while doing its job, this replacement was barely acceptable in our case because not as precise, cumbersome and needing your shape to be modifiable. So I was hoping LL would do something about it because, I don't know, it is a bad idea to break features the users are accustomed to.
But no.
Instead of that, the whole grid was rolled out this week and sure enough, the Z offset was broken and inoperable. You could play with the slider all day, nothing would happen. I didn't have time to look into this breakage before yesterday, but thanks to Henri Beauchamp's work in his Cool Viewer, it is now working again, as well as before, and the RLV command @adjustheight (which relies on it) still works like before. The only problem is that your shape must be modifiable now. No modifiable shape, no Z offset (we can call it an offset now, can't we Henri ? *wink*). This is going to be a problem for people who sell and for those who buy no-mod shapes, but it is that or nothing.
Another thing : the SSA rollout also broke the temporary upload feature, so I removed the checkboxes from the Upload and the Snapshot windows. But fret not, you can use the standard "Local" feature instead, which is faster and cleaner :
When you want to apply a texture on a face or prim, notice the "Local" radio button on the texture chooser. Click on it, then click on "Add", select one or more textures to add to the local cache in the explorer, then click on one of the textures that appear in the list to apply it to your face. The neat trick is that this texture will update itself automatically as soon as it is modified on your hard drive. For example, when you work on it in Gimp or Photoshop and save it, switch back to your viewer and you will see the result right away. No additional action is required. It's neat and is a time saver over the old "temporary upload" which was taking a lot of time for each upload.
I would like to thank warmly Nyx Linden and Henri Beauchamp for both taking on their personal time to fix that breakage. Thanks guys !
So here it is, a new version of the RLV with the fix and you can adjust your Z offset again. Sorry for the wait !
You can grab the viewer here :
http://www.erestraint.com/realrestraint
The MD5 hash for the Windows package is
1dd2c82af6b5591a3e006f2645202ad2
Have fun !
Marine
So I was hoping Linden Lab would do something about our Z offset feature... you know, the slider on the top menu bar that lets you make your avatar hover above the ground or sink. It was handy for adjusting your position when sitting on a furniture, or when your avatar is simply not standing on its feet (sitting, kneeling, laying...). There is even an RLV command that uses this feature, to adjust your height automatically with a script.
This was very useful feature and the recent Server Side Appearance rollout across the grid broke it. Linden Lab were called out on this, and Nyx Linden took it on his personal time to provide us a replacement, by adding a "Hover" value in the avatar's shape, that does more or less what the old Z offset did. Problem is, while doing its job, this replacement was barely acceptable in our case because not as precise, cumbersome and needing your shape to be modifiable. So I was hoping LL would do something about it because, I don't know, it is a bad idea to break features the users are accustomed to.
But no.
Instead of that, the whole grid was rolled out this week and sure enough, the Z offset was broken and inoperable. You could play with the slider all day, nothing would happen. I didn't have time to look into this breakage before yesterday, but thanks to Henri Beauchamp's work in his Cool Viewer, it is now working again, as well as before, and the RLV command @adjustheight (which relies on it) still works like before. The only problem is that your shape must be modifiable now. No modifiable shape, no Z offset (we can call it an offset now, can't we Henri ? *wink*). This is going to be a problem for people who sell and for those who buy no-mod shapes, but it is that or nothing.
Another thing : the SSA rollout also broke the temporary upload feature, so I removed the checkboxes from the Upload and the Snapshot windows. But fret not, you can use the standard "Local" feature instead, which is faster and cleaner :
When you want to apply a texture on a face or prim, notice the "Local" radio button on the texture chooser. Click on it, then click on "Add", select one or more textures to add to the local cache in the explorer, then click on one of the textures that appear in the list to apply it to your face. The neat trick is that this texture will update itself automatically as soon as it is modified on your hard drive. For example, when you work on it in Gimp or Photoshop and save it, switch back to your viewer and you will see the result right away. No additional action is required. It's neat and is a time saver over the old "temporary upload" which was taking a lot of time for each upload.
I would like to thank warmly Nyx Linden and Henri Beauchamp for both taking on their personal time to fix that breakage. Thanks guys !
So here it is, a new version of the RLV with the fix and you can adjust your Z offset again. Sorry for the wait !
You can grab the viewer here :
http://www.erestraint.com/realrestraint
The MD5 hash for the Windows package is
1dd2c82af6b5591a3e006f2645202ad2
Have fun !
Marine
Friday, August 16, 2013
RestrainedLove Viewer 2.8.5.2
Hi there,
Ok, third release in a week, and I'm supposed to be in vacation...
But this release fixes invisiprims ! Thanks to Henri Beauchamp's help, a little bit of code that was getting in the way of having invisiprims work was removed, the result was tested, and here you go ! New version of the RLV.
Now, I was wrong on some account : I thought nobody cared about invisiprims but me, because two products of mine needed them to work. That was incorrect, I'm far from being the only person worrying about the loss of support for invisiprims (LL officially dropped supporting them long ago). A lot of people still need them.
It's true, invisiprims are a hack in the first place. They were never supposed to be kept working for long, but for years we had no way to hide parts of the avatar mesh until alpha layers were introduced. Then most people were like "Ok can we stop with invisiprims now ? We can hide parts of the avatar mesh in a more elegant way now, let invisiprims die already ! They're ugly !"
Sure they are ugly, they're a hack. Invisiprims hide not only the avatar mesh behind them but also alpha textures, shininess and shadows. Plus, they render differently in the deferred renderer ("Lighting & Shadows", aka "Advanced Model") and in the forward renderer (the one without shadows). Ugly ! Hacky !
But there are two things invisiprims can do that alpha layers can't (or any other technique for that matter) :
- Hide a part of the avatar mesh by script : When you turn an invisiprim even semi-transparent, it stops hiding the avatar behind it. When you turn it fully opaque again (ok it's invisible, but opaque, follow a little, will ya ?), it hides the avatar behind it again. That's the feature two of my products rely on : the RR Armbinder and the RR Tape gag (plus blindfold). The RR Isolation Hood uses invisiprims too, but they can be replaced by alpha layers, and will. But for the former two, they are invisible while unlocked (and shouldn't hide the avatar's shoulders and lips respectively), and visible while locked (and expected to hide the shoulders and forearms for the armbinder, and lips for the gag).
- Hide only one arm : It's silly, but there is only one texture you can apply on the arms, and this texture will be mirrored on the other arm. This is how the SL avatar is UV-mapped, and this is not going to change any time soon I don't think. This means that an alpha layer (which follows the SL avatar UV map) is stuck with this restriction too. You cannot hide the left arm and not the right arm, for example. Invisiprims, on the other hand (no pun intended) are attachments, you can hide whatever you want without bothering with UV mapping.
Now, I know this post is supposed to be about RLV, but let me digress for a minute. I have made a script that gives the user of a RR armbinder or a RR tape gag a folder when locked. It's not released yet, maybe I will included it in an update, maybe not, and you'll see why I'm undecided if you read on.
The folder can contain anything you can think of and its name begins with a tilde ("~") so it is placed directly in your #RLV folder, and in the case of those two products, it just contains an alpha layer. The folder is different for some locks, for example the armbinder needs to hide only your forearms on locks 2 and 3, and needs to hide the whole arms on locks 4, 5 and 6. It works exactly like the Mousewheel and the Treadmill, which give you a folder containing clamps and/or a harness, depending on the configuration. It won't give you the folder if you already have it, to avoid clogging your inventory with useless stuff. And unlike the Mousewheel and the Treadmill, it doesn't need a RLV relay since you own the product, the commands are direct.
All this is good and well, but there are a few problems with this technique :
- The user needs to be on a RLV. If they aren't, they need to wear the alpha layers manually. It's clumsy.
- The #RLV folder receives sub-folders directly at the root. While this is acceptable and used by many other products in SL, this means this folder needs to be cleaned from time to time.
- The alpha layers take some time to bake. This means you won't see your avatar correctly (lips or shoulders will keep poking through the restraints) until the baking is done, which can take between 10 seconds and... the whole session. Depends.
- It won't work if you are already wearing 5 alpha layers. The limit of how many pieces of clothing of each type you can wear at any time is 5.
- Sometimes SL will just refuse to acknowledge that there is something in the folder you've been given. Sure you'll see the folder under #RLV, but your viewer will believe the folder is empty (or still "Loading...") and the "force wear" command issued by the restraint will fall short. Meaning you will think there is a bug : you've received the folder, the alpha layer is in there, but you're not wearing it. Mariiiiine ! There's a bug !
- Finally, you could be restricted from wearing stuff outside certain folders under your #RLV, and the "~" folders such as the one you've just received are not part of them. This means you receive the folder, the alpha layer is in there, the "force wear" command works... but nothing happens, and you think there is a bug, while everything is working as designed.
So... You can see why I'm currently happy with invisiprims, even though they are hacky and ugly and not supported. But until there is a better option to hide parts of the avatar mesh by script, I'd rather stick with them than relying on the more static option of alpha layers.
Thanks Henri !
You can grab the viewer here :
http://www.erestraint.com/realrestraint
The MD5 hash for the Windows package is
fcb9d42ed84b30a7d23394d69485302a
Have fun !
Marine
PS : My fix for invisiprims until now was limited to re-activating a bit of code deactivated by Runitai Linden (the 3D rendering guru at Linden Lab). Henri's fix
Ok, third release in a week, and I'm supposed to be in vacation...
But this release fixes invisiprims ! Thanks to Henri Beauchamp's help, a little bit of code that was getting in the way of having invisiprims work was removed, the result was tested, and here you go ! New version of the RLV.
Now, I was wrong on some account : I thought nobody cared about invisiprims but me, because two products of mine needed them to work. That was incorrect, I'm far from being the only person worrying about the loss of support for invisiprims (LL officially dropped supporting them long ago). A lot of people still need them.
It's true, invisiprims are a hack in the first place. They were never supposed to be kept working for long, but for years we had no way to hide parts of the avatar mesh until alpha layers were introduced. Then most people were like "Ok can we stop with invisiprims now ? We can hide parts of the avatar mesh in a more elegant way now, let invisiprims die already ! They're ugly !"
Sure they are ugly, they're a hack. Invisiprims hide not only the avatar mesh behind them but also alpha textures, shininess and shadows. Plus, they render differently in the deferred renderer ("Lighting & Shadows", aka "Advanced Model") and in the forward renderer (the one without shadows). Ugly ! Hacky !
But there are two things invisiprims can do that alpha layers can't (or any other technique for that matter) :
- Hide a part of the avatar mesh by script : When you turn an invisiprim even semi-transparent, it stops hiding the avatar behind it. When you turn it fully opaque again (ok it's invisible, but opaque, follow a little, will ya ?), it hides the avatar behind it again. That's the feature two of my products rely on : the RR Armbinder and the RR Tape gag (plus blindfold). The RR Isolation Hood uses invisiprims too, but they can be replaced by alpha layers, and will. But for the former two, they are invisible while unlocked (and shouldn't hide the avatar's shoulders and lips respectively), and visible while locked (and expected to hide the shoulders and forearms for the armbinder, and lips for the gag).
- Hide only one arm : It's silly, but there is only one texture you can apply on the arms, and this texture will be mirrored on the other arm. This is how the SL avatar is UV-mapped, and this is not going to change any time soon I don't think. This means that an alpha layer (which follows the SL avatar UV map) is stuck with this restriction too. You cannot hide the left arm and not the right arm, for example. Invisiprims, on the other hand (no pun intended) are attachments, you can hide whatever you want without bothering with UV mapping.
Now, I know this post is supposed to be about RLV, but let me digress for a minute. I have made a script that gives the user of a RR armbinder or a RR tape gag a folder when locked. It's not released yet, maybe I will included it in an update, maybe not, and you'll see why I'm undecided if you read on.
The folder can contain anything you can think of and its name begins with a tilde ("~") so it is placed directly in your #RLV folder, and in the case of those two products, it just contains an alpha layer. The folder is different for some locks, for example the armbinder needs to hide only your forearms on locks 2 and 3, and needs to hide the whole arms on locks 4, 5 and 6. It works exactly like the Mousewheel and the Treadmill, which give you a folder containing clamps and/or a harness, depending on the configuration. It won't give you the folder if you already have it, to avoid clogging your inventory with useless stuff. And unlike the Mousewheel and the Treadmill, it doesn't need a RLV relay since you own the product, the commands are direct.
All this is good and well, but there are a few problems with this technique :
- The user needs to be on a RLV. If they aren't, they need to wear the alpha layers manually. It's clumsy.
- The #RLV folder receives sub-folders directly at the root. While this is acceptable and used by many other products in SL, this means this folder needs to be cleaned from time to time.
- The alpha layers take some time to bake. This means you won't see your avatar correctly (lips or shoulders will keep poking through the restraints) until the baking is done, which can take between 10 seconds and... the whole session. Depends.
- It won't work if you are already wearing 5 alpha layers. The limit of how many pieces of clothing of each type you can wear at any time is 5.
- Sometimes SL will just refuse to acknowledge that there is something in the folder you've been given. Sure you'll see the folder under #RLV, but your viewer will believe the folder is empty (or still "Loading...") and the "force wear" command issued by the restraint will fall short. Meaning you will think there is a bug : you've received the folder, the alpha layer is in there, but you're not wearing it. Mariiiiine ! There's a bug !
- Finally, you could be restricted from wearing stuff outside certain folders under your #RLV, and the "~" folders such as the one you've just received are not part of them. This means you receive the folder, the alpha layer is in there, the "force wear" command works... but nothing happens, and you think there is a bug, while everything is working as designed.
So... You can see why I'm currently happy with invisiprims, even though they are hacky and ugly and not supported. But until there is a better option to hide parts of the avatar mesh by script, I'd rather stick with them than relying on the more static option of alpha layers.
Thanks Henri !
You can grab the viewer here :
http://www.erestraint.com/realrestraint
The MD5 hash for the Windows package is
fcb9d42ed84b30a7d23394d69485302a
Have fun !
Marine
PS : My fix for invisiprims until now was limited to re-activating a bit of code deactivated by Runitai Linden (the 3D rendering guru at Linden Lab). Henri's fix
Tuesday, August 13, 2013
RestrainedLove Viewer 2.8.5.1
Hello again,
It has been brought to my attention that the latest RLV wasn't working for those who use SL Voice, simply because one of its libraries was not compatible with the ones contained in the official SL viewer anymore. I don't know why, nor what I did wrong, but the issue was so bad that you couldn't even use the RLV properly without a fix. The viewer would complain about something missing in ortp.dll, then it would slow down so much that it would be unusable (about 1 frame per second or even less). You wouldn't get this issue unless you used Voice and were in a voice-enabled region.
So here is the fix :
Until now you would copy SLVoice.exe and the three vivox libraries from the SL viewer to your RLV in order to use Voice. It just so happens that a fifth file needs to be copied : ortp.dll.
You can get this file from your official SL viewer installation, overwriting the one in the RLV folder (since that one is not compatible), and it should work.
I'm uploading a new RLV without this ortp.dll file, and with an updated readme, just to avoid confusing the users. You don't really need to download it again if you have downloaded RLV 2.8.5, simply follow the instructions above to fix this problem yourself.
You can grab the viewer here :
http://www.erestraint.com/realrestraint
The MD5 hash for the Windows package is
3dd6f917a7a2374dd133dc3044e4dfe7
Now, another issue I've stumbled upon yesterday : the materials feature completely breaks invisiprims when using the deferred renderer (aka "lighting & shadows", aka "advanced lighting model"). You may have noticed that I have struggled over the last year to keep providing support for them, even knowing it is a hack and is meant to be forgotten after a while.
Problem is, some of my products (and I'm not the only one in this case) rely on a feature that only invisiprims could provide : the ability to hide and show some parts of the avatar mesh by script. When you wear an invisiprim and turn it even partially transparent, it stops hiding the avatar mesh underneath. This is neat when you want to make an attachment appear on you while hiding some parts of your body, just by clicking, and it would not even require an RLV.
Now this is not working anymore, and I don't see what I can do to make it work again. Even the hack is broken. So what I am going to do (and should have done long ago) is create alpha layers for some of my products (namely the Isolation Hood, the Armbinder and the Tape Gag) and make the avatar wear them forcibly when locked, a bit like the Mousewheel and Treadmill do when the sub is hitched. I wish I didn't need to do that, but LL leaves me no choice.
Have fun and sorry for the inconvenience,
Marine
PS : Thank you Starfire Desade for the heads-up !
It has been brought to my attention that the latest RLV wasn't working for those who use SL Voice, simply because one of its libraries was not compatible with the ones contained in the official SL viewer anymore. I don't know why, nor what I did wrong, but the issue was so bad that you couldn't even use the RLV properly without a fix. The viewer would complain about something missing in ortp.dll, then it would slow down so much that it would be unusable (about 1 frame per second or even less). You wouldn't get this issue unless you used Voice and were in a voice-enabled region.
So here is the fix :
Until now you would copy SLVoice.exe and the three vivox libraries from the SL viewer to your RLV in order to use Voice. It just so happens that a fifth file needs to be copied : ortp.dll.
You can get this file from your official SL viewer installation, overwriting the one in the RLV folder (since that one is not compatible), and it should work.
I'm uploading a new RLV without this ortp.dll file, and with an updated readme, just to avoid confusing the users. You don't really need to download it again if you have downloaded RLV 2.8.5, simply follow the instructions above to fix this problem yourself.
You can grab the viewer here :
http://www.erestraint.com/realrestraint
The MD5 hash for the Windows package is
3dd6f917a7a2374dd133dc3044e4dfe7
Now, another issue I've stumbled upon yesterday : the materials feature completely breaks invisiprims when using the deferred renderer (aka "lighting & shadows", aka "advanced lighting model"). You may have noticed that I have struggled over the last year to keep providing support for them, even knowing it is a hack and is meant to be forgotten after a while.
Problem is, some of my products (and I'm not the only one in this case) rely on a feature that only invisiprims could provide : the ability to hide and show some parts of the avatar mesh by script. When you wear an invisiprim and turn it even partially transparent, it stops hiding the avatar mesh underneath. This is neat when you want to make an attachment appear on you while hiding some parts of your body, just by clicking, and it would not even require an RLV.
Now this is not working anymore, and I don't see what I can do to make it work again. Even the hack is broken. So what I am going to do (and should have done long ago) is create alpha layers for some of my products (namely the Isolation Hood, the Armbinder and the Tape Gag) and make the avatar wear them forcibly when locked, a bit like the Mousewheel and Treadmill do when the sub is hitched. I wish I didn't need to do that, but LL leaves me no choice.
Have fun and sorry for the inconvenience,
Marine
PS : Thank you Starfire Desade for the heads-up !
Monday, August 12, 2013
RestrainedLove Viewer 2.8.5 with materials !
Hi there,
I didn't plan to do this so early, but it didn't require as much work as I expected, so here it is : a RLV that supports LL's latest feature, support for materials !
Wait, what's that, materials ?
I won't enter in a lengthy technical explanation, you may want to take a look at the video here and you'll understand everything :
http://www.youtube.com/watch?v=keFfqiDqnJg
And you'll understand why materials are going to be a mini-revolution in SL ! No more baking specular lighting into a texture before importing ! Woo !
Ahem. Sorry. I'm being a bit enthusiastic here. But, materials !
Also I forgot to mention it in the last post, but this viewer, as well as 2.8.4.1, supports Server-Side Appearance (once it is deployed across the grid).
You can grab the viewer here :
http://www.erestraint.com/realrestraint
The MD5 hash for the Windows package is
e057c25298a2c0015507fb9e2e7eaa3d
Have fun !
Marine
I didn't plan to do this so early, but it didn't require as much work as I expected, so here it is : a RLV that supports LL's latest feature, support for materials !
Wait, what's that, materials ?
I won't enter in a lengthy technical explanation, you may want to take a look at the video here and you'll understand everything :
http://www.youtube.com/watch?v=keFfqiDqnJg
And you'll understand why materials are going to be a mini-revolution in SL ! No more baking specular lighting into a texture before importing ! Woo !
Ahem. Sorry. I'm being a bit enthusiastic here. But, materials !
Also I forgot to mention it in the last post, but this viewer, as well as 2.8.4.1, supports Server-Side Appearance (once it is deployed across the grid).
You can grab the viewer here :
http://www.erestraint.com/realrestraint
The MD5 hash for the Windows package is
e057c25298a2c0015507fb9e2e7eaa3d
Have fun !
Marine
Subscribe to:
Posts (Atom)
Posts
