Yesterday afternoon Mistress had reason to play around with flexible path values for a linkset. In doing so she mentioned that it was a bit of a pain to have to set the parameters individually for each item in the linkset. Never having really played with this before, I was a little surprised to find that it's a prim parameter that you can't set on more than one prim at once; especially given it's one you can set on more than one prim at once from a script.
So, for fun, I knocked up a little tool that would let her experiment quickly and easily. Z&A Flex Linkset was born:
The script is designed so that it listens to the object owner in local chat, and accepts commands for setting the different parameters. When a parameter is given it's applied to the whole linkset. Commands include:
flex soft <value>
flex grav <value>
flex drag <value>
flex wind <value>
flex ten <value>
flex fx <value>
flex fy <value>
flex fz <value>
As well as commands for setting the flexible path parameters, there are also commands for controlling the script itself. To see the current parameters:
flex show
To reset the parameters to their default:
flex reset
And when you're done with the script and you want it to remove itself from the object:
flex done
And that's it. It was fun to knock together, Mistress had fun playing around with it, hopefully it's of some use to someone else too.
Showing posts with label Scripting. Show all posts
Showing posts with label Scripting. Show all posts
2017-11-06
2016-08-21
The unnecessary script
I bought this unitard/bodysuit thing the other day:
I love it. I'm never taking it off ever again. At least not until the next thing I have to wear.
Only.... there's a thing that bugs me about it. This particular one is for the Maitreya mesh body but it doesn't auto-alpha out of the box; neither is it a perfect skin-tight fit so it does need some alpha work. That's not a problem of course, I can use the body HUD and I can then use the Maitreya auto-alpha script to make it auto-alpha for me.
Ideally I'd drop the script inside the item of clothing -- saves having to make a separate object that I have to add to any outfit -- but, as with many items of clothing, it's no-mod. And this is where it gets a bit silly and a bit unnecessary and where it bugs me.
Looking inside the item of clothing I see this:
A bloody "no rez" script. The sort of thing that, when you rez the item on the ground, it patronises you and then calls llDie.
So, for no real sensible reason I can detect, I have to carry around a script that reports that it will happily use up to 64k of script memory (why can't the author at least use llSetMemoryLimit to reduce that?) while doing nothing other than stopping me from rezzing it out. Worse, trying to stop me from rezzing it is a complete waste of time because all I have to do is find a plot with scripts turned off:
Meanwhile.... the Maitreya auto-alpha script can achieve the auto-alpha thing and it has support for the pointless no-rez thing built in as an option. Even better: it does this in a script that will use a maximum of 16k of script memory!
So.... dear clothing makers, please, please, think though your options and reasons before you drop a script into an item of clothing -- chances are all you're doing is adding scripts to avatars for no good reason whatsoever.
I love it. I'm never taking it off ever again. At least not until the next thing I have to wear.
Only.... there's a thing that bugs me about it. This particular one is for the Maitreya mesh body but it doesn't auto-alpha out of the box; neither is it a perfect skin-tight fit so it does need some alpha work. That's not a problem of course, I can use the body HUD and I can then use the Maitreya auto-alpha script to make it auto-alpha for me.
Ideally I'd drop the script inside the item of clothing -- saves having to make a separate object that I have to add to any outfit -- but, as with many items of clothing, it's no-mod. And this is where it gets a bit silly and a bit unnecessary and where it bugs me.
Looking inside the item of clothing I see this:
A bloody "no rez" script. The sort of thing that, when you rez the item on the ground, it patronises you and then calls llDie.
So, for no real sensible reason I can detect, I have to carry around a script that reports that it will happily use up to 64k of script memory (why can't the author at least use llSetMemoryLimit to reduce that?) while doing nothing other than stopping me from rezzing it out. Worse, trying to stop me from rezzing it is a complete waste of time because all I have to do is find a plot with scripts turned off:
Meanwhile.... the Maitreya auto-alpha script can achieve the auto-alpha thing and it has support for the pointless no-rez thing built in as an option. Even better: it does this in a script that will use a maximum of 16k of script memory!
So.... dear clothing makers, please, please, think though your options and reasons before you drop a script into an item of clothing -- chances are all you're doing is adding scripts to avatars for no good reason whatsoever.
2016-07-08
Parcel Settings Checker
This is something I wrote earlier this year, and which I wish I'd thought to write a lot sooner. On Raven Park there's a handful of plots that are for rent and, as part of those rentals, there's a few rules to keep things safe and clean. Two big ones are that you don't have public build turned on, and that you also don't have ban lines (security tools are fine -- but no ban lines please, they're ugly!). So, of course, every so often, I had to fly around the region and check settings.
Which was a silly thing to do when I could have a script do the job for me! It was quick and easy to write and I thought I should finally publish it here in case it was useful to someone:
Of course, what you should do is change the value of EMAIL_REPORT_TO so that it points to an email address you want the report sent to (or leave it empty if you'd prefer it to be sent via IM). If you want to check other settings on a plot you can modify the code of ReportOnParcelAt. As it's written it does a check every six hours. If you want to change that just modify the value passed to llSetTimerEvent.
Hope it's helpful to someone else.
Which was a silly thing to do when I could have a script do the job for me! It was quick and easy to write and I thought I should finally publish it here in case it was useful to someone:
Of course, what you should do is change the value of EMAIL_REPORT_TO so that it points to an email address you want the report sent to (or leave it empty if you'd prefer it to be sent via IM). If you want to check other settings on a plot you can modify the code of ReportOnParcelAt. As it's written it does a check every six hours. If you want to change that just modify the value passed to llSetTimerEvent.
Hope it's helpful to someone else.
2016-04-25
A little adventure in live-editing a mesh body glitch layer
The other weekend the Raven Park dance was prison-themed. It was decided that I should go as Toni and that it would be fun to find a Toni-appropriate prison uniform. That, of course, meant something fairly revealing because.... why the hell else would you buy a Maitreya Lara mesh body? ;)
Sadly though, after a lot of searching, including looking for a specific size of gacha item at various gacha resale markets, nothing could be found. So Mistress decided to custom-make a uniform for me. We ended up with a full-perm mesh template that said it was Maitreya compatible and Mistress made just the perfect texture for it. The final result looked like this:
The problem with it, however, was that it didn't really fit that well. Despite saying it was Maitreya compatible my body was clipping out of it all over the place; with all possible alpha cuts turned alpha it still wasn't right and no amount of shape-changing really solved the problem. We were still seeing the problem even with the "standard" Maitreya shapes. It was going to be no good for dancing.
So Mistress then suggested that she make a glitch applier for it. Normally if an item of mesh clothing doesn't fit I'll bin the demo and not bother; with this however it was a case of wanting to make the right look for a two hour dance so a compromise using a glitch layer made sense.
The plan seemed sound, but how could Mistress get it made without too much faff? To start with I quickly made an applier version (using the dev kit that Maitreya provide in their main store) of the famous "Robin (Sojourner) Wood UV Suit" and put that on so Mistress stood a chance of working out where to place textures.
That was a start, but it was still going to mean a bit of faff uploading textures and trying them out. What she really needed was to be able to live-edit the texture; but to make that happen she'd need to be able to use a local texture as an applied texture on the mesh body and there's no direct way to do that.
I did realise, however, that there was an indirect way.
So, first thing I did for her was write this simple script and pass it to her:
She then dropped that in a cube she rezzed in-world and then textured the cube with a local texture version of the glitch layer. After that she touched the cube and it gave her the UUID of the local texture.
So far so good.
Next I got her to rez another cube and drop the "Maitreya Applier Script - V2 0.10" script from the Maitreya dev kit inside it. This was now the applier prim.
Now for the final step. I had Mistress make a copy of the "Maitreya Texture Loader - Body Overlay V2" notecard and edit it to apply the UUID of the local texture to the top of the mesh body:
All she had to do then was drop the notecard inside the applier prim, let it read it, touch it, apply the texture to the relevant layer and.... done! At that point she had the local texture applied to her body and any change she made was reflected almost instantly on her Maitreya Lara body.
A bit of image editing later and Mistress had the glitch layer sorted; she passed me the texture, I made an applier for it and I was sorted:
At this point I could wear the dress and not worry (too much) about bits of my body clipping through because they were the same colour.
It is, of course, kind of amusing that we had to make glitch pants of old for a nice new mesh body and mesh dress, but it got the outfit sorted and worked a treat. Mistress had fun making a thing and I had fun cobbling together a method that let her live-edit an applier layer.
While nothing I came up with is especially clever or new -- I'm sure others have figured this out before -- I thought it might be handy writing it up here in case anyone else went looking for a way to do this.
Sadly though, after a lot of searching, including looking for a specific size of gacha item at various gacha resale markets, nothing could be found. So Mistress decided to custom-make a uniform for me. We ended up with a full-perm mesh template that said it was Maitreya compatible and Mistress made just the perfect texture for it. The final result looked like this:
The problem with it, however, was that it didn't really fit that well. Despite saying it was Maitreya compatible my body was clipping out of it all over the place; with all possible alpha cuts turned alpha it still wasn't right and no amount of shape-changing really solved the problem. We were still seeing the problem even with the "standard" Maitreya shapes. It was going to be no good for dancing.
So Mistress then suggested that she make a glitch applier for it. Normally if an item of mesh clothing doesn't fit I'll bin the demo and not bother; with this however it was a case of wanting to make the right look for a two hour dance so a compromise using a glitch layer made sense.
The plan seemed sound, but how could Mistress get it made without too much faff? To start with I quickly made an applier version (using the dev kit that Maitreya provide in their main store) of the famous "Robin (Sojourner) Wood UV Suit" and put that on so Mistress stood a chance of working out where to place textures.
That was a start, but it was still going to mean a bit of faff uploading textures and trying them out. What she really needed was to be able to live-edit the texture; but to make that happen she'd need to be able to use a local texture as an applied texture on the mesh body and there's no direct way to do that.
I did realise, however, that there was an indirect way.
So, first thing I did for her was write this simple script and pass it to her:
She then dropped that in a cube she rezzed in-world and then textured the cube with a local texture version of the glitch layer. After that she touched the cube and it gave her the UUID of the local texture.
So far so good.
Next I got her to rez another cube and drop the "Maitreya Applier Script - V2 0.10" script from the Maitreya dev kit inside it. This was now the applier prim.
Now for the final step. I had Mistress make a copy of the "Maitreya Texture Loader - Body Overlay V2" notecard and edit it to apply the UUID of the local texture to the top of the mesh body:
All she had to do then was drop the notecard inside the applier prim, let it read it, touch it, apply the texture to the relevant layer and.... done! At that point she had the local texture applied to her body and any change she made was reflected almost instantly on her Maitreya Lara body.
A bit of image editing later and Mistress had the glitch layer sorted; she passed me the texture, I made an applier for it and I was sorted:
At this point I could wear the dress and not worry (too much) about bits of my body clipping through because they were the same colour.
It is, of course, kind of amusing that we had to make glitch pants of old for a nice new mesh body and mesh dress, but it got the outfit sorted and worked a treat. Mistress had fun making a thing and I had fun cobbling together a method that let her live-edit an applier layer.
While nothing I came up with is especially clever or new -- I'm sure others have figured this out before -- I thought it might be handy writing it up here in case anyone else went looking for a way to do this.
2015-06-20
Some new shackles
Given my current status these days I don't really have much call for 24/7 cuffs or shackles of any sort. Back when I was owned by Miss Vila I almost always had a set of Real Restraint Elegance Cuffs locked on; they've always been a favourite of mine in that they look big and heavy and they're all metal but they also look smart.
I still need and use cuffs these days, of course, but that's mostly for product building and testing purposes. For that I have an old set of Elegance Cuffs, with all their scripts removed (the full-blown RR cuffs are a little heavy on the script count, it has to be said), and with a hybrid LockGuard/LockMeister script in them (that's also no-script safe too, which can come in handy at times).
After today though I think I might move over to something new:
These are the wrist cuffs for a set of cuffs from Dutchie. I first noticed them in the advertising material for Froukje's latest release. While I don't in any way want to diminish how important a role the female model plays in the advertising images (wink) one of the first things I noticed was how good the cuffs looked in the photos.
And now I've got a set.
They're just the sort of thing I like; while elegant-looking they also look solid and look like they'll hold up against all sorts of wear.
The really great thing is that they're a single mesh object, not a linkset. This made sizing them to fit my male frame really easy. Also, because they're copy and modify, I can make a few different sets for different needs.
They also have a spec map applied for those who run with ALM, which means they nicely catch the light as this sort of metal would. Here's a little video where I try and show this off (please forgive the shaky camera work -- controlling the SpaceNavigator when in this close is kind of tricky, I find).
While they come scripted to work with LockGuard furniture (so perfect for all Z&A hold/display products that use chains, for example) they won't work for LockMeister items (not really so common with furniture these days, but not uncommon for when working with other restraints). So, for example, out of the box they won't work with the Z&A Yoke. Again though, because they're modify (oh how I do love when people leave modify on for their products!), that's easily fixed because I can just swap the scripting for the hybrid script I mention at the start.
They're a great addition to my folder full of cuffs in my inventory. I suspect they'll get a fair bit of use when it comes to building and testing my own products -- and they'll also be my preference when I need cuffs on an outfit.
I still need and use cuffs these days, of course, but that's mostly for product building and testing purposes. For that I have an old set of Elegance Cuffs, with all their scripts removed (the full-blown RR cuffs are a little heavy on the script count, it has to be said), and with a hybrid LockGuard/LockMeister script in them (that's also no-script safe too, which can come in handy at times).
After today though I think I might move over to something new:
These are the wrist cuffs for a set of cuffs from Dutchie. I first noticed them in the advertising material for Froukje's latest release. While I don't in any way want to diminish how important a role the female model plays in the advertising images (wink) one of the first things I noticed was how good the cuffs looked in the photos.
And now I've got a set.
They're just the sort of thing I like; while elegant-looking they also look solid and look like they'll hold up against all sorts of wear.
The really great thing is that they're a single mesh object, not a linkset. This made sizing them to fit my male frame really easy. Also, because they're copy and modify, I can make a few different sets for different needs.
They also have a spec map applied for those who run with ALM, which means they nicely catch the light as this sort of metal would. Here's a little video where I try and show this off (please forgive the shaky camera work -- controlling the SpaceNavigator when in this close is kind of tricky, I find).
While they come scripted to work with LockGuard furniture (so perfect for all Z&A hold/display products that use chains, for example) they won't work for LockMeister items (not really so common with furniture these days, but not uncommon for when working with other restraints). So, for example, out of the box they won't work with the Z&A Yoke. Again though, because they're modify (oh how I do love when people leave modify on for their products!), that's easily fixed because I can just swap the scripting for the hybrid script I mention at the start.
They're a great addition to my folder full of cuffs in my inventory. I suspect they'll get a fair bit of use when it comes to building and testing my own products -- and they'll also be my preference when I need cuffs on an outfit.
2015-04-29
New toys for scripting
It's been a while since I noticed changes to the calls available in LSL that have interested me. The last time I can think of was when llGetAgentList turned up on our region. Today's RC release adds some handy extra items to llGetEnv. Whereas before the values that could be acquired were:
dynamic_pathfinding
estate_id
frame_number
region_idle
sim_channel
sim_version
it's now been extended with:
agent_limit
estate_name
region_cpu_ratio
region_product_name
region_product_sku
region_start_time
simulator_hostname
I can see some of these new ones being handy for information and diagnostic uses. region_start_time is especially useful in that it renders part of my region restart notifier script moot (the part that lets you know when a region last restarted). It also means you can check the update of any region you're stood in by simple use of an easily-scripted HUD.
simulator_hostname also looks handy in that it pretty much replaces any need to use llGetSimulatorHostname and, in doing so, removes the forced delay cost.
I'm also a bit intrigued to see the addition of OBJECT_LAST_OWNER_ID. That could have some interesting uses.
dynamic_pathfinding
estate_id
frame_number
region_idle
sim_channel
sim_version
it's now been extended with:
agent_limit
estate_name
region_cpu_ratio
region_product_name
region_product_sku
region_start_time
simulator_hostname
I can see some of these new ones being handy for information and diagnostic uses. region_start_time is especially useful in that it renders part of my region restart notifier script moot (the part that lets you know when a region last restarted). It also means you can check the update of any region you're stood in by simple use of an easily-scripted HUD.
simulator_hostname also looks handy in that it pretty much replaces any need to use llGetSimulatorHostname and, in doing so, removes the forced delay cost.
I'm also a bit intrigued to see the addition of OBJECT_LAST_OWNER_ID. That could have some interesting uses.
2015-04-24
Get a region's map tile URLs
Earlier today I found myself in a position of needing to grab a handful of map tiles from the Second Life map API. There's an image that needs making that requires a number of map images so grabbing them from that API made sense.
To help do this job, and to help work out what the URLs are for a given region, I knocked up this script:
Just drop it into a prim and touch the prim to get all the URLs for all the map tiles, at all zoom levels, for the current region. Alternatively, say the name of a region on channel 1 to have it do the same for that region (the script is coded to only listen to the owner).
The output looks like this:
Using a variation on this script I was able to create the image I needed without too much effort (in my case I needed to get the tiles in a specific area, at a specific zoom level, so I could paste them together to make a bigger map).
I'm starting to wonder now if using something like this, in combination with media-on-a-prim, could be used to make an in-world interactive map (yes, I know, you could just browse maps.secondlife.com on a prim but where's the fun in that?).
Potential idle-time project at some point.
To help do this job, and to help work out what the URLs are for a given region, I knocked up this script:
Just drop it into a prim and touch the prim to get all the URLs for all the map tiles, at all zoom levels, for the current region. Alternatively, say the name of a region on channel 1 to have it do the same for that region (the script is coded to only listen to the owner).
The output looks like this:
Using a variation on this script I was able to create the image I needed without too much effort (in my case I needed to get the tiles in a specific area, at a specific zoom level, so I could paste them together to make a bigger map).
I'm starting to wonder now if using something like this, in combination with media-on-a-prim, could be used to make an in-world interactive map (yes, I know, you could just browse maps.secondlife.com on a prim but where's the fun in that?).
Potential idle-time project at some point.
2015-04-03
Calculate LOD switching distances
During the process of getting to the bottom of yesterday's bizarre mesh problem I got to see a really handy script in action. It dumped massive amounts of information about the mesh object it was dropped into (most of it went right over my head -- there's still a lot I need to learn about how mesh works and reacts in-world and in the viewer). One handy bit of information it gave was the distances at which the different LOD switches would happen.
I like to think I have a fairly good feel for how the different LODs for a mesh should look, and indeed when I can even leave them out. In some situations I will leave out the lowest and low LODs if I feel that they'll never be seen (although I've noticed that the lowest can often be seen very close when an object first comes into view, or first comes back into view after being hidden by another object, or looked away from; but that's a different story). This can, of course, save a ton of land impact. So normally I just mesh away, upload, make sure my viewer's RenderVolumeLODFactor is set to no more than 2 and then cam around and away like crazy and see how the object reacts and looks. This has generally served me well.
Fact is though, as is detailed in Beq's article in this issue of Prim Perfect, there's an actual calculation that can be done to know exactly what the distances are. That's just too handy and some hard numbers will always trump a vague feel. So, given that, I took what's given on the Wiki and wrote the following script to give the bare minimum information.
Hopefully that's useful to someone else too.
I like to think I have a fairly good feel for how the different LODs for a mesh should look, and indeed when I can even leave them out. In some situations I will leave out the lowest and low LODs if I feel that they'll never be seen (although I've noticed that the lowest can often be seen very close when an object first comes into view, or first comes back into view after being hidden by another object, or looked away from; but that's a different story). This can, of course, save a ton of land impact. So normally I just mesh away, upload, make sure my viewer's RenderVolumeLODFactor is set to no more than 2 and then cam around and away like crazy and see how the object reacts and looks. This has generally served me well.
Fact is though, as is detailed in Beq's article in this issue of Prim Perfect, there's an actual calculation that can be done to know exactly what the distances are. That's just too handy and some hard numbers will always trump a vague feel. So, given that, I took what's given on the Wiki and wrote the following script to give the bare minimum information.
Hopefully that's useful to someone else too.
2015-03-27
Quick steps maker
While contemplating an upcoming build the other day the idea for this script popped into my head and, having thought of it, I had to knock it together quickly. Like a few other scripts I've put on here this stems from my use of Mesh Studio, where I'll make mesh objects in-world from lots of prims. This time around I wanted to make some simple stairs.
I've done this before and it's easy enough: rez and size a prim, copy it, move it to the next spot, copy, move to the next spot, and so on. But it'd be easier done with a script, right?
So the Z&A Quick Steps Maker was born. With this you simply rez out as many cubes as you want steps:
Link all the cubes and drop the script into the root prim. When you do so it'll texture the "top" face of the root so you know what direction the stairs will build in.
Next, size the root prim to the size of a step.
Once you're happy with it, touch the linkset and...
...the steps build themselves. If it doesn't quite look right all you need to do is resize the root prim to taste...
...and touch again to have the stairs rebuild:
Of course, a far more sophisticated system could be made where an object rezzes other objects out, building the stairs for you dynamically (could be something like that even exists -- I've not bothered to look), but that wasn't the point of this script. The point here was to knock up something that works quickly and easily for those times where you know what it is you're doing but you just want to save some fingerwork. It also means that there's no need to consider things like the grey-goo fence as it's you making all the prims up front.
Anyway, on the off chance that it's useful to anyone else, here's the script:
I've done this before and it's easy enough: rez and size a prim, copy it, move it to the next spot, copy, move to the next spot, and so on. But it'd be easier done with a script, right?
So the Z&A Quick Steps Maker was born. With this you simply rez out as many cubes as you want steps:
Link all the cubes and drop the script into the root prim. When you do so it'll texture the "top" face of the root so you know what direction the stairs will build in.
Next, size the root prim to the size of a step.
Once you're happy with it, touch the linkset and...
...the steps build themselves. If it doesn't quite look right all you need to do is resize the root prim to taste...
...and touch again to have the stairs rebuild:
Of course, a far more sophisticated system could be made where an object rezzes other objects out, building the stairs for you dynamically (could be something like that even exists -- I've not bothered to look), but that wasn't the point of this script. The point here was to knock up something that works quickly and easily for those times where you know what it is you're doing but you just want to save some fingerwork. It also means that there's no need to consider things like the grey-goo fence as it's you making all the prims up front.
Anyway, on the off chance that it's useful to anyone else, here's the script:
2015-03-09
RLV REPL
This script is being filed under "why the heck didn't I think of this before?" as well as "surely someone else has done this, I wonder why I've never seen it before?"
A little earlier today I found myself needing to quickly test a handful of different RLV commands. Now, as I have done over the past 5 years, I could have made a script, ran it, changed it, ran it again, changed it some more, run it again, etc... Really though, that gets rather tedious. And then it hit me! What I really need is a RLV REPL.
What I came up with isn't a REPL in the strictest sense but it more or less does the job. Rez a cube, throw the script inside and then touch it to turn it on (it'll be obvious when it's on and off). In the on state it listens to all local chat by the object owner and, if the text starts with an @, it repeats it via llOwnerSay. Instant quick and dirty RLV command line/REPL thing!
This should save me a bit of faffing about the next time I want to test something.
A little earlier today I found myself needing to quickly test a handful of different RLV commands. Now, as I have done over the past 5 years, I could have made a script, ran it, changed it, ran it again, changed it some more, run it again, etc... Really though, that gets rather tedious. And then it hit me! What I really need is a RLV REPL.
What I came up with isn't a REPL in the strictest sense but it more or less does the job. Rez a cube, throw the script inside and then touch it to turn it on (it'll be obvious when it's on and off). In the on state it listens to all local chat by the object owner and, if the text starts with an @, it repeats it via llOwnerSay. Instant quick and dirty RLV command line/REPL thing!
This should save me a bit of faffing about the next time I want to test something.
2015-02-19
Show face numbers
This is a script that actually started out life as a set of textures, which got made while I was exploring the workings of "Smart Objects" in Photoshop.
The idea behind the script is pretty simple: drop it in a prim or the root of a linkset and it'll texture every face with a number to show the face number. Nothing clever. Nothing you'd want to do to an item where you didn't want to destroy the existing textures. Nothing you can't really do in a reasonable viewer (most of the time -- this does help solve the problem of getting at mesh faces that are almost impossible to touch). On the other hand, sometimes, when you're coding, having a nice big visual reminder on the screen in front of you isn't such a bad thing.
The script itself doesn't self-delete, but it does refresh the textures if the prim changes or more items are linked to it.
Here's the script:
The idea behind the script is pretty simple: drop it in a prim or the root of a linkset and it'll texture every face with a number to show the face number. Nothing clever. Nothing you'd want to do to an item where you didn't want to destroy the existing textures. Nothing you can't really do in a reasonable viewer (most of the time -- this does help solve the problem of getting at mesh faces that are almost impossible to touch). On the other hand, sometimes, when you're coding, having a nice big visual reminder on the screen in front of you isn't such a bad thing.
The script itself doesn't self-delete, but it does refresh the textures if the prim changes or more items are linked to it.
Here's the script:
2015-02-09
List unique textures in a build (revisited)
As much as I love making mesh objects in-world with Mesh Studio there's one issue with this approach (and it's an issue with the approach, not really with Mesh Studio itself) that can be a bit of a pain: keeping mesh faces the same across each LOD level.
When I'm making something with Mesh Studio I have this approach (with appropriate resolution tweaks along the way):
Mostly this isn't a problem -- the lowest LOD should only really be visible from such a distance as to make textures a bit of a moot point. Thing is I've noticed, with recent Firestorms (for example), that a mesh object can sometimes get "stuck" at the lowest LOD when it first comes into view after being obscured by another large object. That in itself is a bit of a bother but it's made all the more worse if textures appear to get swapped.
So, with all that in mind, I got to thinking that I should be able to script something to help with this. While I wouldn't really be able to script my way out of the problem, I might be able to make a tool that lets me compare each of the linksets and ensure that the texture+tint combinations are all first encountered in the same order.
And then I realised that this script that I wrote later on last year more or less did the trick. The only problem with it was that the output didn't quite lend itself to easily scanning over the results and visually comparing them. So I made a few tweaks and the result is this:
First off I've made use of modern viewers' ability to hyperlink text, like this:
[http://www.google.com/ Visit Google]
Which, in local, results in:
Visit Google
Using this I've made the UUID of the texture just be the UUID while still being a hyperlink so you can view the texture online.
Secondly, I've stored the results and then try and output them in a single llOwnerSay. I say "try"... if the output will end up being too low so as to blow the 1024 limit, I then fall back to doing it line-by-line (I'm almost tempted, at this point, to do the whole thing via llHTTPResponse).
Finally, just for kicks, the colour data is now shown as RGB and it also links to a site that shows the colour.
The result of all of this is that, whereas the output of the old version of the script looked like this:
The new version looks like this:
When comparing two objects to check that the lists are the same I'm finding the latter a lot easier to quickly scan over.
When I'm making something with Mesh Studio I have this approach (with appropriate resolution tweaks along the way):
- Make and texture the source linkset that's exactly how the final mesh will look.
- Shift copy it, remove any faces that I can afford to lose for the next LOD level down.
- Shift copy #2 and start to remove more faces and even whole prims.
- Shift copy #3 and really go crazy on removing prims and faces while keeping the same overall shape and, of course, the same number of texture and tint combinations (for those who don't know, a texture+tint combo defines a face in the resulting mesh).
Mostly this isn't a problem -- the lowest LOD should only really be visible from such a distance as to make textures a bit of a moot point. Thing is I've noticed, with recent Firestorms (for example), that a mesh object can sometimes get "stuck" at the lowest LOD when it first comes into view after being obscured by another large object. That in itself is a bit of a bother but it's made all the more worse if textures appear to get swapped.
So, with all that in mind, I got to thinking that I should be able to script something to help with this. While I wouldn't really be able to script my way out of the problem, I might be able to make a tool that lets me compare each of the linksets and ensure that the texture+tint combinations are all first encountered in the same order.
And then I realised that this script that I wrote later on last year more or less did the trick. The only problem with it was that the output didn't quite lend itself to easily scanning over the results and visually comparing them. So I made a few tweaks and the result is this:
First off I've made use of modern viewers' ability to hyperlink text, like this:
[http://www.google.com/ Visit Google]
Which, in local, results in:
Visit Google
Using this I've made the UUID of the texture just be the UUID while still being a hyperlink so you can view the texture online.
Secondly, I've stored the results and then try and output them in a single llOwnerSay. I say "try"... if the output will end up being too low so as to blow the 1024 limit, I then fall back to doing it line-by-line (I'm almost tempted, at this point, to do the whole thing via llHTTPResponse).
Finally, just for kicks, the colour data is now shown as RGB and it also links to a site that shows the colour.
The result of all of this is that, whereas the output of the old version of the script looked like this:
The new version looks like this:
When comparing two objects to check that the lists are the same I'm finding the latter a lot easier to quickly scan over.
2015-01-02
Firestorm, Interesting and a RLV(a) issue?
I'll start out by making it very clear that this is nothing more than me jotting down something I found and noting my internal speculation about the causes. What I'm thinking (and this post is just me thinking out loud) could be (likely is) completely wrong; but I think it's worth noting down anyway.
At the moment I'm working away on building the new range of Z&A RLV cells while retiring the old ones. Given that they all contain the same script engine there's not a lot of scripting to be doing with that. Sure, there's the odd cell-specific plugin to write here and there but generally nothing I'd call "fun". The bulk of the work is prim-flinging and meshing, something I really enjoy, but it's not scripting, which I really enjoy.
A few days back, when I suddenly couldn't fling prims around so well, I did what I often do in that situation: I rezzed out a cube, got cosy with it and started scripting. This time the idea was to finally do a complete re-write of another early Z&A product to make it better and different. One of the RLV API features it makes use of is the @sit command. While working on that bit of code I decided to have a play and see just how far away (on a region) an object can be before the force sit fails.
[Caution, vague non-technical terms follow]
Keep in mind, at this point, that objects exist in two places in SL. They exist on the server and so exist as things that can be seen by scripts (because scripts live and run server-side). They also exist client-side in the sense that there's a list of "stuff" your viewer knows exists at any given time. Hence the reason why it's always suggested that people have sensible draw distances otherwise you end up potentially wasting a lot of memory and bandwidth loading up lots of objects and textures and the like that you can't really "see".
In the script I was toying with I check that any given object that is a potential sit target actually exists. Of course, the object my script is in and the object I'm verifying might be a few thousand meters apart but the script can still get information about it. RLV, on the other hand, being a body of code that exists only in the viewer, can presumably only ever deal with objects known to the viewer at any given time. Given these facts I sort of assumed that @sit might fail for objects not in draw distance.
Turns out it's a little more complex than that.
Having satisfied my curiosity that things near (the avatar/camera) can be @sit targets and things a long way away can't be (in my case a handful of things in the workshop, where I was stood, vs a chair in Mistress' house, which is about 2km away from the workshop) I got on with writing the code.
Yesterday, while doing some testing, I noticed a very curious thing. One of the target objects, which was near me (and well within my draw distance, about 33m away from where I'd have been stood when the @sit request was sent), just wasn't working. Or, more to the point, the @sit request was coming back as "ok" from my relay but I wasn't being sat.
After double-checking the code I then turned on RLVa debug messages in Firestorm and saw messages like this:
This is the point at which I started to suspect that it might be related to Project Interesting. I won't claim to know anything about how PI works other than what has been mentioned at a high level, but one thing I seem to recall reading is that it tries to do a good job of only loading/holding details of objects you can actually see. So an unobscured object in a scene, that's on the very edge of your draw distance, will be known to the viewer. On the other hand an object close by but obscured by other things won't be.
I guess you can see where my thinking was going at this point: like I said, the problem object, although only 33m away, was obscured by a floor and a wall from my location.
So, to test this idea (that it was about things being obscured, not that it's PI directly to blame), I made a little test rig on the platform outside the workshop. First I made a 3-prim object like this:
The blue bar is the root and is called "Force Sit". The two arrows are named with the UUID of two objects 23m either side of the object. Inside the root is the following code:
The idea is simple: stand at the arrows and click an arrow to be force sat on the object that's in that direction. The difference between the two objects is that one of them is in the clear while the other is obscured:
by two hollowed out cubes, one inside the other:
Initial testing never had a failure. But, I'm guessing, my viewer would "know" about the target object even when obscured and wouldn't bother dumping the data when it was fairly close by. Even heading down to the ground, walking about, and coming back up didn't make a difference. It all still just worked.
So I decided to leave it alone, all sat outside the workshop, and test it again the next time I logged in. Which I did this morning.
I got into the workshop, walked out onto the platform, detached my camera from my avatar using flycam so that my camera would stay about 38m from the arrows and about 45m from each of the target objects, and did the test.
First I touched the green arrow, which would attempt to force sit me on the object that I could see. That worked just fine.
Next I touched the red arrow, which would attempt to force sit me on the object that I couldn't see as it was inside the boxes. Nothing. I didn't move. One again I turned on RLVa debug messages and, sure enough...
It still failed. I then raised and tilted a little more until just one corner of the object was visible:
...and this time the test worked. I was force sat on the object inside the box.
That seemed to pretty clearly demonstrate it: object distance from your avatar, or your camera position, isn't the only thing that will affect how a @sit works -- it's also about if the object in question is obscured.
Keep in mind too, as mentioned above, that a relay will still reply that the operation worked "ok", but the avatar won't be sat and internally the sit will be seen as a failure (something that can of course be overcome by use of @getsitid).
The point of all of this? Well, like I said at the start, there's no actual conclusion to this; I just felt the need to document a curious problem that I'd run into and how I looked into it and what I found. It feels like it's something related to what Project Interesting has done although, of course, I'm not sure. I've also not tested this (so far) with any viewer other than Firestorm 4.6.9.
What I do know is that, if and when this code becomes a released product, this effect is something I might need to note in the documentation. People might see the product work fine on some victims but not on others and there'll be no obvious reason why this is the case.
At the moment I'm working away on building the new range of Z&A RLV cells while retiring the old ones. Given that they all contain the same script engine there's not a lot of scripting to be doing with that. Sure, there's the odd cell-specific plugin to write here and there but generally nothing I'd call "fun". The bulk of the work is prim-flinging and meshing, something I really enjoy, but it's not scripting, which I really enjoy.
A few days back, when I suddenly couldn't fling prims around so well, I did what I often do in that situation: I rezzed out a cube, got cosy with it and started scripting. This time the idea was to finally do a complete re-write of another early Z&A product to make it better and different. One of the RLV API features it makes use of is the @sit command. While working on that bit of code I decided to have a play and see just how far away (on a region) an object can be before the force sit fails.
[Caution, vague non-technical terms follow]
Keep in mind, at this point, that objects exist in two places in SL. They exist on the server and so exist as things that can be seen by scripts (because scripts live and run server-side). They also exist client-side in the sense that there's a list of "stuff" your viewer knows exists at any given time. Hence the reason why it's always suggested that people have sensible draw distances otherwise you end up potentially wasting a lot of memory and bandwidth loading up lots of objects and textures and the like that you can't really "see".
In the script I was toying with I check that any given object that is a potential sit target actually exists. Of course, the object my script is in and the object I'm verifying might be a few thousand meters apart but the script can still get information about it. RLV, on the other hand, being a body of code that exists only in the viewer, can presumably only ever deal with objects known to the viewer at any given time. Given these facts I sort of assumed that @sit might fail for objects not in draw distance.
Turns out it's a little more complex than that.
Having satisfied my curiosity that things near (the avatar/camera) can be @sit targets and things a long way away can't be (in my case a handful of things in the workshop, where I was stood, vs a chair in Mistress' house, which is about 2km away from the workshop) I got on with writing the code.
Yesterday, while doing some testing, I noticed a very curious thing. One of the target objects, which was near me (and well within my draw distance, about 33m away from where I'd have been stood when the @sit request was sent), just wasn't working. Or, more to the point, the @sit request was coming back as "ok" from my relay but I wasn't being sat.
After double-checking the code I then turned on RLVa debug messages in Firestorm and saw messages like this:
Antony's Collar: failed: @sit:{uuid}=force (invalid option)(where {uuid} was the UUID of the object, of course). Now, the object in question wasn't in my direct line of sight; it was obscured by a floor and a wall. But, like I say, it was just 33m away from me. Unsure what was going on I cammed out to it, grabbed the UUID of it again and double-checked and, sure enough, it was the right UUID. I tested again and it worked without me having changed anything in the code!
This is the point at which I started to suspect that it might be related to Project Interesting. I won't claim to know anything about how PI works other than what has been mentioned at a high level, but one thing I seem to recall reading is that it tries to do a good job of only loading/holding details of objects you can actually see. So an unobscured object in a scene, that's on the very edge of your draw distance, will be known to the viewer. On the other hand an object close by but obscured by other things won't be.
I guess you can see where my thinking was going at this point: like I said, the problem object, although only 33m away, was obscured by a floor and a wall from my location.
So, to test this idea (that it was about things being obscured, not that it's PI directly to blame), I made a little test rig on the platform outside the workshop. First I made a 3-prim object like this:
The blue bar is the root and is called "Force Sit". The two arrows are named with the UUID of two objects 23m either side of the object. Inside the root is the following code:
The idea is simple: stand at the arrows and click an arrow to be force sat on the object that's in that direction. The difference between the two objects is that one of them is in the clear while the other is obscured:
by two hollowed out cubes, one inside the other:
Initial testing never had a failure. But, I'm guessing, my viewer would "know" about the target object even when obscured and wouldn't bother dumping the data when it was fairly close by. Even heading down to the ground, walking about, and coming back up didn't make a difference. It all still just worked.
So I decided to leave it alone, all sat outside the workshop, and test it again the next time I logged in. Which I did this morning.
I got into the workshop, walked out onto the platform, detached my camera from my avatar using flycam so that my camera would stay about 38m from the arrows and about 45m from each of the target objects, and did the test.
First I touched the green arrow, which would attempt to force sit me on the object that I could see. That worked just fine.
Next I touched the red arrow, which would attempt to force sit me on the object that I couldn't see as it was inside the boxes. Nothing. I didn't move. One again I turned on RLVa debug messages and, sure enough...
Antony's Collar: failed: @sit:{uuid}=force (invalid option)I then raised my camera and tilted it down a little until I could almost, but not quite, see the target object:
It still failed. I then raised and tilted a little more until just one corner of the object was visible:
...and this time the test worked. I was force sat on the object inside the box.
That seemed to pretty clearly demonstrate it: object distance from your avatar, or your camera position, isn't the only thing that will affect how a @sit works -- it's also about if the object in question is obscured.
Keep in mind too, as mentioned above, that a relay will still reply that the operation worked "ok", but the avatar won't be sat and internally the sit will be seen as a failure (something that can of course be overcome by use of @getsitid).
The point of all of this? Well, like I said at the start, there's no actual conclusion to this; I just felt the need to document a curious problem that I'd run into and how I looked into it and what I found. It feels like it's something related to what Project Interesting has done although, of course, I'm not sure. I've also not tested this (so far) with any viewer other than Firestorm 4.6.9.
What I do know is that, if and when this code becomes a released product, this effect is something I might need to note in the documentation. People might see the product work fine on some victims but not on others and there'll be no obvious reason why this is the case.
2014-12-27
Texture shuffle script
As I've mentioned before on this blog, I do quite a lot of building using Mesh Studio. In some cases the thing I'm building requires the careful lining up of textures on the various faces of the prims that will make the final object, in others it's not so important. With the latter builds, especially those that are designed to look like they're made of wood, I make a point of "randomly" messing with the texture offsets and the repeat sign (as in: the flip of the repeat) to try and make the texture look a bit more varied when I'm really using just the one texture.
So, given something like this:
I'll get rid of that very regular pattern by going through every face and changing the relevant values until it all looks a bit mixed up. The thing is though, in a very large linkset, that can get really boring. Sure, there's a certain meditative quality to doing a repetitive task like that again and again and again but... sometimes, just sometimes, you want to get on with actually building the damn thing.
Last night, as I headed for bed, I had one of those "why the hell didn't I think of that before?!?" moments. The idea that popped into my head was that I should write a really simple script that'll do the job for me (and likely do a better job of it than I do). So, this morning, I fired up the code editor and knocked it out.
Now I can drop a script in an object like that above, touch a face that matches the faces I want shuffled, and the result is this:
Or, if I don't like it, I can touch it again and get a different random arrangement. Or another. Or... you get the idea. And, of course, if I decide that one or two faces could do with a better tweak I can remove the script and finish it off by hand.
Here's the script in question:
So, given something like this:
I'll get rid of that very regular pattern by going through every face and changing the relevant values until it all looks a bit mixed up. The thing is though, in a very large linkset, that can get really boring. Sure, there's a certain meditative quality to doing a repetitive task like that again and again and again but... sometimes, just sometimes, you want to get on with actually building the damn thing.
Last night, as I headed for bed, I had one of those "why the hell didn't I think of that before?!?" moments. The idea that popped into my head was that I should write a really simple script that'll do the job for me (and likely do a better job of it than I do). So, this morning, I fired up the code editor and knocked it out.
Now I can drop a script in an object like that above, touch a face that matches the faces I want shuffled, and the result is this:
Or, if I don't like it, I can touch it again and get a different random arrangement. Or another. Or... you get the idea. And, of course, if I decide that one or two faces could do with a better tweak I can remove the script and finish it off by hand.
Here's the script in question:
2014-11-30
New blindfold
Today I picked up another new blindfold. Like with a couple of other blindfolds I've picked up before (like here and here) this wasn't scripted to work as a RLV blindfold (in fact this one wasn't scripted in any way at all) but the creator had sensibly made it copy and modify. This meant I could make a copy and script it with Z&A's scripts for my own use.
I'm seriously pleased with it. It looks really good and, while the fit isn't perfect (I'm sure that with some careful tweaking it'd come close), it almost fit me out of the box.
As with the other blindfolds it's using Z&A's blindfolding code that has multiple darkness levels (that allow for some degree of sight) as well as total darkness. As well as that it also gives control over other aspects of in-world sight:
This generally gives Mistress all the control she could want from a vision control restraint while also allowing me to carry on working when she's not around -- albeit working under tricky conditions.
For anyone who's interested: the blindfold came from Goth1c0. Sadly it's not in their marketplace shop but it's easy enough to find in their main store. While I was over there I also picked up a rather fantastic corset piercing that is actually designed for male shapes! That deserves a blog post of its own in a day or so.
I'm seriously pleased with it. It looks really good and, while the fit isn't perfect (I'm sure that with some careful tweaking it'd come close), it almost fit me out of the box.
As with the other blindfolds it's using Z&A's blindfolding code that has multiple darkness levels (that allow for some degree of sight) as well as total darkness. As well as that it also gives control over other aspects of in-world sight:
This generally gives Mistress all the control she could want from a vision control restraint while also allowing me to carry on working when she's not around -- albeit working under tricky conditions.
For anyone who's interested: the blindfold came from Goth1c0. Sadly it's not in their marketplace shop but it's easy enough to find in their main store. While I was over there I also picked up a rather fantastic corset piercing that is actually designed for male shapes! That deserves a blog post of its own in a day or so.
2014-11-12
Why you might not want to use llTargetOmega
Earlier today, while out browsing at an event (which'll likely get more of a mention in a later blog post), I picked up what looked like a fun little gadget. It's billed as a Mad-O-Meter and looked like the perfect sort of silly prop you need to have in your inventory. I was even thinking that it could be something nicely silly to put out in the Raven Park Abbey.
Only... it doesn't really work. Well, that's not fair. It works in that when you touch the button to make it work it does its thing and picks your madness level by spinning the pointer. Where it goes wrong is what happens next.
I first tried it when Mistress and I got home from the event and right away there was some disagreement over what it was saying. We'd spin it and I'd see the pointer land on one thing and she'd see it land on another. Now, perhaps, this was intentional, although I'd hope that if it was it would be made clear (there was no notecard to say either way). For a moment though I'm going to assume that the creator intended it to work as we expected: the madness level would be seen by everyone so that everyone could all have a laugh at the same thing.
Logged in later, with my stunt double logged in on a different machine, and both looking at the device, I started with it in its initially-rezzed state (see above). I then touched it and both avatars watched it spin. Here was the result:
Obviously I can't peek at the code (it's understandably no-mod) but I'm going to make a wild guess and assume that the code is using llTargetOmega to do the spin. The problem with that is that, unless the object is physical, the spin effect is client-side only. That is, in-world, there's no spin. The spin effect is created in and only visible in your viewer. This means that it's highly likely that everyone will see the spin position differently.
This device is a good example of this happening, and why you might not want to use llTargetOmega if you want a spin on an object that should look the same to everyone.
Still, in this case, it's likely to drive everyone observing it batty as they argue over the latest result so even if it's an unintended side-effect (AKA bug) it's one that works. ;)
 |
| Me and my stunt double observing the device in its initial state |
I first tried it when Mistress and I got home from the event and right away there was some disagreement over what it was saying. We'd spin it and I'd see the pointer land on one thing and she'd see it land on another. Now, perhaps, this was intentional, although I'd hope that if it was it would be made clear (there was no notecard to say either way). For a moment though I'm going to assume that the creator intended it to work as we expected: the madness level would be seen by everyone so that everyone could all have a laugh at the same thing.
Logged in later, with my stunt double logged in on a different machine, and both looking at the device, I started with it in its initially-rezzed state (see above). I then touched it and both avatars watched it spin. Here was the result:
 |
| How I saw the pointer after giving it a spin |
 |
| How my stunt-double saw the pointer after the same spin |
This device is a good example of this happening, and why you might not want to use llTargetOmega if you want a spin on an object that should look the same to everyone.
Still, in this case, it's likely to drive everyone observing it batty as they argue over the latest result so even if it's an unintended side-effect (AKA bug) it's one that works. ;)
2014-11-08
GitHub now supports LSL!
Okay, I say GitHub now supports LSL, but I'm not sure when now is. I've being using Gist for quite some time to hold and make available various small scripts. I use it to hold the scripts and to also help display them on this blog.
Thing, for a long time, GitHub didn't "understand" LSL so I always had to add the code as plain text. This meant that you didn't get any nice syntax highlighting or anything like that.
And then, just now, I was looking at an old blog post and saw that it had syntax highlighting in the code! Sure enough, when I went and checked the language options if I started a new Gist...
That's really good to see!
Thing, for a long time, GitHub didn't "understand" LSL so I always had to add the code as plain text. This meant that you didn't get any nice syntax highlighting or anything like that.
And then, just now, I was looking at an old blog post and saw that it had syntax highlighting in the code! Sure enough, when I went and checked the language options if I started a new Gist...
That's really good to see!
2014-08-19
Listing unique textures in a build
Mesh Studio is a fairly big part of how I make things these days and one of its features is the simple way that you specify mesh faces with it. Simply put, for anyone who hasn't used it before, you create a mesh face by having one or more prim faces be the same texture and tint. If two prim faces have the same texture UUID and the same colour then in the final mesh they'll be part of the same face. Nice and easy.
Only... recently I've been having some oddness happening. MS tells you, via hover text, how many mesh faces the build will result in. On occasion I've been finding that it's reporting too high. This caused me to pull out and polish up a script I first wrote about a year ago when I ran into a possibly related problem where I found that a prim that had been dimpled, and then the dimple was closed again, would confuse MS because the non-existent dimple would be reported at the LSL-level as a visible face (not MS' fault, of course, and the issue might have been fixed by now -- I should test again).
The recent situation I've run into is with very prim-heavy builds (well over 100 prims in the source linkset) where faces that don't really exist appear to have the plywood texture on them. Setting the whole prim 100% transparent (the way you tell MS to not generate a surface) and then unhiding the faces I want fixes it every time (which has me suspecting that it's possibly related to cuts and dimples). Finding the offending prim(s) is something not easily done by hand, hence the updating of the original script.
In case it's useful to anyone else, here it is. Drop it in the root of your object and touch it and it'll report every unique texture and tint combination it finds:
It's coded to ignore transparent faces, and to ease knowing what texture is what the texture is reported as a URL that shows you the texture (eg, plywood texture URL). For what I'd hope are obvious reasons all output is done with llOwnerSay.
Only... recently I've been having some oddness happening. MS tells you, via hover text, how many mesh faces the build will result in. On occasion I've been finding that it's reporting too high. This caused me to pull out and polish up a script I first wrote about a year ago when I ran into a possibly related problem where I found that a prim that had been dimpled, and then the dimple was closed again, would confuse MS because the non-existent dimple would be reported at the LSL-level as a visible face (not MS' fault, of course, and the issue might have been fixed by now -- I should test again).
The recent situation I've run into is with very prim-heavy builds (well over 100 prims in the source linkset) where faces that don't really exist appear to have the plywood texture on them. Setting the whole prim 100% transparent (the way you tell MS to not generate a surface) and then unhiding the faces I want fixes it every time (which has me suspecting that it's possibly related to cuts and dimples). Finding the offending prim(s) is something not easily done by hand, hence the updating of the original script.
In case it's useful to anyone else, here it is. Drop it in the root of your object and touch it and it'll report every unique texture and tint combination it finds:
It's coded to ignore transparent faces, and to ease knowing what texture is what the texture is reported as a URL that shows you the texture (eg, plywood texture URL). For what I'd hope are obvious reasons all output is done with llOwnerSay.
2014-08-08
A new blindfold
It should come as no surprise that, quite often, I'll hit the Marketplace, enter "RLV", hit search and then order by newest first. While I derive a lot of pleasure from making RLV products in Second Life I also get a lot of pleasure from using them (well, having them used on me....). So no surprises that I like to keep an eye out for anything that looks fun, or neat, or just plain nice, or any combination of those things.
Last week I noticed this blindfold from PixelFashion. Given the mixture of leather and lace I knew it was the sort of thing that Mistress would really like and, sure enough, when I showed it to her she strongly suggested that it was something I should own.
And now I do:
I'd noticed from the listings that there was a non-RLV version, which appeared to be no-modify, and an RLV version which was modify. The RLV version, according to the listing, was scripted with OpenCollar scripts. While I'm sure that'd be useful for some it didn't seem very "blindfoldy" to me and, besides, I already wear one set of OC scripts in my own collar which Mistress made for me. But that wasn't an issue. What we had here was a very affordable and very attractive mesh blindfold that had lots of colour/texture options and which was modify too.
Perfect for dropping my own code in. Even easier given that I've just recently made two other personal blindfolds using purchases I'd made elsewhere so I had all the code ready to drop in.
The blindfold itself seems very well made and really does look good. The colour/texture change HUD is straightforward and the resize system that's part of the HUD was very simple to use. The other nice thing about it is that, out of the box, it was a pretty good fit for me -- very unusual even for items aimed at male avatars. In fact, I had to size it down just a touch.
The really interesting part was that, a short while after I'd bought it, the creator IMd me to ask what I thought of it. I told them that I thought it was a very attractive build and that I'd removed all the scripts and replaced them with my own because I had a particular use for it. I was rather relieved when their reaction was to be delighted by that idea.
This... right here, this is SL at its best. A content creator who allows the object itself to be modified and who actively welcomes people making changes to suit their own needs.
That made me very happy.
And Mistress is happy too because I've got a blindfold in my #RLV folder that is very her.
Last week I noticed this blindfold from PixelFashion. Given the mixture of leather and lace I knew it was the sort of thing that Mistress would really like and, sure enough, when I showed it to her she strongly suggested that it was something I should own.
And now I do:
I'd noticed from the listings that there was a non-RLV version, which appeared to be no-modify, and an RLV version which was modify. The RLV version, according to the listing, was scripted with OpenCollar scripts. While I'm sure that'd be useful for some it didn't seem very "blindfoldy" to me and, besides, I already wear one set of OC scripts in my own collar which Mistress made for me. But that wasn't an issue. What we had here was a very affordable and very attractive mesh blindfold that had lots of colour/texture options and which was modify too.
Perfect for dropping my own code in. Even easier given that I've just recently made two other personal blindfolds using purchases I'd made elsewhere so I had all the code ready to drop in.
The blindfold itself seems very well made and really does look good. The colour/texture change HUD is straightforward and the resize system that's part of the HUD was very simple to use. The other nice thing about it is that, out of the box, it was a pretty good fit for me -- very unusual even for items aimed at male avatars. In fact, I had to size it down just a touch.
The really interesting part was that, a short while after I'd bought it, the creator IMd me to ask what I thought of it. I told them that I thought it was a very attractive build and that I'd removed all the scripts and replaced them with my own because I had a particular use for it. I was rather relieved when their reaction was to be delighted by that idea.
This... right here, this is SL at its best. A content creator who allows the object itself to be modified and who actively welcomes people making changes to suit their own needs.
That made me very happy.
And Mistress is happy too because I've got a blindfold in my #RLV folder that is very her.
2014-07-29
End of an era (sort of)
Today I retired (replacing on the marketplace and deleting from the shop) the very first full RLV device I ever made. This was, in effect, the very first Z&A product. While it wasn't made to be a Z&A product -- when I made it I had no intention of going into business or anything like that -- it was the first thing I made that went on sale after Zardia had twisted my arm into having a go.
So you can imagine I paused for a moment when faced with this...
What's interesting to note about it is that it did a lot less than our more recent releases and yet had a much higher script footprint. It also had a pretty large land impact too with a prim count of 13. Back when I made it that wasn't so bad but now, with mesh making it so much easier to create devices with less impact, that seems horrifically high.
As far as I'm aware it was the oldest linkset of prims in the shop, dating from February 8th 2010.
Mistress did suggest that I should put it in a glass case and keep it on display. I'm actually rather tempted to do that. After I've found a really nice low-LI glass case... ;)
Subscribe to:
Posts (Atom)