2012-10-01

Never assume...

So, as you'll know, I've been rather slow when it comes to writing anything for this blog lately due to lots of work on a new product range and also setting up The Femdom Hunt III. Last night I was getting the latest update packs for the hunt ready and ran into a fascinating problem that reminded me that you should never assume that something that worked before works now.

Anyone who does hunts will know that one common way of letting people pick up the gifts is to have the object they're looking for set to sell content for L$0 (or L$1 for some hunts, even as much as L$10 in some cases). On top of this, anyone who's organised a hunt will know that, sometimes, you need to create and send out these objects no-transfer. This is normally done if the object is made with some third-party sculpt map and you want to follow their licence terms (most sculpt makers insist that the objects made with the maps are either no-copy or no-transfer -- a fair request for obvious reasons).

The object we've always used for The Femdom Hunt is made with a third-party sculpt map. So, for the first two hunts, we've always made the objects up, set them to sell content for L$0, set the next-owner perms to no-transfer and it's all been good. I pass the shoes to the vendors and Femdom sim owners and they put them out and it all works.

So, last night, I'm making up all the shoes for the hunt. I followed the process I've followed before. And then, for some strange reason, I decided to pass the shoe to a test account and test it. I knew it would be fine. I knew it would work. I knew it was a "pointless" test but what the hell, I had a moment of doubt so decided to test it anyway. It's always a good idea to test the "obvious", just in case. And I'm glad I did. After passing the object to the test account it lost its for-sale setting! And, being no-transfer, the test account couldn't set it for sale again (while no-transfer objects could be set to sell content, you can't sell copies or the original of a no-transfer object so, of course, by that point the ability to set for sale is disabled).

Something that always worked, that I knew would work again, suddenly didn't.

I went back and pulled out the shoes from TFH1 and TFH2, which had worked back then, and they displayed the exact same problem. I even pulled out an object from a hunt we took part in in August, that was set up the same, and it displayed the same problem too (whereas it had worked just fine in August).

Right now I've no idea if this is a bug with Second Life or if it's an intentional change with an unintended consequence. What is important here though is the fact that I didn't just assume that what had worked twice before still worked and, thankfully, didn't send out 60+ objects that would be no use to anyone and would likely confuse some.

As for the solution? In future we'll likely have to make a point of using an object we can send out full-perm and ask vendors to set it to sale for L$0 for themselves (yes, the for-sale state is lost no matter the perms). This, of course, is likely to result in more problems when the hunt starts as people either forget to set the object for sale, or set it to sell a copy, or the original, rather than content, or they do it right but forget to change the price to L$0 (leaving it at the default L$10). But there's no time for that right now so, this time around, we'll probably have to go with a content-giving script instead.

I assume that'll work.

No comments:

Post a Comment