Friday, December 27, 2019

Merry Christmas and Happy Holidays !

Hi !

Merry Christmas and Happy Holidays ! I hope you've been naughty and Santa disciplined you *snickers*

I'm writing this post only to tell you two little things.

Firstly, about the Marketplace fees and what I said I would do after a week... well it's been more than three weeks and I haven't taken any decision yet because I've been a lazy slut very busy and frankly I haven't really noticed much of a difference in the money I got from the Marketplace sales recently compared to before LL increased the fees. There is a difference of course, but it's far from crashing my business so I guess it can wait a bit longer.

Secondly, I hear that Catwa finally added support for materials for the layers of the mesh heads that are not the skin. Better late than never ! However it does not seem to be possible using Omega yet so it looks like I'm going to have to make specific Catwa appliers. I don't know anything about Catwa appliers yet, I need to look into them, but at the very least I will eventually, and preferably soon, update my When You're Hot appliers with them, making them finally compatible with Catwa. It's not done yet, I don't know how much work this will represent, but it will be done and the sooner the better.

Have fun !


Tuesday, December 3, 2019

LL changes the Marketplace fees


Sorry for not posting these days and for not releasing anything. I'm still here and hard at work but the two projects I'm working on are big and are not finished yet, so I have nothing to show yet. But be patient :)

This post is about Linden Lab's latest changes to the pricing of the Marketplace, which you can read here. What I am interested about in particular is the fact that they cranked up the merchant fee from 5% to 10%. In plain English, this means that when you buy a product, the merchant used to get 95% of the price (the rest going to LL) and now they receive only 90% of it, for no return at all or any improvement in the service.

If you remember, 6 months ago LL had jacked up the fee of the process credit from 2.5% to 5%, which represents a significant loss per year. I decided back then not to increase the price of any of my products and kept my word.

But now this is beginning to accumulate. First the process credit fee and now this. And I suspect the fee will increase in the future since LL seems to think they have a margin, with Apple's and Google's fees being 30%. It's comparing apples to oranges, if you ask me, no pun intended.

Anyway, all this to say is that this time I don't know what to do. The calculation is simple : before Dec 2nd I received X*0.95 of any sale and now I receive X*0.90, so in order to receive the same amount of money as before, I would have to change the price of every product to X*0.95/0.90 = X*1.0555... Which means an increase of 5.555%. But that would put the cost entirely on the consumer, I would hate it if a merchant did that to me.

So a more just solution would be to divide the increase by two, so the consumer takes half of the cost and I take the other half. In other words, the increase would be about 2.777% only. In practice, that would mean the When You're Hot appliers would go from L$700 to L$720, for example. Not a big increase, but a noticeable one anyway.

I don't know yet what I'll do. I could also completely close my Marketplace store and sell only in-world but let's be honest, the Marketplace is where it's at. For most people, if a product is not on the Marketplace, it does not exist.

I've known about this change the day LL posted it to the blog but I stayed quiet, not really seeing a solution, and I still don't see one. I'm giving it a week to see how much this change impacts my income, probably not much but it won't go unnoticed either, I guess.

In other words, the prices of my Marketplace products won't change before next Monday (Dec 9th). After that... I don't know yet.


Thursday, September 26, 2019

Hotfix for the VixenTex plugin crashing

Hi !

It seems that after SL's September 24th 2019 update, the VixenTex plugin contained in the Vixen cuffs (especially the arms ones) tends to crash with a stack-heap collision, which means memory full. Nothing changed in the script but what used to work before stopped working after this SL update. I know the VixenTex plugin has always been borderline full on memory so to mitigate that I optimized it a little more and released an update for it.

The crash occurred when you go to the VixenTex plugin then choose a Preset, and to fix it you'd have to hard-reset the cuffs. Annoying.

With this hotfix, hopefully you won't get a crash anymore. I have checked the EleganceTex, HighbindTex and StrapTex plugins as well, they don't seem to be subject to this crash, only VixenTex. You can get the hotfix by doing a simple update of your Vixen cuffs (and collar if you want) at any of my updaters, you don't need a replacement since the issue is located in the plugin, which is in the main items of the Vixen set.

You can find an updater at the following places in-world :

My little shop

Dark Wishes

Roper's Dark Playground

Chorazin's main store

It looks like an orb floating above a pedestal, just click on it and follow the instructions.

Please note that Pak (where my little shop is) seems very laggy these days and this interferes with the update process. I recommend you try one of the other three slurls in priority. Chorazin's place is the least laggy of all.

Have fun !


PS : Thank you TotallyIn Corrigible for the heads-up !

PPS : If this script crashes because its memory fills up more than it used to, I expect other scripts to crash in the near future, and needing an update too. I'll stay on the lookout.

Friday, September 20, 2019

Update to the Proud Girls : Bake On Mesh support

Hi there,

Here is a small update to the Proud Girls to support Bake On Mesh and to give the ability to add environment shine on any layer including the skin if you so wish (Maitreya does not support environment shine yet but if you want your skin to look oily, this is the way to go).

Bake On Mesh

Technically an update wasn't really necessary there. All you had to do was to find an Omega or Lolas Skin applier that applies the special "upper bake" texture to tell your viewer to use the baked texture of your avatar instead of a regular diffuse texture, and that was it, but to switch back you would have to reapply your former skin again.

This update here simply adds a "BoM" switch in the Maintenance menu (and makes that menu a two-page one because there was no room left) :

Clicking on this button toggles between "Bake On Mesh" and regular for your skin (only). Please don't forget to unwear your body alpha mask or your breasts will turn red. If you are wearing an alpha mask, that probably means you are not using BoM for your Maitreya body, in which case you probably will soon. It makes no sense to use BoM on the Proud Girls and not on Maitreya anyway, it should be either both or none.

Environment shine

This one is a little bonus in case Maitreya Lara ever supports environment shine on the skin. But since I know some girls like to use the Proud Girls with a Slink body (apparently they fit not too bad either) and Slink supports environment shine, I wanted to add support in the Proud Girls too.

When you change the shine on any layer (skin, tattoo, bra or top), you can either enter just one number like before to change just the glossiness, or enter two numbers separated by a space, the first one being the glossiness and the second one being the environment. Setting an environment value to around 20 makes your skin look oily, it's quite sexy ^_^

How to update

It's easy. Simply rez the "Updater Proud Girls (rez me)" object near you and wait (don't be in "Do Not Disturb" mode), you should receive the new box shortly.

Or you can get a redelivery from the Marketplace, that works too.

Have fun !

PS : If you wonder what I'm doing now, I'm working on two very big projects for SL. One for my Maison De La Marquise brand, a new product that looks like it will be bigger than Pretty Mummy (and even sexier), the other is to update someone else's product that you likely own. More info later. So I'm far from being inactive even though I haven't communicated much lately nor released much. When I'm silent it usually means I'm working :p

Thursday, August 29, 2019

RLV (Bake On Mesh)


Here is a new version of the RLV with the new "Bake On Mesh" feature from LL. This is the only change, but an important one, especially since some mesh body makers such as Slink already offer a "Bake On Mesh" compatible body, no doubt others will follow shortly.

I for one will need to update the Proud Girls in order to let the user switch the skin between normal and "BoM".

You can grab the Windows version here :

The MD5 hash for the Windows executable is :

The Mac and Linux versions can be found here :

Have fun !

Tuesday, August 20, 2019


Hi !

Here is a new version of the RLV, a little in a rush because more and more people seemed to be impacted by the "gamma corruption" bug that crept into the SL viewer a few months ago.

This is a fix by Linden Lab for the SL viewer, I merely merged it into the RLV, hopefully this will fix the issue. It never happened to me, though, so I can't be sure, but I hope it will work for you.

Another change takes place when your vision is restricted with the outer sphere opaque, other avatars will no longer appear as gummy bears (aka jelly dolls) when close to the vision range, but 2 m farther than that, because this feature is meant to be an optimization to accelerate the rendering, not to be seen by the user at all. Please note that I completely forgot to mention that in the release notes, my bad.

I also switched the sound support from FMODex to FMODStudio, but this doesn't make a noticeable difference at least for me. Thanks to Chorazin Allen and Nicky Perian for letting me use their code from Kokua.

One last thing. Chorazin Allen is for the moment publishing the RLV on Mac and Linux (and also Windows but that's because this is his primary platform) on top of maintaining Kokua, taking the relay from Kittin Ninetail because her RL did not allow her to do it anymore. Thanks Chorazin !

You can grab the Windows version here :

The MD5 hash for the Windows executable is :

The Mac and Linux versions can be found here :

Have fun !

Thursday, June 13, 2019

Update to the carts, Treadmill and Mousewheel

Hi there,

Here is an update for an annoying bug occurring in the Mousewheel, Treadmill and all the MG carts when changing a configuration while under heavy lag. Sometimes the animations wouldn't play, sometimes the objects wouldn't be given correctly... and it would work when done a second time.

This was due to a race condition that wouldn't occur in healthy sims, but under heavy lag the timing wasn't good enough, so this fix should correct that.

The products that are impacted are :

- Chariot
- Dogcart
- Mousewheel
- Phaeton (both of them)
- Sulky
- Treadmill

The Mousewheel and Treadmill seemed especially sensitive to this bug, but since the scripts are exactly the same as the carts, I don't see why the carts should be exempt.

To update your carts and/or treadmill and mousewheel, simply rez the updater contained in the folder on the ground and wait, you will receive a new box a moment later. Leave the updater alone, it destroys itself after a while.

You receive a new box but you might not want to re-rez everything, especially if you've made substantial modifications to your device. I'm thinking about carts in pony sims like PFS, FFF and FPR, for instance. So if you do not want to have to modify everything yourself again, here is what you can do :

1. Get the updated device (carts or whatever)
2. Take a copy of the following script from root prim of the new device, into your inventory :
    *Chariot / *Dogcart1 / *Mousewheel1 / *Phaeton2 / *Phaeton4 / *Sulky / *Treadmill1
3. Edit one of the seats (for example where a pony sits) and take a copy of the "Seat" script into your inventory.
4. If there is a "GiveItemsAndWear", take a copy of it too (it is in the mousewheel and the treadmill only).
5. Edit the root prim of your old device and replace its main script ("*Chariot", "*Dogcart1" etc) with the one you took from the root prim of the old device.
6. Edit the seats of the old device separately, one by one. For each one of them, replace the Seat and GiveItemsAndWear (if it exists there) with the ones in your inventory. Some devices have a lot of seats (Chariot and Phaeton 4 particularly), you need to replace them all. Press Ctrl Alt T to see the seats in red so you don't miss any. In the Phaetons and the Dogcart, the cage is a separate seat that needs to be updated as well, but if you forget it that's not an problem. In fact, the seats that you must update are the ones where a pony sits, as the passengers, driver and prisoner do not change animations when the config changes, so they are not impacted by the bug.

Have fun !


Thursday, May 30, 2019

About LL's price changes...

Hi again,

So, following LL's latest post about the incoming price changes to Premium accounts, as well as region price and process credit fees, I would like to take something off my chest.

For starters and to avoid keeping you worried, I do not plan to increase the price of any of my existing products to offset the cost this change represents. Perhaps future products might be a bit more expensive than they would have been without this change, I don't know, I don't actually think so. Of course, never say never, but for now and for the foreseeable future (unless LL jacks the prices up even more in two months, who knows), the prices will stay the same.

There are several reasons for that, one of them being how I come up with a price when I release a new product (it's mostly related to the value of the product, not to its production cost), another one being that I am reluctant to change any price once it has been set, be it up or down. I remember when redesigning the Police set and replacing the Prisoner Belt with the waist chain and the Police collar, I thought long and hard before changing the price. It wasn't an easy decision (granted, that was a L$30 increase, nothing to scream about, but still).

But I won't lie, SL is going to cost more for me than it did so far, and the same goes for every content creator who makes a living with SL like I do.

First, there is the premium cost being jacked up (from $72 to $99 a year since I'm annual). Ok that's not a big deal, I can surely afford to pay $27 a year for, well, nothing at all in return. Or nothing tangible at least. Maybe it will help LL improve the platform and fixing the bugs ? In that case, ok take my money and make the damn thing work.

Second and more importantly, the process credit fee that doubles from 2.5% to 5% per process. In my case that means that it will cost $1000 more to get my money out of SL every year, once again for no change in the service whatsoever. I am not happy at all with this change, but I understand this is because of new regulations or something. Grumpity Linden has hinted about that in a forum post but he has been pretty vague on the subject. I don't know where the additional 2.5% will go. Will it go to LL ? To a bank ? To the US ? No idea. But someone is going to get richer in the process and that's not me.

Why am I telling you all this ? Because we are all impacted by those changes. If you are a Premium user or are planning to become one, you will pay more than you used to, meaning less money to spend in SL as a whole, since your stipend will remain at L$300 per week.

But there is a silver lining. If you've paid attention to the page I have linked at the beginning of this post, you have noticed that region prices are being lowered by about 8%, which is a good thing. Land owners who are not greedy will lower the rent prices for their tenants (you), meaning more L$ for the latter to spend, meaning more sales for merchants. One can only hope. At least I am decreasing the rent in my own sim (where there are four tenants) and I hope the majority of sim owners will do the same.

This is the only thing that can save SL businesses, in my opinion. It's that or merchants will have to increase their prices, which means a double loss for consumers. First loss because their Premium price will go up, second loss because everything will become more expensive. I pray that it will not be the case.

If you are a business owner yourself and you decide to increase your prices, trust me I understand. This post is not at all meant to shame you for doing it. The process credit fee increase is significant and we all have to make a living. I am just pointing out that I won't do that because I can afford it, at least for the foreseeable future.


Update to all the latex suits

Hi there,

Here is an update for all the latex suits (Catsuits, Bodysuits, Socks & Gloves) to fix the annoying bug that would apply the legs textures onto the top of the body when using a mesh body that is compatible with Omega and that is not Maitreya (for example Slink, Belleza and Tonic), and when in a very laggy sim. And when unlucky.

Please note that if you are a Maitreya user, this update won't change anything for you and you can skip it unless you wear parts that are compatible with Omega (for example, a V-tech flat chest or a Lab737 baby bump).

Likewise, although the Socks & Gloves get the fix too, they did not really trigger the bug as they use separate appliers for the top and the bottom, so you don't really need to update them either (but you can if you want). But for the Catsuits and the Bodysuits, the fix was sorely needed.

The bug was due to an over-optimistic timing on my part, assuming that the top Omega applier script needs no more than one second to load its textures before the legs Omega applier script takes over to get its own textures loaded... but in laggy sims it seems to need more time. The fix makes it so the legs Omega applier script waits for the top one to finish before it starts getting its data instead of waiting for a fixed delay, so now all the textures are correctly loaded and it no longer depends on the speed of the sim.

As a result, the loading is now faster and you only have one message on the chat instead of two.

However, there is a known issue that I have not managed to isolate and fix, and I'm not even sure if it comes from my scripts, or even from this update, or if it comes from the Omega scripts. Sometimes (often, in fact), when applying to an Omega compatible mesh body, the top would apply but not the legs, no matter how long you wait. The workaround is simple and written in the chat when you click on a color button : click on the applier button a second time. In fact, if you want to be sure the whole body gets applied, double-click on the applier button right away. I absolutely don't know why it does that, even after spending hours tracking this bug in different sims. It does not seem to depend on sim speed nor on what you click on, nor on how much time passes between the click on the color button and the click on the Omega applier button, or anything like that. It is a race condition between the two Omega applier scripts, of which I do not have the source code so I cannot fix it myself.

To update your latex suits, simply rez the update orb contained in the folder and wait, you will receive a new box from my server (don't be in "Do Not Disturb" mode or you will receive the box only when you leave that mode). Or you can request a redelivery in the Marketplace (in your "My Marketplace" page), that works too.

Have fun !


Monday, May 20, 2019

Small update to the Deluxe Gag


Here is a small update to the Deluxe Gag to fix a strange issue with the OpenMouth plugin, that would not save the correct brand or variant in some locks. For example, if you change the variant of the "simple ring" lock to "narrow", then the "simple ball" lock will use the "narrow" variant as well.

This was due to a pretty stupid oversight on my part. The OpenMouth plugin mistook the current lock (from 1 to 9 depending on the button you click on) with the calculated lock which determines how much to garble the speech. Both are the same in all the RR gags except the Deluxe Gag and that was the cause of the bug. Please be aware that I did not fix the bug in the other RR gags but there is no need to, since only the Deluxe Gag was suffering from it.

To update your Deluxe Gag and benefit from this fix, you need to go to one of these locations :

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

Once there, click on the updater and follow the instructions. If you Deluxe Gag is already up to date, you do not need to choose "REPLACE", simply choose "UPDATE". My shop in Pak is quite laggy these days so if you can't get it to work there, I recommend you go to Chorazin's place, which is a lot faster.

Have fun !

Thursday, May 16, 2019


Hi there,

Here is a new version of the RLV with more bug fixes and the inclusion of the latest version of the SL viewer's codebase (including a fix for one of its own bugs).

The highlight of this version is a fix for a very annoying bug that occurs only in certain places like ColdLogic Neve, where you can't see some of the alpha-blended prims because their first faces are invisible. This was due to the graphics optimization that completely ignores the rendering of any invisible surface.

Another highlight of this version is the optimization of the vision restriction spheres. Now, when the outer sphere is opaque or almost (99% alpha or more), then the avatars beyond it are rendered as if they were too complex, in other words as their gummy bear versions (but you won't see it due to the outer sphere being in the way). This speeds up the rendering a great deal and helps in busy places like DeLust.

Also thanks to Kitty Barnett, we can now receive deliveries from objects while offline again because this version of the viewer uses the legacy method of retrieving offline messages instead of the new sim capability which doesn't seem to work well.

You can grab the Windows version here :

The MD5 hash for the Windows executable is :

Have fun !

Thursday, May 9, 2019

Update to the Dust System

Hi !

Sorry for being silent lately, I'm deep into a RL project that takes all my time but don't worry, I will be back soon.

I'm releasing an update for the Dust System (the surfaces and the controller, not the dusters) to finally fix a bug that had been eluding me for years. Namely, sometimes the surfaces simply don't get dusty again after having been cleaned. Well, except it's not that simple, they do get dusty but they sometimes take way too much time. Let me explain.

As you may already know, each surface has two delays. The first one indicates how much time the surface stays clean, and the second one indicates how much time it takes, once the first delay is elapsed, before it becomes fully dusty again (and it becomes dusty progressively over time between the end of the first delay and the end of the second one). Easy.

Except that when you click on the surface and it's still clean, its timer resets ! That's not good, this means that if the first delay is set to one week (which is the default) and you click on the surface 6 days after having cleaned it, it will take one more week before even beginning to gather dust. So this update is meant to fix that because it had been confusing a few users.

Another change is simply the controller now shares its information (namely the two delays) with the surfaces whenever you press "Refresh", you change the times or when a surface resets or is updated with the "Update Surf" button of the controller menu. That way you can set your times on the controller once and later update your surfaces and/or add new ones, and they will all be in sync without having to do anything manually.

To update your Dust System, you have to do it in two stages.

First click on your controller (rez it if you haven't already), chose "New version ?" to check for the new version, and you will receive your new package after a short time.

Then, instead of rezzing new surfaces (because it is time consuming, and you probably have already placed your surfaces carefully already), derez that controller and rez the new one, the one that is included in the box you've received. No need to rez new surfaces, you will in fact update each of the existing ones automatically by clicking on the new controller and pressing "Update surf.". Wait a moment until all the surfaces are updated, and voila !

Have fun !


Thursday, April 11, 2019

Update to the Siren and Shibari arms ropes


It has come to my attention that yet again, some (most) of the animations in the arms ropes of the Siren and Shibari sets deformed the avatar, because they included bone translation information. Specifically, you would see your shoulders change width right when playing one of those anims.

I don't know why because I distinctly remember having fixed that issue years ago, but here it goes again, so now I have re-uploaded all of them after correcting them and hopefully you won't see your avatar deformed when being bound in ropes ever again.

To get this fix you must replace your Siren and Shibari arms ropes (legs ropes do not have this issue as far as I know), it won't be fixed with a mere update. Fortunately, you don't have to use the new set completely, only the right wrist rope, you can still use the other items of the old set that you've replaced. Those secondary items are not touched by the updater and the fix is just a replacement for the animations, there is no other change, so you won't need to resize anything but the right wrist rope.

To update your restraint and benefit from this fix, you need to go to one of these locations :

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

Once there, click on the updater and follow the instructions. You need to choose "REPLACE". Don't forget to save your times before requesting a replacement. If you do not get a "REPLACE" option, contact me (Marine Kelley) to get a manual replacement.
My shop in Pak is quite laggy these days so if you can't get it to work there, I recommend you go to Chorazin's place, which is a lot faster.

Please note : If you have issues with one of the animations in Supertight (specifically "STB"), please replace again, without having to resize your secondary items, as there was an issue with this animation the first time. Thanks Miraelia for the heads-up.

Have fun !

Thursday, March 21, 2019

Update to the Proud Girls


This was a long-standing update but I kept postponing it because I always had something more urgent to do... Sorry about that. Here is an update to the Proud Girls that will hopefully make your life easier. It's not a big update, just a few quality of life changes.

The changes

Skin materials

Skin appliers can now change the materials of the skin since Maitreya's appliers can do it too. You can restore the materials by clicking on the "Restore mat." button located in the Maintenance menu.

Long applier messages

Some appliers were not fully compatible with the Proud Girls because the latter could not parse their messages. Now when such an applier is used, the Proud Girls will assume it is a Lolas applier with materials (those are the longest).

Keep the mask mode

When applying a texture, the mask mode of the layer you apply to is now preserved instead of being reset.

Keep the shine

That one was the most annoying issue of all. Now when you apply a texture with materials, the shine of the target layer won't change except if it is specified as 0 (or there are no materials) by the applier. Just like in Maitreya.

Don't change the shine of the rings/barbells/chain

Now when you change the tint of the rings, barbells or chain, their shine won't change at all. In fact, the shine won't be changed by the script anymore, so you can set it the way you want, manually, and it will remain that way.

How to update

It's easy. Simply rez the "Updater Proud Girls (rez me)" object near you and wait (don't be in "Do Not Disturb" mode), you should receive the new box shortly.

Or you can get a redelivery from the Marketplace, that works too.

Have fun !

Real life pics & video how-to

Hi there,

Following the release of my little gift last Saturday, I would like to explain how I made all those tapes so that you can make your own, and hopefully share or sell them. Because yeah, this little gift wasn't completely out of interest, I want other people to produce content too, not just me :p

This blog post is aimed at anyone who owns either the HD Video System and/or the RemVision and wants to make their own tapes, either with Second Life (SL) pictures and videos, or with real life (RL) ones. Or a mix of both. Or your own drawings. Or whatever you can think of.

I have already written a comprehensive blog post explaining how to take your own videos in SL and how to turn them into animated pictures that the HD Video System and RemVision can play. You can find it here. That post, however, is SL-centric and you may want to upload your own images and videos to display them in SL, and the process is slightly different. The goal of this present blog post is to show you how. I will speak in the first person as if you were looking over my shoulder while I'm working.

I will use a few sample pictures and animated GIFs as an example for this tutorial. Please note that I do not own any of the images I use here, I downloaded them from Tumblr (when it still allowed adult content) and Bdsmlr. They're adult but not pornographic, just a little erotic. I do not include any RL bondage picture either, nothing that could look real and non-consensual (even if bondage pictures are, hopefully, consensual), only sexy latex pictures.

I have uploaded to my dropbox a zip file containing all the files I use in this tutorial. It is in the finished state, so after downloading this zip you will get the original files, the generated textures and the intermediate AVIs. You can find this file here.

The "Making Movies - Free Tools" box located at my shop also contains the finished (but not finalized) tape with all the uploaded textures in it, as well as the finished track notecard so you can compare and use it as an example.

Are you ready ?

Good. Let's go.

The process of turning real life content into SL tapes is pretty straightforward and does not require much creativity. It is divided in four phases.

1. Organize your content.
2. Process it.
3. Upload it and make the track.
4. Create the tape label

But first, you need to make sure your tools are ready.

Phase 0 : Prepare your tools

(But you need to do this only once.)

Well, guess what, I won't actually explain how to install your tools here, since I've already done so in this post. Just to recap, you need Python 2 or 3, VirtualDub and ImageMagick (and ShnTool if you need to process music, but that's beyond the scope of this present blog post). And once all this is installed, you need to download the few Python scripts I've written that will handle the processing for you.

So if you haven't already done so, jump to the Making Movies - Video blog post to find out how to install your tools. I'll be waiting.

Done ? Good. Let's proceed.

Phase 1 : Organize your content

Organize your files properly

It may sound like a no-brainer, but since there is probably a lot of content to work through, it is a good idea to organize it all upfront in order to not get lost, waste time, or upload the same thing several times, wasting money doing so.

First of all, I create a folder on my hard drive that I will name, say, "Example". Just for convenience, I also copy the three Python scripts I will need to process the files, because I don't want to have to type long paths in the command prompt.


In this folder, since I'm going to process still pictures and GIF files, I need to create (at least) two folders that I will name "images" and "videos", and I create a text file at the same time, that I name "Track_example.txt". This text file will contain the timings of all the pictures the tape will display. It will remain empty for now until the last phase.

Now is the time to select the content I want to include in my tape. For this part, anything goes. It may be pictures found on the internet like here, or pictures taken in SL, or drawings, the limit is your imagination.

Here I simply show the thumbnails of all the pictures I will process :

Sexy latex pictures !

In fact, the top four in the window above are animated GIFs, the second one being really big (20 MB !). The other ones are simply JPG pictures but some are bigger than 1024x1024, which is the maximum SL can display on a prim.

You can already see here that you have three types of files. Normal pictures, big pictures and animated pictures. Let's organize them so we don't mix them up. I create one folder inside "images" that I will name, for example, "HD", and move all the bigger pictures in it :

The first one is 540x1211 and the second one is 1080x1920.

There are a couple other pictures which have one dimension a bit bigger than 1024, but they're no bigger than 1050, so we would not really gain much precision by spanning them over more than one prim.

You need to keep in mind that the more prims you use for a single image, the more money you have to spend when you upload it (since it takes more than one texture to display at full resolution), but also the fewer pictures you can display in a single tape because the Track scripts in the tape have limited memory, so you will have to create more than one tape. It's not a problem, but it is something to keep in mind if you want to avoid a script crash at some point. From my experience, I know that a tape can manage up to 300 textures.

As for the videos, it's easy, I move all the four GIFs to the "videos" folder :

Rename your files (if needed)

All my files are organized the way I want, but their names are a bit... unwieldy. They're "tumblr" or "bdsmlr" followed by a bunch of letters and digits, and at some point I will have to copy their names into the "Track_example" text file. The names are so complex and random that this is a recipe for error. It's not a problem memory-wise because the Track scripts do not retain the names of the pictures at all, but SL does have a limit of 64 characters for the name of an item in your inventory, and some files will have a lot of parameters added to their names later. So, better keep things short.

I don't know how you'll do it, but I use FreeCommander (I didn't use it to take the snapshots of the folders above to avoid confusing you, but I actually seldom use the Windows Explorer anymore, instead it's FreeCommander all the way and it's pretty much the very first app I install when I get a new computer) that has a nifty multi-rename feature. Here I use it to rename all the files "EX" followed by either "v", "sd" or "hd" for "video", "standard definition" and "high definition" respectively, then a three digit number, then the original extension. In the end, it gives me this :

There. This will be much easier to manage.

All this renaming is entirely optional and you rename the way you like, if you want to rename at all. This was just to show you an example of how to make things easier for you later.

Process your files

Now we're getting into the thick of it. This section will take the biggest part of this blog post, so brace yourself.

Process the SD pictures

We'll begin with the easiest, the processing of the simple pictures (the ones I have renamed with "sd"). This means, in this particular case, to rename them in a way that the name of each file will contain the dimensions of the picture in a format that the HD Video System and RemVision will understand. It can be done by hand, but the "" script can do it for you.

To do this, I open a command prompt where the SD pictures are, i.e. in Examples/images :

Just for the sake of the example, typing "dir" in this directory gives me the list of all the SD pictures I have and none other :

Time to rename them. I type :

python \SL\

And it gives me this :

What this script just did was add the dimensions of each file to its own name in the form ".WxH" before the extension. That's all. It's a bit slow because to do this it has to open the file, identify it with "identify" (a process in the ImageMagick suite), write the output in a temporary file, read the output from that temporary file, then close it. For each picture. Still, it's a lot easier than to do this by hand.

Look at the file names now :

That's it, the SD pictures are ready, there is no more work needed to do on them.

Please note that if you modify the dimensions of one of the pictures (for example you crop it) and need the dimensions recalculated, you can re-run the script and it will replace with the new dimensions instead of appending the new ones to the already existing file names.

Likewise, if you need to remove the dimensions totally to go back to the original names, simply write "remove" after the command. That would be :

python \SL\ remove

Process the HD pictures

Now let's go to the HD folder and process the two big pictures that are in it.


The first one is 540x1211 and the second one is 1080x1920 pixels. I would like to point out that at the time of this writing, the script can only generate a square number of pictures to compose the HD ones here, so we'll generate 2x2 pictures for the first one and 2x2 pictures for the second one. I think it's a waste of resources and I would like to work on the script and on the screen of the HD Video System to handle 2x1 and 1x2 formats, but this is not a trivial change so for now this is what we have.

Unlike the SD pictures, here I need to do them one by one. Later I will modify the script to run batches.

I make the command prompt go to this directory by typing

cd HD

I check by typing


Everything is there, let's go.

Let's do the first one. This time the script to use is "" (yes, it's a long name but at least it's clear). I simply type

python \SL\ EXhd001.jpg

And I get :

Notice that now I no longer have two files in this HD folder but six, as the script has created four pictures of less than 1024x1024 to cover the whole original EXhd001.jpg file which it hasn't touched at all.

I do the same for the second file and I get :

Now there are ten files in my folder, but only eight will have to be uploaded. Now is a good idea to move the original two to a safe place so I won't upload them by mistake later. I simply create a folder that I name "processed" and I move those two files (EXhd001 and EXhd002) in it.

To take this snapshot I had to press Alt-PrintScreen and at the same time drag and drop with the mouse button down. Since the keys are too far apart and I don't have three hands, I had to press PrintScreen... with my nose. The things I do for you !

Now only the eight generated files remain.

Notice the name of those files. There are two groups of four but only one per group has the actual parameters containing, among other things, the dimensions of the original picture and the layout to use (for example 540x1211 and 2x2 respectively). It doesn't matter that the name does not include the actual dimensions of the file (for example 270x606) because the screen does not really care about the dimensions. What it cares about is the ratio between the width and the height in order to display the picture without stretching.

The other parameters are specific for animated pictures and are irrelevant here.

That's it, we're done with the HD pictures, let's move on to the animated ones now, which require the most work.

Process the GIFs

When you process an animated GIF, the goal is to have it display at the same dimensions, the same frame rate and hopefully little to no loss in resolution. The last part is what causes issues because as you know, SL can only display 1024x1024 textures, and you want to squeeze all the frames of your GIF into one or more of those textures.

In practice, you will most likely lose some resolution but it won't matter. As long as the quality is 60% of the original resolution or more, you'll be fine.

Instead of blathering for hours on the subject, let's try one of the GIFs. First, I go to the "videos" folder with the command prompt :

cd ..\..\videos


The four GIF files are there, good. Let's try and process the smallest one, which is EXv004.gif. That's the spanking one, it is 10 frames long and its dimensions are 500x273.

Wait... How do I know how many frames it takes ? Well... FreeCommander told me. I don't know how to get this information in the Windows Explorer, but it's not really important anyway :p

Crop and convert to AVI

The first step is to open this GIF in VirtualDub and to crop it, because there might be areas that you don't really care about and can do without. The less area to render, the more frames you can cram into the same texture, so the less resolution you lose. Here is how it looks in VirtualDub, which indicates 11 frames (from 0 to 10) but the last one is empty anyway, so that's 10 frames in total, FreeCommander wasn't lying.

Let's crop it (no pun intended, but yeah, we're cropping a spanking).

To do this, I open the Video > Filters window (Ctrl-F is the shortcut) and add a "null transform" filter to crop the image.

I click on "Cropping..." and this opens the "Cropping" window which will allow me what parts of the video to show and what part to hide.


The original video is 500x273 big and the null transform filter is new so there is no cropping set yet. What you want is show only the interesting parts and make sure the dimensions are even. It won't work if one dimension is odd (like here, 273 is an odd number, if I saved the video now VirtualDub wouldn't let me). This is because I use the Xvid codec which can only handle even dimensions.

A good way to ensure that the dimensions are even is by dragging the sides with the Shift key pressed. Much faster than to adjust precisely, to the pixel, until you get an even dimension.

Here in this video, I don't really care about what's on the left of the girl's butt, so the doorway can be hidden. I do want the spanking hand to show though, and since it moves, it is a good idea to find out how far to the left it goes. It turns out that frame 7 is where it is leftmost, so I can crop with this frame active.

As for the vertical dimensions, I don't really want to crop but I have to because the Height of the video is an odd number, so let's lower it by one by increasing Y1.

Here is the result after some cropping :

I simply shift-dragged the left side and clicked on the down arrow next to Y1. This took like 3 seconds in total. I click OK twice and the main window of VirtualDub shows me what the video will look like after the cropping. But I don't really care, I want to get on with it as fast as I can, because this is not the only video I have to process. For this example there are only four videos, but there may be a lot more than that in your case (there are a lot more than four videos in the three gift tapes I made).

So all I do is press F7 (that's the shortcut for "Save as AVI"), I select the same folder in the Save dialog if not already done, and I click "Save" or press Enter without renaming anything.

So that's one done. The result is a file named EXv004.avi in the same folder. If I open it in VLC, it shows the same animation minus its left part, with the same frame rate and no loss. The loss will occur when I turn this AVI file into textures, which I'm going to do in a minute.

After making several videos out of GIF files, it will be really quick.

- Drag and drop in VirtualDub
- Press Ctrl-F
- Crop
- Press OK twice
- Press F7
- Press Enter
- Done. Switch to the next.

Here is the result with one AVI per GIF :

Notice that in this Explorer window, I added the Frame width, Frame height, Frame rate, Width and Height columns in the Details view mode. This allows you to see the differences between the Frame width and height of an AVI, and the width and height respectively of the corresponding GIF and see how much I cropped each file (and that I didn't crop file 2 and 3 at all).

Now that all the AVI files are ready, it is time to process them into textures that the HD Video System will use to display those videos in SL.

Turn the AVIs into textures

To do this, you need the "" script and a few parameters :

- The name of the file (with or without the ".avi" part, surround the name with quotes if there's a space in it)
- The frame rate (you see it in the Windows explorer)
- The number of prims from 1 to 5 (to make 1x1 to 5x5 textures respectively)
- The target number of frames (that parameter is optional, use it if you want to decimate)

Let's try the first one with the most naive parameters. I type in the command prompt :

python \SL\ EXv001 11 1

This means "process video EXv001.avi, which goes at 11 FPS and I want it to use 1x1 textures". And I get this :

The script recapitulates the parameters and indicates the calculations it does, such as the dimensions of each frame in the final texture (here 204x204), the layout it chose (here 5x5) and more importantly, the quality. That one is simply the final dimensions divided by the original dimensions. It will write "OK" if the quality is between 60% and 120%. Less than 60% and you might want to use more textures or to decimate the frame rate (i.e. remove some frames), more than 120% and you are wasting space. Here, apparently the naive parameters are OK for the script and the result seems not bad at all :

The result is a file named EXv001.00.240x224.5x5.25x11.1x1.png. Its parameters contain all the screen needs to know to display this texture as an animated picture with the right frame rate and the right dimensions, there is nothing else you need to do.

The original GIF contains 25 frames that are mostly square (240x224) so it ended up with a 5x5 layout. And you can squeeze 25 of these small images into a 1024x1024 texture just right, without much quality loss, which is why the end result is satisfactory. It won't be so easy for some other videos though.

So let's consider the first video done and switch to another, more problematic one, like the third one which is 480x600 and spans over 374 frames ! You can't cram 374 images of those dimensions into a 1024x1024 texture, no matter how hard you try, but let's try anyway.

python \SL\ EXv003 20 1

Yyyyeah... 10% quality, that's not nearly enough. Indeed, this is what I get with these parameters :

Here are the 374 frames put inside a single 1024x1024 texture. I don't know what I expected, but it can't get better than this with such tight resources.

The original video goes at 20 frames per second, which is pretty smooth, and the image is that of a cute girl spinning in her gorgeous black latex dress. I want to see the latex, but I'm not interested in so much smoothness, I would be perfectly happy with 12 to 15 FPS at most. The fewer FPS, the more resolution we can use, and vice-versa since in the end, all the frames are put inside the final texture(s).

With 10% quality, I don't really have a choice anyway, I have to use 4x4 textures or even 5x5. Let's try with 4x4 and lower the frame rate down to 60% of 20, which makes 12 FPS :

python \SL\ EXv003 20 4 0.6

That's not bad at all... Ok, the quality is a little low, but around 50% is still good. The original GIF is very big and detailed anyway, and I might not need so much detail. Actually, looking at the generated tmp.avi file, which is 12 FPS, I'm pretty satisfied with the result. Of course, the smoothness is nowhere near as good as the original GIF, and the dimensions are halved, but it's still pretty good.

Here, let me show you two of the 16 generated textures :


That's textures "01" and "09" respectively. You can see the detail of her face and hair on the first, and the details of her latex dress on the second. You can even count her fingers. Such detail is all I ask.

So let's consider it done.

No need to dwell on the remaining two, but let me show you the commands I used to generate their respective textures :

python \SL\ EXv002 7 2

python \SL\ EXv004 7 1

This gives me 4 textures (2x2 prims) for EXv002 and 1 texture (1x1 prim) for EXv004. Both videos have around 7 FPS and I didn't need to decimate. The output quality is around 90% in both files, which is excellent.

That's it, the pictures and videos are all done ! It wasn't so hard, was it ? We have converted each GIF to an AVI, cropped each AVI then converted it into PNG files, sometimes one AVI yielding several PNGs to keep relatively close to the input resolution and frame rate. All that needs to be done now is to manage all that new content, into SL.

But in order to avoid uploading stuff that we don't want to upload, let's organize things a little.

I create a folder that I name "processed" in the "videos" folder, and I move all the GIFs and AVIs files in it. I also don't need the "tmp" folder anymore nor the "tmp.avi" file so I delete those.

Write the track and upload

Write the track

The track is the "Track_example.txt" file that was created at the beginning, and that remained empty for the whole duration of the tutorial. Now is the time to fill it.

Its purpose is to specify the order and timing of each picture and video, and what the sections are. You will see what I mean by that shortly.

I won't explain the details of what an entry is, everything is already explained in this blog post. But that post does not explain sections so I will do so here.

First, open the "Track_example.txt" file in a text editor like Notepad, Notepad++ or Scite (I use the latter).

The track will need to specify, for each picture and video, how much time it must stay on screen, so that's what we're going to do now.

We have 8 SD pictures, 2 HD pictures and 4 videos, so that's 14 entries in total. If you forget one, it won't be played by the HD Video System or RemVision at all even if you have uploaded it and put it in the tape. However, there are more than 14 textures in the folder, since some videos yielded more than one texture, and the HD pictures both generated 4 textures each. But you won't reference any original file more than once.

Let's not be too creative there... Let's decide we want each picture to show for 60 seconds and then the next one replaces it, then the next etc. Here is how the track file looks :

Notice that I never wrote any of the parameters contained in the names themselves, only the names and nothing else. The tape track scripts will figure out how to grab the parameters from the textures that I will upload later so no need to repeat them here.

The very first entry is there to avoid confusing RemVision which adds a dummy "Begin" section at the beginning, and I've had trouble in the past when I didn't write this "+1 :: $" line.

Each other entry is a timing (+0/+60) and a file name following a dollar sign because it is a picture or a video. As you can see, they are all written in order. There's no creativity here, I should actually write a script to do it automatically one day. I made one in LSL that I included in the HD Video System but I need to make one in Python. But I digress.

Now suppose we want to group some entries, and to let a RemVision play all these pictures in a random order (the HD Video System cannot play in a random order, only sequentially). To do this we need to define sections, because RemVision can play sections in a random order but all the entries inside the same section will be played in the order they are written. This is on purpose.

Since the section names are copied into the RemVision plugin, it is better to choose short names otherwise a memory shortage may ensue and crash the script. But I'm talking a hundred sections, which is far from the few sections we will write here.

A section is a subtitle that begins with a "!", therefore an entry that begins with "!!" since subtitles already begin with "!". The HD Video System and RemVision do not display those subtitles, and the RemVision plugin stores them so the user can define manual playlists, but other than that they are simply subtitles, and as such follow the same syntax and are stored in the subtitles track script.

Let's see... I'd like to group EXsd007, EXsd008 and EXv001 together because it's the same model (Susan Wayland, even though for the video I'm not 100% sure but whatever), EXsd003, EXsd004 and EXhd001 together because it's full body latex, and the rest will be one entry per section.

It now looks like this :

Save the track

Now that the track is done, copy and paste it into the "*Track audio video subtitle" notecard contained inside the tape, then save.

Upload the files

Ok so now comes the painful part. Painful for your wallet, that is. You will need to upload every single one of those textures, PNGs and JPGs alike. In my folder, that means 38 files exactly (16 JPGs and 22 PNGs). That means L$380 to pay to create that tape, plus maybe L$10 to make the tape label (unless you want to use one of the uploaded textures for that).

But please don't upload the files contained in the zip you downloaded, I have already uploaded them for you. They are inside the "Example RL pics (work)" tape contained in the "Making Movies - Free Tools" box.

Place the files in the tape

Nothing to say except edit the tape and put all the textures in it. Please note that you should not put too many textures in one sweep, try to insert 30 or 40 items, wait a few seconds, do the same with the next 40, wait etc. This will avoid the "inventory creation failed" error from the sim (and you'd notice the failure once you record the tape). Of course, for this example here, there are only 38 textures to insert so this won't be a problem.


Click on the tape and select "Record All". If all goes well, the scripts will read your track notecard and hopefully no texture will be missing (otherwise, see above and you'll need to insert the missing textures again). Once done, the tape is ready to play !

Enjoy !

Now is the time to watch your video and see if there is any issue. If you find an issue, probably all you'll have to do is modify the track notecard and record again.

Optional : Create the tape label

By default the tape label is plain white, but you may want to make your own. No need for a tutorial here, if you can use Gimp or Photoshop, feel free to make your label, if not, you can use any one of the texture that you've uploaded, and offset and scale it so it looks good enough for you.


Once you're happy with your movie, take a copy of the tape in your inventory. Then click on the tape in-world and press "Finalize", then "YES". All the content except the notecard and scripts will be removed and you will be ready to share or sell your tape. Don't forget to change the permissions !

That's it, I hope you will find this tutorial easy, and that you will enjoy producing your own content !

Saturday, March 16, 2019

A gift for you.

Hi there,

I have a gift for you ! No, not this one, another one...

But to know what it is and to be able to use it, you first need to update your HD Video System and/or your RemVision because I had to substantially modify the process script (the one that turns videos into frames for SL) so that it can handle non-square videos with non-square numbers of frames. It doesn't sound much, but it makes it a LOT more powerful than before. In the past, it could only process square videos and that was very limiting. The same goes for the screens of those two products, which too have to be able to display non-square videos.

In this update, you will find the following changes and if you pay attention, I think you will have a hint of what the gift is all about. If you don't already have a clue, that is.

HD Video System

* The two screens are now able to handle non-square videos.

* The player can now display times longer than 100 minutes without shifting the Play symbol.

* The screen seemed not to be able to display colors for subtitles (unverified and unheard of, but I have corrected the code anyway, just in case).

To update your HD Video System, simply rez the update orb contained in its folder and you will get your new HD Video System automatically.


* The screen is now able to handle non-square videos.

* Increased the chat limiter to 110 lines from 90 (it should still not trigger the infamous chat throttle).

* When a new tape is being copied, it displays static over the eyes during the copy for a nice little effect (*), then resumes playing if it was playing before. It also re-shuffles the playlist if the playing mode was "Random" (otherwise it switches back to "Sequential").

* Made the inner lenses (the surface where the projected picture is) glow 10%. You can set it to whatever you like manually, the script does not modify the glow at all, but I find 10% to be good. (*)

* The lenses displayed tall pictures (pictures that are taller than they are wide) stretched the wrong way.

* The ear pieces are now invisible by default. It makes more sense because they don't restrict hearing by default.

* The outer lens (the one that shows the texture you select, like Blank, Realistic and such) is now invisible in the "Lock" lock, but you can still turn it visible by selecting "Always max" in the Lenses Opacity menu of RemVision. (*)

* The screen seemed not to be able to display colors for subtitles (unverified and unheard of, but I have corrected the code anyway, just in case).

* When clicking and dragging the screen, it limits the dragging in a way that you can't move it away enough to see what it was hiding before dragging it. This now takes the state of the background ("None", "Black" or "White") into account, meaning that if the background is invisible, the screen will use the visible prims (the ones showing the movie) to know how far you can drag it and where to stop. In the end, you can't see what's behind the screen no matter how far you drag it.

(*) If you use the unrigged lenses instead of the rigged ones, you need to use the new ones after getting the replacement, as the old ones don't have that feature.

To update your RemVision device, you need to go to one of these locations :

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

Once there, click on the updater and follow the instructions. You need to choose "REPLACE". Don't forget to save your times before requesting a replacement. If you do not get a "REPLACE" option, contact me (Marine Kelley) to get a manual replacement.

There is a known issue that does not have any solution that I know of. Since now the animated pictures can have empty frames in their textures (but you won't see them since the screen won't play them, it plays only the non-empty frames), clicking on the screen will reset the animation back to its first frame. It's not a big deal, but it's a change from before when clicking on the screen would re-synchronize at the current frame. Now it re-synchronizes at the first frame, that's all.

Python scripts for movie creators

(This section is relevant to you only if you create movies and/or slideshows)

It's funny, but the core of this update is not even the HD Video System nor RemVision. It is mainly the script, the one that is used for turning an AVI file into a set of textures with frames that SL can display as an animated picture over several prims.

Before this update, this script could only handle square videos with a square number of frames, or would decimate the frames until reaching a square number. This was good but too limiting, in particular when dealing with animated GIFs from the Internet, which can have arbitrary dimensions and numbers of frames, but small enough a number making decimation out of question.

As a result, you now need to specify the dimensions of the AVI when calling this script, and you now have the ability to specify the target number of frames you want in the final montage (or indicate a decimation factor like before). It will organize all the frames composing your video into the textures in the best way possible while sticking to the original ratio (Width / Height) to avoid any deformation. The result on-screen is much better than before. I'm thinking of ways to make this script obtain the dimensions and the number of frames of a video by itself so you don't have to specify those data in the parameters anymore.

I have updated to get rid of the requirement of specifying the dimensions of the picture, now it figures it out all by itself.

I have also created a new script named that will automatically rename all the images in a folder on you hard drive with the appropriate dimensions so you don't have to do it yourself.

If you want to update the Python scripts on your hard drive, simply go get them from my Dropbox account, the urls are in the Director's Manual notecard of the HD Video System, and in the blog post linked below.

I have reflected all those changes in the Making Movies - Video blog post.

The Gift

So... You've read this far and you really want to know what this gift is all about, don't you ?

Now I can tell you what it is !

The gift is a box containing three tapes full of bondage pictures and videos coming from the Internet. The pictures are more or less organized in themes (Fetish, Ropes, Cuffs, Sex, Straps, Duos and some other sections) and all three last three hours average, counting one minute per picture or video. This means hundreds of pictures and videos ! And not the shabby ones either.

This is where you see the new script shine, as all the animated pictures come from GIFs without losing too much quality. Some are even exactly like their original files without any loss.

The tapes are designed to be played in random order for a better experience, so the sub never knows what to expect. The section names are very short because they are stored in the RemVision plugin, which would crash if they were any longer. They are usually just a letter and a number (not always consecutive due to how I had to move some pictures from one tape to another) and reflect the type of the pictures and videos. R for rope, F for fetish, X for sex, S for straps, D for duo, C for cuffs.

You may ask yourself, why this gift and why now ? There's no special occasion. I've just wanted to improve my animation script for a while to allow for non-square videos and to prove how easy it is to use once it was operational. So I will probably write a blog post to explain how I made those tapes (pictures, videos and tracks) to encourage you to do the same :)

You can get the box containing the tapes for free at My Little Shop :

Have fun !

Thursday, March 7, 2019



Here is a new version of the RLV with even more bug fixes, including for the infamous "attachment loss after teleport" bug, and for that one I'm far from being alone to work on it.

I took Henri Beauchamp's fix (with his permission, thank you Henri) as well as Chorazin Allen's integration of the fix from Firestorm into Kokua (with his permission too, thank you Chorazin, and of course thank you Ansariel and Kitty for working on it in the first place), added them to my own (introduced in RLV 2.9.25 and a little more in 2.9.26), shook the whole cocktail a little and voila.

I've tested and seen this bug occur with each fix taken separately, sometimes an attachment would go past Henri's fix, some other times it would go past Ansariel's fix. Even with two of them in the code, sometimes an attachment would go past both fixes one after the other (it was rarer, but it happened).

But with all of them I have yet to experience one attachment loss, and I TP a lot with a lot of attachments on my avatar, so yay ! Well I hope yay. In any case, it seems a lot more stable than before, so let's hope this bug is finally behind us now.

There was also a small bug introduced in RLV 2.9.26, well it's not really a bug but a side effect of one of the fixes mentioned above, which would make Bento-rigged attachments using animations containing bone displacement (for example neko ears) revert back to their original locations after a teleport and even a rebake wouldn't fix it. This should be fixed by the fixes mentioned above, but I have still seen it happen in this version, albeit very rarely. If this happens to you, press Ctrl Alt T twice (that shortcut highlights invisible surfaces in red) and it seems to fix it. I don't know why yet, but at least we have that option. Also the bug was only seen in local, other people would not see it, and so is the fix.

Lastly, I have added three useful shortcuts for builders :

- Alt+S to return to the standard Move tool (it also deactivate Edit Linked and selects the whole object, otherwise the selection would look weird).
- Alt+X to select by face.
- Alt+C to switch to Qarl Linden's Align tool.

Speaking of Qarl's Align tool, I have reinstated it in the Edit window, something I forgot to do in 2.9.26. The code was there but the UI file did not contain the "Align" entry, sorry about that.

You can grab the Windows version here :

The MD5 hash for the Windows executable is :

Have fun !