Some Mistresses are more equal than others

For a couple of years, I was a member of the Sisterhood of the Latex Dolls. The Sisterhood is a society devoted to the love of latex and BDSM in Second Life. As the name implies, it is a Sisterhood: male avatars may apply, but must be transformed to female before they begin the path to becoming a Sister.

To become a Sister, an applicant must pass an interview that's designed to see if she's interested in what the Sisterhood is. She then must spend at least one month as a Potential Latex Doll. During that month, she spends some amount of time bound to racks in public view at the Sisterhood's home, at Latexia in the Fetish VooDoo region, naked except for collar and cuffs. She gets a series of lessons about the Sisterhood's history and principles, and at the end of that course, she is given an examination by specially selected Sisters and, if she passes, granted the right to become a Sister herself.

Being a BDSM-based organization, there are Mistresses (in two flavors, Mistress and Switch) and Slaves, as well as Trainee Dommes (in training to become a Mistress or Switch). The uniforms are different among the ranks. in theory, Mistresses and Switches can give orders to Slaves and Potentials, though there are limits: the Sisterhood as a whole operates on the SSC (safe, sane, and consensual) principle, and limits and safewords are strictly observed.

Every Sister is identified by an ID designator. I was known as M12, holding the rank of Mistress, as well as being a Priestess of the Latex (qualified to preside at ceremonies and give final exams to Potentials), Senior Teacher, and (possibly ex-) co-Head of BDSM. I put in a lot of time and effort in the Sisterhood, and it, for quite a while, was a second home for me in SL, as well as for several of the subs in my family. My SL wife, Chibi Souther, was M924; Bridget Pobieski was 218; AliceTheKitty was 531; Molly (Molly808) was 509. Other Sisters passed through our family as well.

The Sisterhood has eight core principles, known as the Eight Obediences. In theory, every Sister, from the newest Slave to the two HeadMistresses, is equally bound by them. In fact, one of the Obediences is Obedience to Equality. The Sisterhood teaches that Obedience to Equality means that, while there is a hierarchy, every Sister is equally valuable and equally bound by her duty to the Sisterhood and to the other Sisters, and to society as a whole. No Sister is better or more important than any other.

Unfortunately, this is only true if you're not a HeadMistress. If you are, Obedience to Equality does not apply to you.

Alice was a controversial Sister. She did a lot to alienate people during her time as a Potential. After becoming a Sister, though, she settled down and worked hard, doing a lot to revive the weekly dance parties at Latexia and being there for people who had questions. There were a few who refused to accept her, but for the most part, she was doing well.

Then one day, she organized a play party. At that party, Riona inion an Bandia (Becky Baroque), M37, and Alice got into a disagreement about Riona not following SSC. Edit: Alice has since corrected me. The disagreement was about Riona monopolizing the available time and play resources. (Considering the serious nature of a violation of SSC, I needed to correct the record here.) Now, Riona is a proud, haughty Mistress who does not take any sort of backtalk from Slaves, no matter what the cause, good or not. (Remember Obedience to Equality? This is not the last time you will see it mentioned in this tale.) She objected strenuously. The dispute simmered for a few days, and wound up in a meeting in the office of one of the HeadMistresses, Lara Boyle (LatexGirlLara Boyle), M85. At that meeting, Lara and Riona hounded Alice mercilessly, to the point that other Sisters present were objecting. I certainly did, and got a warning from Lara for my pains.

Alice, not to put too fine a point on it, snapped. She made a very ill-advised comment about car bombings. For reasons that are not mine to disclose here, that struck a very personal nerve in Lara. Her response was to summarily eject Alice from the Sisterhood. The other HeadMistress, Kiriko Kiama, M829, intervened, and M85 reduced it to a suspension. At that point, Alice's temper got the better of her, and she made another ill-advised comment - and this time, Lara ejected her and Kiri backed her up.

The problem is that Alice's second comment was that she was being punished for doing the same thing Lara had also done, in public. And she was completely correct. Lara had publicly commented that the Boston Marathon bombing was deserved because of Boston's prior support for the IRA.

Now, to me, Obedience to Equality means that the HeadMistresses are subject to the same rules as every other Sister. This was a blatant violation of that principle. Further, the HeadMistresses must not only be unbiased, but must be seen to be unbiased. Lara is anything but.

Lara and I had had other problems in the not too distant past. I had done a lot of work making Sisterhood uniforms for use on OpenSim grids, especially LFGrid, where Dolma Dollinger, M30, had set up a Fetish VooDoo sim as a test and possible refuge in case Second Life became unusable for some reason. We set up an organized visit, known as a dollwalk, there one Sunday afternoon. Kiri attended it; Lara objected to it, for reasons I'm still not sure I understand. In the process, Lara accused me officially and publicly of acting in bad faith. She'd later apologized to me in private, but refused to do so in public.

Even so, I was prepared to continue until she showed that she does not consider herself bound by the Obediences. That was the final straw. I left the Sisterhood, publicly and finally.

After I did, I got notecards from a few Sisters and former Sisters. A couple of former Sisters who had gone on to do other things in the SL BDSM world told me privately that they agreed with my reasoning and similar experiences had run them off as well. Several Sisters said that my departure saddened them, and they hoped to remain friends. I still consider many Sisters friends, even though I don't see much of them any more.

I have a lot of respect for Lara when it comes to BDSM. In RL, she's a former professional domme, and her methods and understanding of BDSM are quite good and largely track my own. That's what attracted me to the Sisterhood in the first place. But when it comes to the Sisterhood, I just can't accept what she's done and how she's done it.

Dolma spoke to me the other day about what it would take to get me to come back. Put simply, I won't return until the HeadMistresses operate with all of the Obediences - including Obedience to Equality - firmly at the forefront of all they do. That includes Lara formally recognizing that she punished Alice for doing something she did herself and that doing so was wrong. I realize there might be other issues about reinstating Alice as a Sister, but that's what fairness demands - unless Lara is prepared to accept the same punishment herself, instead.

Sisters are taught that the Obediences are at the center of the Sisterhood. That, to put it simply, is a lie, and a repellent one. I can't condone such with my work and my presence.

Edit, 21 November: This was Kiri's response to seeing this post:

[2013/11/18 21:57] Kiriko Kiama: (Saved Mon Nov 18 10:15:45 2013)You have been ejected from 'The Latex Dolls' by Kiriko Kiama.
[2013/11/18 21:57] Kiriko Kiama: (Saved Mon Nov 18 10:16:14 2013)You have been ejected from 'Latex Sisterhood' by Kiriko Kiama.
[2013/11/18 21:57] Kiriko Kiama: (Saved Mon Nov 18 10:16:34 2013)You have been ejected from 'Latex Doll in Training' by Kiriko Kiama.
[2013/11/18 21:57] Kiriko Kiama: (Saved Mon Nov 18 10:17:18 2013)You have been ejected from 'Latex Sisterhood Teachers' by Kiriko Kiama.
[2013/11/18 21:57] Kiriko Kiama: (Saved Mon Nov 18 10:18:21 2013)You have been ejected from 'Latexia Mall Merchants' by Kiriko Kiama.

She missed a couple, but I left them myself when I saw this.

*!:{[%CuteStoreName%]}:!* and other annoyances

I was digging through my inventory a while ago looking for some clothes I'd picked up. I knew what the store name and item name was, but I couldn't find the item itself. I had to resort to slogging through a stack of results returned by inventory search.

I have no idea why vendors insist on giving their items in inventory cute names with all sorts of special characters around them. It makes life more difficult for their customers. Yes, I know organizing one's inventory is a tedious chore. I know that damned few people do it, especially when compared to the large number of people who say they're going to do it or need to do it or get halfway through ti and quit doing it.

But making it basically impossible to find the vendor's name without knowing which sets of cute special characters they wrapped their store name in this week (yes, they do change, which just makes the problem worse) doesn't help. It just means that you have to look and look and look, manually.

Lokii Violet is a good friend (even if she does have an unhealthy attachment to flamingos! :3 ) who owns a store named Malfean Visions. Good stuff, and reasonably priced. But I sincerely wish she'd not gone with :{MV}: as her store tag. Gah.

To make matters worse, Jaimie Earst turns things around. At least if the store name comes first, once you find it, you've found everything else that vendor makes...but not Jaimie. Her stuff is named *item by Jaimie Earst. That means that it's scattered around everything else where the vendor used a * for decoration.

Why do vendors feel the need to get cute like this? I wish they'd stop.

Worse than useless

Ever since we announced that we would be concentrating exclusively on Firestorm and ending work on Phoenix, back in 2011, there's been one group of users who have been complaining loud and long: users of the OTR instant message encryption facility. They've been demanding we port it to Firestorm ever since that day and refusing to migrate until we do.

There's one major problem: OTR, as implemented in Phoenix, is worse than useless. That's because there's a major flaw in how it handles the encryption key exchange: it does it in-band, over the same channel that's about to be encrypted. There's no reason to believe that LL didn't crack it within hours of it being released.

(There's another, smaller problem: The code itself is, to put it bluntly, unreadable crap. That can be cleaned up, though.)

Cryptography is incredibly hard to get right, and incredibly easy to almost get right. The difference is that almost right is worse than no encryption at all. It gives the users a false sense of security, so that they say things over the supposedly secured channel that they would not say if they knew it was insecure.

The OTR code in Phoenix is almost right. Because of the flaw in the way it handles the key exchange, anyone who can listen to the traffic can simply snag the key as it floats by and use it to decrypt the messages, undetectably.

There are well-designed protocols to handle key exchanges and the like, as well as well-designed cryptosystems that, when properly implemented, can provide reasonable security against real-time eavesdropping. Cinder Roxley is working on implementing such a system in Firestorm, to serve the folks who think they need to encrypt their messages. This is harder than it looks, because there are a couple of constraints that don't apply to the usual case. Not only do we need to make it work without using some sort of central service, but we also need to do it without revealing the user's IP address to his intended communication partner, which a direct key exchange would do. The problem's not insoluble, but it's not easy, either.

I don't know why people think they need to hide their IM traffic from LL. Really, now. If you don't trust LL, then why are you using SL in the first place? Use some other way of getting your messages through that don't involve a third party. Some folks argue that everyone should encrypt everything as a matter of course both to confound those who would look for encrypted traffic (usually, this is immediately followed by a rant against the surveillance state) and to remove the stigma associated with encryption. I'm not entirely unsympathetic to such an argument, but it smacks of paranoia.

Personally, I think the people complaining about a lack of OTR in Firestorm need to get a life, and assess the true risks of interception are, and the costs of having their traffic monitored by LL or others. Fundamentally, such an analysis would reveal a much simpler reason that neither LL nor anyone else is monitoring what they say: they just don't care. They've got much better things to do than listen in on your steamy gay furry BDSM scene. (And if that's truly what you're worried about, how about embracing it and being proud of it instead?)

We'll do OTR, or something secure, in Firestorm soon enough...but the kind of complaints we've been hearing are just simply out of proportion.

"Self-defeating, if not horribly unproductive"

(For reasons that will be obvious, this post, even more so than most on this blog, is explicitly my own personal opinion and not that of the Firestorm team as a whole.)

For a while now, the Firestorm default grid selection hasn't included InWorldz. The reasons for this are varied, but center on a series of changes IW made to their server software that had the effect of rendering it incompatible with Firestorm, as well as pretty much every other viewer that will run with Second Life or a stock OpenSim grid. Those bugs have been there for more than a year now. When we heard about them, we went to the IW folks and asked if we could help resolve them. We never heard back, so we assumed they weren't interested. That assumption was reinforced when we heard that the IW team had forked Firestorm for an IW-branded viewer.

Because of that, some folks had reached the conclusion that we weren't pro-IW, or even IW-friendly. I can see why; OTOH, I hope they can see why we thought they weren't exactly Firestorm-friendly, either.

There's another reason that some of us, I especially, aren't exactly fond of the InWorldz team. Their lead viewer developer - who, I'm told, gets paid something for the work - is McCabe Maxsted, formerly of Imprudence. At least at one point in the past, McCabe was on record as claiming that Phoenix was nothing more than a griefer viewer because of its Emerald heritage, and because some of the same people were involved in the project.

He made this accusation on an interview show with Paisley Beebe, with me in the audience. (I was there because of a preceding segment, where my good SL and RL friend Axi Kurmin was being interviewed about something or other.) This was nine days after the launch of Phoenix and shortly after the banning of Emerald. Essentially, he said that people shouldn't trust Phoenix, and should use Imprudence, because of its open nature and embrace of "free software". (My opinion of soi-disant "free software" is another rant.)

Needless to say, this offended most of the team.

Fast forward to a few days ago, when the subject of an InWorldz Viewer release that was pretty thoroughly broken came up on the IW forum. The general consensus was that it was best to roll back a release, but then the discussion turned to Firestorm and how we were supposedly anti-IW. Cinder Roxley posted what was really happening to the forum, and that got things out into the open, and hopefully resolved. But there's one loose thread, yet...

McCabe posted:

I've said this elsewhere, but it bears repeating here: I have no interest in any kind of viewer wars, viewer blaming, or anything of that nature, and at best I'd call that kind of rhetoric self-defeating, if not horribly unproductive. We all care about the virtual world platform, and want to make it the best place possible for people. People should focus on that, instead.

I'm happy to hear that. Now, how about apologizing for that slam you laid on the team for the world to see?

The Firestorm team is fully committed to supporting OpenSim grids into the future. We want to be the go-to viewer for OpenSim, as well as Second Life. That includes InWorldz. We'll be happy to make sure Firestorm works as well on IW as it does everywhere else, as long as the IW grid isn't gratuitously incompatible with OpenSim as a whole (or even if it is and the incompatibility doesn't require a pile of code to handle). I hope that IW does what it takes so there's no technical need for a separate viewer for their grid. I've been asked to bring one of my products, the Tonya's PASS skin management system for petite avatars, to IW. I'm considering it; one of the things getting in the way right now is that I have to run a specific viewer for IW. If that changes, I'd be a lot more inclined to do it.

The ball's in your court, IW.

Exports and imports and permissions

Recently, there's been an increase in misinformation surrounding the export of objects from Second Life. Part of the upsurge is because the Singularity viewer's latest release includes the ability to export a linkset as a COLLADA .DAE or Wavefront .OBJ file, which can then be fed to things like Blender for hacking on and eventual reimport as mesh objects.

The baseline for this discussion is paragraph 2.b of the Third Party Viewer Policy, which says:

You must not use or provide any functionality that Linden Lab’s viewers do not have for exporting content from Second Life unless the functionality verifies that the content to be exported was created by the Second Life user who is using the Third-Party Viewer. Specifically, before allowing the user to export the content, the Third-Party Viewer must verify that the Second Life creator name for each and every content component to be exported, including each and every primitive or other content type, is the same as the Second Life name of the Third-Party Viewer user. This must be done for all content in Second Life, including content that may be set to "full permissions."

That's pretty simple. If you didn't create it, you can't export it, even if it's full permissions. (Much full-permission content in SL is licensed only for use within SL.) This applies to prims, textures, scripts, and anything else.

Exporters have been around for a very long time. They predate the Emerald viewer. The first copybot tools predate even the open-sourcing of the viewer code. LL had been trying unsuccessfully to get a handle on them for as long as they'd been around, and the Third Party Viewer Policy finally gave them some leverage.

Exporters are good things for some content. While any animations, textures, and the like you create, you should have on your local computer already, there are other things that get created that don't exist outside of SL unless you export them. Some, like scripts, are easy to export with a simple copy and paste. You can't copy and paste a prim, though, much less a full linkset (an object made out of multiple prims, from a chair to a full castle) with all of the complexity that goes with it (texture parameters, scripts, colors, you get the idea).

Emerald and Phoenix had an exporter. With their demise, though, there's a void in the content creator's toolset. We've been working for quite a while on adding export capability to Firestorm. Techwolf Lupindo has written an exporter, designed to be rigorously accurate and to honor the TPVP to the letter, while still giving meaningful capabilities to the user. There's a whole framework involved for selecting what's to be exported, checking the creator of every component and only exporting those components that are created by the user, and getting the data out and back in. The point is to allow a creator to back up and restore whole creations so that they could be replaced if an inventory corruption or account problem destroyed the originals, as well as permitting copying things to other grids.

It got disabled in Firestorm at the last minute because it didn't pass QA. Cinder Roxley is working hard on fixing the problems so we can enable it in 4.5.1.

Meanwhile, Singularity's Latif Khalifa wrote a function to export linksets to mesh files, and included it in the latest release. I haven't tried it myself, but I think it's a good thing overall. It lets a creator prototype in prims in SL and then refine the result into a nice mesh object. We've asked for, and gotten, permission to include it in Firestorm, though Cinder's reworked it a bit to integrate it seamlessly into the existing exporter framework.

There's been some confusion recently about having export capability and what it does to content security in SL. The biggest claim is that all it takes is removing two lines of code and it's a free-for-all. That's always, always been true in SL, ever since the viewer was open sourced. Textures, in particular, have always been vulnerable. Scripts aren't, simply because they're never sent to the viewer unless the user has the ability to edit them. (They execute on the sim host, not in the viewer.) The exporter doesn't add anything new here.

Another claim is that the mesh exporter will export any mesh object. I wish it did, actually; there's an item that's freely available and uploadable, but can't be edited in Blender, that I'd love to let SL export in a form that Blender can work on. (No, there are no licensing restrictions that would prohibit this.) But no, nobody's got an exporter that will do mesh objects. Edit: I was incorrect. Singularity's exporter, and therefore Firestorm's, will indeed export mesh objects. They will not export rigging information, however, so rigged mesh clothing and the like would have to be rerigged by any putative copybotter.

At one point, it was claimed that the Firestorm exporter was in violation of 2.b because it allowed export of a linkset that wasn't entirely created by the user. Siana Gearz even went to LL to complain about it. Since Firestorm does not export any component that was not created by the current user, and the policy says "the Third-Party Viewer must verify that the Second Life creator name for each and every content component to be exported", LL agreed that we're following the letter and spirit of the TPVP.

This is ironic, because Singularity's exporter will happily export a sculpted prim with a sculptmap that was not created by the current user. We will, of course, fix that in Firestorm.

So, to sum up, the exporters in Firestorm and Singularity don't add any ways to steal content that didn't already exist in other forms. (I'm certain Singularity will fix that one hole I just mentioned.) They do add capabilities for content creators, and that's a Good Thing. No need to get alarmed.

SSA is a success, first time out

We've all had reason to bitch at LL in the past for doing things that have, to be charitable, been less than successful in not royally screwing up the grid. To their credit, they've gotten things worked out and running well again, each time. Even so, the experience has been less than promising.

Eventually, you'd think they'd feel snakebit and shy away from big changes. Thankfully, they haven't. They took on one of the biggest problems in SL, bake fail, and seem to be well on the way to banishing it from the grid once and for all.

Oz Linden has said that SL is the only place where it's not unheard of for someone to go to a business meeting and ask, "Where did my pants go?". That's not a recommendation, folks. What it is is bake fail: your avatar's appearance doesn't turn out the way you'd intended it to from wearing clothing and such because some parts of it fail to be shown properly.

That's the whole idea behind server-side appearance. Its purpose is to fix bake fail once and for all.

The original way of doing avatar appearance, before multi-attach, was that your viewer would select the system clothing layers (shirt, underpants, skin, etcetera) to wear, either from your selection as you were putting things on or from a message from the server at login time. It would obtain the information from each piece and assemble them, then tell the server "all right, I'm wearing this list". Your viewer would then put them all together, make one texture for each major body section (head, upper torso/arms, and lower torso/legs), then upload that texture to the sim and let it pass that out to everyone to show on your avatar. That last process is called "baking".

The limitation is that the first way of doing it could only handle one attachment per attachment point. That was fine until you got to things like furry avatars who wanted to wear accessories and furry body parts on the same attachment point at the same time. The Emerald viewer came up with one way of addressing this problem, namely to define secondary attachment points at the same location as the primary; this worked, as long as the user looking at the avatar was running a compatible viewer. Needless to say, many weren't. Without server-side support, though, ti was the best that could be done.

LL added the server-side support to go along with an early release of Viewer 2. Part of that support was the Current Outfit folder (COF), which regularized and standardized handling outfits no matter how many things were attached on any given point or any clothing layer. Phoenix added proper multiattach support and dumped the old way quickly; everyone else added it as well except for the CoolVL Viewer, which did it its own, incompatible way. (But that's another flamewar we've already had.)

The Current Outfit folder and multiattach/multiwearables made life a lot simpler, but they didn't change how the avatar textures were baked. Things were still shipped back and forth between the SL servers and the viewer. Each time something was sent over the wire was an opportunity for things to screw up, and when they did, you saw the Ruth shape, or the infamous poo-colored cloud, or last week's outfit, or just plain gray. The same thing could happen for lots of different reasons on the user's computer, including things as prosaic as running the viewer on a secondary monitor. (The bake process actually used the normal viewer's avatar display routines to draw the various textures on the avatar, then read the texture back out of graphics memory. This didn't work on a secondary monitor.)

SSA (originally called server-side baking, and now you know why) is designed to eliminate that kind of error. The key is that, with the COF, everything needed to create the avatar's appearance is present at the SL servers. Since it's there, they can simply add another set of servers, called the "bake ovens", to bake the textures and ship them out. No need to traverse the Internet multiple times, each time risking the data getting lost by some $6 consumer-grade cable router that can't handle a real workload or having DNS croak in the middle of things or any of the myriad failure modes that make SL such joy to troubleshoot. Just look in the COF, tell the oven to bake the textures from this list of assets, get the baked texture back, boom, you're done.

Of course, it's not quite that simple in practice. Not only did the bake ovens have to be built from the ground up, but the viewer code had to be rewritten to deal with not having to do the pile of work needed to bake the texture and then upload it. There was a lot of code refactoring that went into the viewer side of SSA. You heard us talk about how it was a big change? This is why. This is also why we chose not to add it to Phoenix, because it would have been a lot of work we'd have had to largely pioneer.

LL did all this, and they did something unusual: they coordinated their SSA efforts closely, and carefully, with the TPV community. That's because this would not work unless the viewers were ready first, before the server components were turned on. Then they were careful to test thoroughly. And test. And test some more. Then they got the TPV community involved in testing. And we tested every way we could think of. Only then did they start rolling it out to the grid. Even that was done differently from normal. They rolled it out to one or two RC channels, from 5 to 15 percent of the grid, and left it that way for a few weeks, to get lots of experience with how it was working before they flipped the switch for everyone.

All that care paid off. Yes, there are a few problems, but those are of much lower magnitude and severity than those associated with other recent big server rollouts. There are some folks who are showing up as gray; those who are actually running SSA-capable viewers (yes, we do get complaints from folks who appear gray, only to be surprised when they get told that Firestorm 4.3 isn't going to work any more!) usually have other issues like inventory loading and such that aren't related to SSA.

Folks, LL got this one right. They took their time to test thoroughly, they coordinated with the TPV community before dropping it on the grid, they listened to feedback, and they introduced it slowly and carefully, measuring as they went.

Will this be the end of bake fail? There's still work left to do, but there's good reason to believe that yes, it really will be.

And people who complain about LL adding features before fixing basic problems: This is an example of fixing basic problems. Bake fail was the single biggest cause of support questions for the Firestorm support team. Nobody will be more happy than they are to see it go away.

We complain at LL when they screw up. Let's cheer them on when they get it right. This time, they got it right.

Last call

Linden Lab has announced that server-side appearance will go live across the entire grid this week.

This is it, folks. No more dithering. No more procrastination. No more excuses.

Fish or cut bait. (I started to use an expression the second half of which is "or get off the pot", but decided to be a bit more civil.) This is a major change to Second Life, and your viewer has to keep up. If you don't run a SSA-capable viewer, you're going to be left behind. Over 85% of the users on Second Life are already on SSA-capable viewers. Nobody's going to be sympathetic to those who aren't.

I'm really hoping that older viewers will get flushed out of SL by this change. The platform needs to advance, and it can't as long as people cling to 4-year-old viewers running on 10-year-old computers. That does not mean that they need to change how they interact with their viewer. Don't like the V2 user interface? Run Firestorm in Phoenix mode. Not good enough? Kadah Coba's doing excellent work with his Latency skin to make it even closer; that should appear in Firestorm 4.5.1. Still not good enough? Get Singularity, or CoolVL Viewer (now that Henri seems to have straightened out the current outfit folder handling). There are plenty of choices to run a modern viewer.

Yes, you might have to upgrade your 2003-vintage PC. You've been uncommonly fortunate in being able to run it as long as you have on SL. There are myriad options to get a computer good enough to run any modern viewer - yes, even Firestorm - for not a lot of money these days.

But if you're waiting till you can't use SL any more to upgrade, your wait is over. The time to upgrade was a while ago, but now you're rushing headlong at the brick wall.

Upgrade. Now.

The default SL avatar mesh sucks

I've been working on a rigged mesh avatar replacement. The idea is that it's a full-enclosure bondage suit, with some design features inspired by a story on the excellent Gromet's Plaza website; in particular, the feet are replaced by ballet boots, the hands by mittens with no fingers, and the head by a rounded hood. Eventually, I want to apply normal and specular maps to make it look like authentic latex, but that's down the road a little.

I've been using Avastar to make mesh replacements from avatar shapes for a while now. It works well, and reliably, once I figured out the requisite workflow. Avastar uses the standard SL avatar mesh, as would be required to maintain compatibility for clothing designers and the like (its intended audience). Unfortunately, that mesh deforms badly as the avatar moves.

This picture shows the biggest problem for what I'm doing:

See the weird edge sticking out on the inner thigh? That's not the only problem: there's a corresponding pocket on the other side of it that turns the edge you see into a wedge shape. That's the worst part, though the crotch deforms badly in front, as well, and the hips deform weirdly, though not as bad.

There's a JIRA, STORM-1800, that gives a start on fixing avatar weight issues. I don't know if it fixes this problem or not, though I would hope so. However, that doesn't solve my problem.

The real problem lies in the low number of vertices in the standard avatar mesh in that area. I don't know why they skimped on this way, but the avatar's old enough that they probably didn't think it was important when it was made - since that was long before SL became popular in the ways it has.

Compare this:

 with this:

The second is much less haphazard, with vertices and edges at places where the avatar needs to deform. As you might expect from looking at these, the second avatar does indeed deform much, much better with movement. It's Utilizator Mode's Avatar 2.0, his idea of what a replacement avatar should be. He gets it right, for everything I've seen.

Unfortunately, I can't use it directly, both for reasons of intellectual property and because the shape isn't what I'm looking to make for this project. He also only offers this in a female version; I want to make a male suit, as well, and the proportions would need fixing for that. Considering that he offers the avatar for L$300, it's not reasonable to expect that he'd release the base avatar mesh in a usable form for others to work with directly - and rip off and sell as their own.

What this tells me is that the only way to get from point A to point B is to completely rebuild the avatar mesh from the ground up, as Utilizator Mode has done. That's a metric buttload of work, and one that not only am I not prepared to tackle for this project, but is probably beyond my limited artistic abilities. As an artist, I make a decent programmer.

Reweighting the SL avatar mesh is probably going to be of only limited utility because the geometry just isn't there. That's also a nontrivial amount of work, all by itself.

What a nuisance. Poor design decisions - or ones that are simply optimized for a much different set of conditions than ones that actually prevail once the product is launched - have bitten number products as they go through the lifecycle, and the SL avatar certainly is an outstanding example of that.

A difference in approach

There's been a lot of back and forth between me and Henri Beauchamp, and me and Siana Gearz and to a lesser extent Latif Khalifa, about the difference in development approaches between Firestorm on the one hand and CoolVL and Singularity on the other.

Henri commented, on an earlier entry on this blog,

Using the wrong tools (a code repo) and method (merges, instead of a a true fork and backports), you waste your time while I work alone but much faster.
For your info, the *only* tools I'm using to program are a text editor (nedit), and the 'grep', 'diff' and 'patch' commands.

He also noted, in another comment,

Also, April is quite late for SSB support (I had it fully working and released in January, i.e. 3 months sooner)

There's only one problem, but it's a doozy. As it turns out, his SSB code has a major bug in it. SUN-99 describes a corruption in the Current Outfit folder (COF) that is caused by CoolVL's implementation. It only affects those who use CoolVL and change outfits in SSB regions. The result is multiple copies of the COF. This cannot be fixed by a viewer. It requires Linden intervention. Since the SSB servers depend on it being right, the user's avatar never updates correctly, and thus their appearance is broken for everyone but the user themselves.

Henri has never made it any secret that he disagrees strongly with the whole idea of the COF. In a comment on Nalates Urriah's blog, Henri rips it up one side and down the other, explaining how it was not necessary, that LL's old way of doing the equivalent could have been extended to handle multi-attach (the original reason for the COF), and that his method of doing it is superior.

That all may well be true. Unfortunately, there's one major flaw in his thinking: The viewer interacts with the Second Life servers. Those servers have very specific expectations of how the viewer will behave. Henri's viewer does not behave that way. Instead of using LL's code which is known to work with the server, he implemented his own - and got it wrong, to his users' detriment.

(And all of this is quite aside from one problem with his implementation that the COF doesn't suffer: his implementation makes what you wear at login be the same thing you were wearing when you last logged out on that computer. If you switch computers and change outfits, when you go back to the original machine, you'll change back. This is not what the user expects.)

The same thing goes for Singularity, in a different area of the viewer. Monty Linden has done a lot of work on the HTTP server and client in the LL server and viewer. The original implementations were broken in a number of ways, and caused many strange and wonderful problems in the viewer and the users' experience. Monty rewrote large portions of that to do things in a much more standards-compliant way. Included in that is a throttling mechanism to prevent one or a small number of users from hogging the simulator resources and making everyone else's responsiveness worse.

Singularity's Aleric Inglewood thought he could do HTTP better than LL. While he started before LL announced their improvements, he stuck with his code even after Monty's was released. The results have turned out different from what he expected. Now he's struggling to find ways around the throttles, and wiring in fallbacks to the old way of fetching textures via UDP when that fails. Since meshes can only be fetched via HTTP, he's kinda stuck there.

Again, this is because the SL servers expect the viewer to act in a particular way and don't deal well with those that do not. In this case, it's an active defense, instead of a simple breakage, but the results are still the same: a broken user experience.

This kind of incompatibility is one major reason we don't reimplement any functions that go straight to the LL servers. We can and do make user interface changes. We keep our cotton-pickin' fingers out of the server interface code.

Nyx Linden just sent out a long email to the TPV developers' list outlining exactly how the viewer should treat the COF, including things to verify in the code. Since we use the code from the release viewer, I don't expect we'll have to spend much time on that. Henri's got some work ahead of him.

This ties in with a related point: when LL rolls a new feature, we can implement it by just using their code and splicing in our changes. We don't have to backport it. We certainly don't have to rewrite it, let alone reinvent it. We can just use it. We deliberately chose to hack on the V3 UI, trying to maximize the amount of code in common between V3 and Firestorm, instead of welding the Phoenix UI code on the side for this reason.

Henri may be able to do things faster, but a wrong answer is still wrong no matter how fast you get it.

Yes, we do seem to piddle around and take our own sweet time and waste time on QA (according to Niran) and so on...but when we release it, we get it right.

So I'm not particularly interested in how Henri or Singularity's development model may be better than Firestorm's. I care much more about putting out a viewer that users can depend on, first time every time, and that gets the job done without screwing up users' inventories or hammering the LL servers. No, we're not perfect (see Firestorm 4.4.1). We can always improve. We know enough to realize that. So do our users, and that's what really matters.

Server-side appearance is rolling

LL has started rolling out server-side baking.

Inara Pey has an excellent treatment of just what it means, especially to folks who aren't running SSB-capable viewers. Phoenix users, this means you.

Still don't want to upgrade? See figure 1.

Dealing with a screwup: The story of Firestorm 4.4.2

Monday was Canada Day, eh? It was also a big, busy, pain in the ass of a day for the Firestorm team.

The first we heard of the problem was when Jessica Lyon told us in the developer chat that there was a big problem with Firestorm 4.4.1 and she'd convinced LL to give us until Tuesday to put out a new release before 4.4.1 was blocked.

To explain what the problem was, I need to first explain the statistics system. Linden Lab keeps statistics on a wide variety of performance measurements in the viewer. You may know that there's a crash statistics list that TPV developers in the Directory get if their viewer reaches a usage threshold, and that determines the order viewers are listed in the Directory each week.

There's far more than that, though. When Oz Linden says that 75% of users can run with Advanced Lighting Model turned on and get acceptable performance, that number didn't come from a Ouija board. It comes from actual reports of system configurations and measured performance sent in by every viewer directly to LL in the form of a statistics message.

That statistics message is supposed to be sent in once every 10 minutes. It contains performance and resource utilization numbers. It does not contain any personally identifying information. It's fed directly into LL's statistics system, where it gets crunched.

The problem was that Firestorm 4.4.1 was sending that message every 30 seconds instead of every 10 minutes. The statistics servers were getting hammered badly by having to deal with a sudden 20-fold spike in data. Oz discovered this when he went to generate the statistics report for last week.

There's a clause, 2.f, in the Third Party Viewer Policy that says:

You must not impose an unreasonable or disproportionately large load on our infrastructure or interfere with our providing the normal functionality of Second Life.

(The statistics message itself is required by 2.h of that same policy.) Guess what we did? LL was completely justified in telling us to fix it or else.

The reason we were spamming the server turned out to be a leftover from our helping to test server-side baking as it got close to its rollout next week. LL needed a big test case, and not just with their own viewer. We were in the final stages of doing QA on 4.4.1, so we made a change to enable enhanced logging of the viewer's responses to appearance update messages so that anyone who encountered a problem would have already collected the information needed to debug it, and LL would have a leg up on actually finding the problem. Part of that change was enabling a debug setting that sped up the viewer statistics message.

We handed out builds with that change made to folks to use in the test. The test was a rousing success by all reports, and LL was quite happy with it.

The problem was that we never undid that change in the release branch of the code. Oops. (All right, it was more of an "aw, SHIT!".)

So we had this problem to deal with. We talked for a bit about how to deal with it. There was no actual code change needed. All we had to do was change the default of one debug setting and, for the sake of completeness, the contents of an XML file used to control how the viewer logs data. Unfortunately, there is no good way to get the userbase to make this change en masse. Not only would we miss many who ignore messages of the day and such, making the changes would be difficult for many of them. (Users of SL are, by and large, not techies. This is a Good Thing.) It quickly became clear that we were going to have to spin a new release.

We knew right up front that we needed to own up to the problem and be open and public about dealing with it. Our users expect, and deserve, nothing less.

We also chose to block 4.4.1 ourselves, rather than have LL do it. We have the ability because Firestorm downloads information from our servers at startup, and one thing it loads is a list of blocked releases. When a release is started that's on the blocked list, it puts up a message, with some explanation text, and then exits when the user clicks OK. This does not require that any information about the user be collected at all, let alone sent to the Firestorm Project servers. If LL were to block it, on the other hand, the user would get a message about how they were not allowed to log on to Second Life with that viewer - with no further explanation. We felt this would cause more harm from user confusion than the very limited benefit that might come from having LL be the boogey man would give. Unfortunately, while the statistics message spam probably does not hurt OpenSim servers, our method blocks 4.4.1 for OpenSim users, as well.

There's a bug in the GPU table that causes problems for folks using ATI Radeon 6000M, 7000M, and 8000 chipsets. We have a fix for that. There was a fair amount of discussion about including that fix in 4.4.2. We decided eventually not to do so, because it would have taken much more QA than the change that was forcing the update, and that would have taken time we just didn't have. Jess had gotten LL to extend the deadline for the block to the next day; they weren't going to sit still for a 2-day QA cycle, especially pushing up against the July 4 holiday.

Finally, we decided to pull 4.4.1 from distribution immediately. We decided that there was no benefit in allowing people to download a release we knew was broken and that we knew we were going to have to block. We rolled back the version check on the website to 4.4.0 so people wouldn't be nagged to install a version that they couldn't get, and Jess wrote the first of two blog posts telling people we were going to have to force an update.

Then we waited while 4.4.2 was updated and built. We had to do that twice because of an error in the first build that omitted the very SSB compatibility flag that was the reason we pushed out 4.4.1 when we did. Still, we got the builds done, and the QA team turned around a very quick smoke test. We pushed 4.4.2 out the door, published the second blog post, waited a few minutes, and blocked 4.4.1.

Then we all joined the support groups and dealt with the flood of questions and complaints from the users. Oy.

The questions themselves weren't so bad. We knew we were going to have to deal with that. There was a massive volume of them, to be sure, but that's why we all piled in. Chat lag in the Firestorm Support English group was ferocious. (Why, oh why, did LL have to fix SVC-7031? :-) ) The questions were repetitive, and many of them were answered in the blog postings that we'd asked people to read. That wasn't the annoying part, though. Not even the guy who refused to read the blog post and demanded that we answer in 10 words or less why 4.4.1 wasn't good enough any more was truly annoying. (By now, you should understand just how impossible that request is to satisfy.)

There was a very common reaction of "Is this some kind of a joke?" (Or a hoax?) We wish it was, and that people were asking the question says good things about the users' perceptions of the quality of our code.

There was a fair amount of unhappiness that were were pushing out a new release so soon after 4.4.1. We expected that, and deserved it. We screwed up; this is the price of that screwup.

No, the annoying part was the tinfoil hat brigade. There were people saying "ZOMG, they're capturing our personal information all over again! Just like Emerald!" Uh, no. There was even one guy who was convinced that we'd stolen his credit card info, though we did get him calmed down eventually.

The wait to get 4.4.2 built, tested, and pushed out to the download servers was interminable, but it finally got out there. That was when people discovered that installing 4.4.2 over the top of 4.4.1 was a non-event. They didn't even have to uninstall 4.4.1 first, though many did. A full clean install with manual clearing of caches and the like wasn't needed for those upgrading from 4.4.1. The install was universally reported to be painless and take about 5 minutes or so. They even loved the performance, though there shouldn't be much reason for performance to improve much. We'll take it.

Now, it's all over but the cussing. People will continue to be surprised over the next several days that they can't log in any more with 4.4.1, and the support folks will have to explain over and over and over. (As I write this, 4.4.2 has been downloaded just over 26000 times; we have far more users than that.) But the LL servers aren't getting hammered any more, and, I hope, people will forgive us for the madness.

We did learn a lesson about our release process: Once we branch for release, nothing goes in without being tracked and verified before we actually spin the release code. We had such a process in place, but it broke down. That won't be allowed to happen again.

We didn't like doing this. It was a lot of work, and a lot of hassle, and made our users' lives harder than they should have been. Forcing folks who'd upgraded on our strong recommendation to do so again, five days or less later, is not particularly user-friendly. We had no choice, though, and I don't know that there's much we could have done differently once the problem became apparent.

Tracking LL's big changes

Ever since the release of materials in LL's viewer 3.6.0, there've been calls for us to put it in Firestorm. I'm quite receptive to the idea. Since I worked on the materials project, I know what it can do, and would love to see Firestorm get the capability to use it. I also think that it won't take off until we add it to Firestorm, just as mesh didn't take off until we added it to Phoenix.

There's a big roadblock for us, though. As I pointed out in a thread on SLUniverse:

The problem isn't that the materials code depends on the CHUI code directly. The problem is that the merge process depends heavily on code changes being applied in the same order to the same files. The CHUI changes hit a large part of the viewer codebase. (That's why it took LL a year to get CHUI out the door.) Inevitably, those changes hit files that the materials project changed. When they do, if you don't merge in the CHUI changes first, then you have to do a lot more work to fit the materials project changes into the code - work that you'll have to undo when you finally get around to putting the CHUI changes in, or will have to do over and over if you ignore the CHUI changes altogether.

This is the real reason that TPVs track the Linden viewer so closely: self-preservation. The more we diverge from the LL viewer, the harder we have to work to keep up with LL's changes.

CHUI is, for us, a big no-op in functionality. The changes are mostly duplicative of changes we put in Firestorm a long time ago, though different in design (and not particularly better, either). Still, the changes permeate the codebase, and we have to accommodate them (mostly by bypassing them with calls to our own code, but not always). This is a nontrivial exercise.

We're working on that now. We started working on it in earnest right after releasing 4.4.1. The code compiles and links and runs, but has lots and lots of bugs in it. We're working through those, one at a time, and will get it up to where we think it should be as quickly as we can. Once we do, then we can put stuff we actually want in the viewer.

Nalates Urriah pointed to my comment on her blog. Her post drew two comments, one from Henri Beauchamp and one from NiranV Dean. The two comments are worth replying to for entirely different reasons.

I've said before, and will keep saying, that I admire Henri for his efforts to keep the V1 UI interface alive in CoolVL, but I think he's fighting a losing battle. He commented,

“I told you, Tonya…” This is what I can say, seeing how the Cool VL Viewer (a v1 UI viewer that Tonya pretended would be unmaintainable in the long term, see: http://sldev.free.fr/forum/viewtopic.php?f=5&t=584#p2430) had its experimental branch with materials implemented only a couple of weeks after the code was opened by LL (and v1.26.9 is now kept exactly on par with LL’s v3.6 materials viewer), and how Firestorm lags big time behind every new feature (the Cool VL Viewer was also the first TPV with SSB, back in January 2013, while Firestorm only gained it recently.

This proves how prominent is a development model over the size of the developers team…

This is one case where Henri didn't have to worry about LL changes. The reason is in the name: CHUI is a UI-specific change, one Henri could largely, if not completely, ignore. That's a rarity in the world of SL viewer development, and he will seldom be so lucky.

Henri's incorrect when he says Firestorm got SSB capability "only recently". The initial SSB-capable Firestorm release was publicly available April 22 of this year, but the code was in the codebase much sooner, back around the end of February.

As for the difference in development models, it's obvious that Henri spends a large amount of time on his viewer, more so than any individual member of the Firestorm team. Again, that's admirable, but I still have my doubts as to how sustainable it is over the long run.

Niran's comment is more revealing:

Just keep in mind that a total retard like me is faster in implementing Materials and SSB and keeping up with LL while still doing heavy UI modifications than Firestorm. Mostly because i dont have a freaking huge Viewer with millions of features to maintain… and because i dont do 2 weeks QA. 2 weeks QA are 2 wasted weeks in which i could have collected a week worth of bugreports, fixed them, worked more on other stuff, make a release, collect bugreports and feedback on that one and, fixed stuff, work even more on other things and update a second time.

"I don't do 2 weeks QA." That says it all right there. Niran's viewer doesn't get any QA, as far as anyone can tell. He slaps it together, tests it himself for some minimal period of time, and throws it out to the world.

QA is never wasted when you're working on software that's intended for someone else, never mind a lot of someone elses, to use. That he derides it as he does shows hos true mindset: he hacks on code rather than making good software.

Niran's a programmer, not a developer of production-quality software. He has no understanding of the difference. That's fine for him and his users, but the average user would much rather have a viewer that is actually likely to work well and stably rather than have the absolute newest shinies. You get there by moving more slowly and carefully than Niran does, actually working to integrate patches form others instead of just dropping them in, and actually doing meaningful QA with more than just one or two testers.

The Firestorm team does what it does the way it does it for good, sound reasons. I think the proof of how well we succeed at it is in the viewer we put out.

Strawberry Singh's Proportions Challenge

Strawberry Singh's been running a meme the past few years about avatar shapes. This year's entry is on proportions. It seemed like an opportunity for me to talk a little about mine.

First, here's the picture:

My shape was created by Strahl Parx, owner of the Chained Tail club for furries. The design concept was that I am an athletic tigress, not so much a voluptuous one. After all, a tigress must stay in top physical condition in order to catch prey. I'm also deliberately tall. An alpha tigress is a big kitty. Still, it's intended to be blatantly, in-your-face sexy, with more than a little dominance thrown in. I'm very happy with it.

I'll also note that the Avatar Ruler is quite accurate, unlike the average scripted height detector. How do I know this? Because it agrees exactly with the height display in the Firestorm shape editor, and I spent a couple of days playing with that to get it exactly right using prims as rulers instead of depending on the size reported by LSL.

And now for Strawberry's questions:

1. Do you try and keep your avatar’s body proportionate and similar to the “average” proportions in the meme post? – No. Then again, I don't tweak my shape much at all, so it looks good as is and doesn't get changed.
2. What do you dislike the most about the SL avatar mesh? – The weighting and UV mapping cause problems, especially around the upper thighs, crotch, and center of the chest. This has been bothering clothing designers for years, and especially makes it next to impossible to make a leotard look like what you actually look like wearing one in RL. The upper thighs deform very badly, as well, as the legs move. There's a JIRA about this, STORM-1800, but that seems to have been caught up in the foofooraw around the mesh deformer.
3. Does it bother you when you see other avatars that are not proportionate at all? – Only if it's very badly off of normal.
4. Even though this is a virtual world and people can be anything they want to be, do you feel when they are in human form, they should try to keep their proportions close to average? - Not even a little bit. The beauty of SL is that you can be whoever and whatever you want to be, deep down inside. 

I'm more than a little unhappy that the mesh deformer seems caught up in ...some form of limbo. I've heard lots of theories about it. The most common one is that Qarl Fizz annoyed LL to the point the deformer won't ever actually get into the viewer. I can vouch for Qarl being an annoying so-and-so - he pissed me off rather thoroughly when he brushed off my offer to help with the deformer UI in the manner he did, but his problem with me stretches back to the Emerald implosion - but that seems like a poor excuse for keeping it out of the viewer. I think it's more a matter of simply not quite being ready for prime time by whatever metric LL is applying to it.

Even so, my shape is such that very few mesh items work for me. The breast size, torso muscles, and leg muscles, especially, are way out of the norm. Because of this, I have essentially no mesh clothing, and won't until the deformer goes live.

I don't think I'll change a thing until then, though. There's plenty of good stuff for me to wear.

I told you so!

I don't normally indulge in "I told you so", but this time I'm going to make an exception, because it just feels too good.

Today, Nyx Linden announced, in a posting to the TPV Developers mailing list, that the tentative date for the start of the rollout of server-side baking has been set for July 9. The date is subject to change if showstopper bugs are found, and there will be another round of testing, but in Nyx's words,

Please consider this an official warning that this is imminent - We've been saying for a while that we're getting ready for release. We hope with a solid date in mind, all viewers can start messaging to their users that they will need to update or they will start to see issues. 

As you should know by now, once SSB rolls out, old viewers will only see other avatars as clouds, and new viewers will likewise only see users on old viewers as gray. In short, your SL will be significantly restricted. We've warned you this day is coming, and it's finally here.

I've been saying for quite a long time that LL would do something that would render old viewers unusable. What I thought would be it turned out not to be, but I knew that someday they would do so. They would inevitably get to a point where they were going to have to make a choice between preserving compatibility and advancing the platform. When that choice came, they would do what would be needed to advance the platform.

This is that something.

I've been telling folks about this ever since we started working on Firestorm. I knew that, at some point, Firestorm would be the future-proofed solution for access to Second Life for folks who think that Viewer 3 does not fail to suck.

Guess what? I was right all along.

Yes, I told you so. Nyah nyah nannie nannie boo boo. And here, have a side order of neener neener, too.

To the folks out there who have been accusing me of lying whenever I bring this up (yes, Archangel Mortenwold, I'm looking at you, you hopeless sack of male bovine exhaust): I don't lie. I calls 'em as I sees 'em. I saw this day coming. I warned you about it. You said I was lying. I wasn't. Now pull your head out of your ass and update your viewer. I told you you were going to have to, years ago.

To the rest of you, you now have a deadline. Upgrade your viewer to something that supports server side baking - and your hardware, if you're running something that won't handle a modern viewer - or leave SL. The choice is just that simple.

You get the customers you deserve

I'm friends with several designers of clothing and jewelry and suchlike in SL. I'm considering joining their ranks, if I can learn to get what I want out of Photoshop; I've recently learned how to make latex clothing, and it seems there's always room for another designer. But that's not what's inspired me to write.

It seems like themed discount malls are the new hotness. I hadn't heard of this kind of thing before, and certainly hadn't gone shopping at one. Apparently, for a nominal fee, a vendor gets a small number of prims for a couple of weeks to sell stuff that fits whatever the designated theme is. Run well, this supposedly makes money. Fair enough.

However, it's imperative, in any business, to remember who your customers are. In this case, the mall's customer is the vendor; their product is the mall and the buyers who come to it to suck up the cheap bargains. That means the mall needs to treat the vendors well if they expect to actually get them at all, much less for more than one period.

I'm told that there are good ones out there. Genre was the example cited.

And then there's the one that we've been discussing tonight: Total Anarchy. I'm not on their radar. I doubt they care about a small BDSM furniture vendor. Friends gave me a copy of their solicitation notecard.

Merciful $DEITY. The whole thing comes across as "we're small, we're new, nobody's ever heard of us, but we're so awesome that we can treat you like shit and you'll still beg us to let you in!"

Uhm. No. Just no.

They start off with a disclaimer:

First off we are COMPLETELY non politically correct here.  This discount room is not for the faint of heart, nor those who get easily butt hurt. There are no refunds for fees for any reason without reasonable notice - and by notice we mean minimum 48 hours - Got it? MINIMUM 48 hours. Once you commit and submit your info, suck it up and get your shit done. We're not your whores and will not ride your ass. If we were your whores, you'd still have to pay us. Get your shit done and on time.

This comes before the description of what the hell they're even selling!

The whole notecard follows that same approach. They seem to think that their customers are lazy shits who won't get things done on time and within prim limits and in accordance with the rules. If you don't do things exactly right, then they keep your money and give your slot to someone else.

This would be annoying as hell if the amounts involved weren't so utterly trivial: Their store fee is L$50 for two weeks! Fifty Lindens!

Oh, and they're running a contest for pictures, and the winner gets L$175. Tip to the winner: Don't spend it all in one place.

Here, let me explain a bit of business 101. You get the customers you deserve. Treat your customers well, you get good ones who stick around. Treat them like shit, you get shit for customers.

These folks start out by treating their customers like shit. Guess what they'll get? Hint: Not the good ones who won't cause drama. No, they'll get the assholes who'll quibble over fifty Lindens and come in late and then raise hell because they won't get exceptions in the rules made for them.

And that L$50 fee? That just screams "I'm small potatoes!". Reality check here: That's about US$0.20. Twenty cents. I could dig up six months' fees if I'd just pull the front seat out of my car and do the cleanup I keep wanting to. The couch change could buy their entire mall.

Here's some free advice for these idiots: Price your product like it's worth something. That L$50 had me thinking "No. Just no." before I even read the notecard. If you walk into a new car showroom and the sticker price is $10K, that instantly sets your expectations: don't expect Mercedes, or even Chevrolet, quality. Your money will, if you're lucky, get you the quality of a 1989 Hyundai Excel.

The same goes here. Even if they weren't being outright assholes to their potential customer base, that price would have me thinking "Not worth messing with".

Anyone want to speculate on the over/under for how long this thing lasts? They claim to have sold out one round and into the second, two weeks each. Personally, I don't think they'll sell a third, any at all.

They're expecting problems. They'll get what they expect, and more, and it'll largely be their own fault.

One thousand six hundred sixty five

That's how many different versions of different viewers were reported to log into SL last week, according to Oz Linden at today's third party viewer meeting. You can see the recording on YouTube. The discussion starts about nine minutes in.

One thousand six hundred sixty five.

Think about that for a moment.

That's beyond anyone's ability to test thoroughly. The combinations quickly grow well beyond insane to downright impossible.

Even individual TPV teams can't test their own viewers thoroughly. Out of that 1665, 50 are different versions of Phoenix, 151 of Singularity, and 262 of Firestorm. Many of the latter two are probably developers and self-compilers, but still...LL has real money to pay for resources to sit and test viewers. Those resources aren't endless, and the time certainly isn't. If LL can't, a team of volunteers like the Firestorm team damned sure can't!...never mind even smaller teams like Singularity, or individual developers like Henri.

And that doesn't even begin to take into account viewers for which the maintainers have long since given up, or left SL, or simply disowned the code.

This came up in the context of a serious bug in the server-side baking code. The bug causes people using Phoenix or 1.23 who teleport into a server-side baking region to be prompted to save changes to their avatar - and that save corrupts modifiable skin, eyes, or system clothing. Permanently. Unrepairably. Gone. Poof.

Oz's point was that they'll try very hard to fix the bug - but they won't know for sure they've fixed it, simply because it's impossible to test all the cases. All they can do is hope, and if you are using an old viewer that doesn't support SSB, you're going to be out of luck.

My point is much simpler than this.

UPGRADE YOUR FUCKING VIEWER!
NOW!!!!

Really, people. There is NO EXCUSE any more for running older viewers that don't support the way SL works now. By now, you can even get second-hand machines for not a lot of money that will run Firestorm just fine. You're going to have to bite the bullet.

We put in a metric crapload of work to make Firestorm something that people of all abilities - even those firmly wedded to Phoenix - can use and use effectively. If you don't like the result, fine. Get Viewer 3. Get Singularity. Get Exodus. Get CoolVL. Get something, anything that supports SSB, but do it now!

If you don't, don't come crying to me when your inventory gets ravaged by some bug that nobody could reasonably test for.

I wish we got paid!

When Jessica Lyon posted about dealing with less than wonderful user interactions with the Firestorm team, she disabled comments. That didn't stop one person from commenting, though...she commented, on the next post after that (about 4.4.1 on the way),

I find your last blog post (before this one) to be very amusing. You did an excellent job making people believe that you are doing all this voluntarily. I won’t be surprised if even your team did not know the truth behind all this.

I guess no one knows that you sold Firestorm to LL, right? No one knows either that you currently work for LL, isn’t it? LL manage to do a fine job making people work on its viewer voluntarily without having to spend a dim (well, besides your monthly paycheck of course).

Anyway, I know pretty much that a lot of peoples won’t believe but if you (the reader) REALLY want to see proof on how Firestorm is now the property of Linden Lab… send me an e-mail!

I'm going to channel my friend Axi Kurmin here. What the. Nickel. Plated. FUCK?!

This is wrong on more levels than I care to think about.

For starters, Firestorm is owned, so far as any viewer can be owned, by The Phoenix Firestorm Project, Inc., a nonprofit corporation, legally organized and in existence for a couple of years now. To sell it would require either selling the corporation - a legal impossibility; non-profit corporations aren't owned to begin with - or the corporation agreeing to sell the code. It has not done so.

As a practical matter, to sell the code would require the agreement of every developer who's contributed to it. There's a reason that LL requires every code contribution to its viewer be done by someone who has a signed Contributor Agreement on file with them. That's the only way they can guarantee they can do what they need to with it, with no encumbrances. We have no similar agreements with our contributors, because we have no intention of ever doing anything with the code but releasing it as open source under one common license.

Then there's the more practical matter: Jess knows just how destructive it would be for her to accept payment from LL for Firestorm. There are lots of reasons that the folks involved with the project contribute, be it code or support effort or testing. None of them involve money. We do it because, fundamentally, we care, if not about the users, at the very least about our own Second Life experience. We pour lots of time and effort into it. I would venture to guess, at this point, that the effort we've put into Firestorm coding above and beyond the LL codebase - never mind support! - would add up to somewhere on the order of 10 man-years. For one person to be paid for all this effort would destroy the team, probably beyond any hope of recovery, and render the code permanently unusable as a base of effort going forward.

Yes, I've gotten some material compensation for my viewer efforts. Not for working on Firestorm, though. I've been involved in the LL materials project, and for that, I got an "I contributed to your Second Life" T-shirt and this nifty green laser pointer:

Guaranteed to warm the heart of any true geek. I play with it often. (But never point it at an aircraft. That's just st00pid and dangerous and illegal.)

Mind you, I'd love to get paid in real dollars for working on the viewer. So would my bank, my mortgage company, my car lender,... But it's not going to happen, and that doesn't bother me very much.

The original commenter simply doesn't understand the realities of the situation. She's either deluded or trolling. I've probably given her more effort than her comment deserves, but I did feel like shining a green laser pointer on the absurdity of the idea.

Dragging people kicking and screaming into the future

NiranV Dean makes a viewer that has a small but devoted following. He got there by having his viewer adopt every new rendering feature the moment someone codes it up, importing patches from anywhere he can get his hands on them, and generally living on the bleeding edge of technology.

That's fine, if that's what his users want.

Niran also spends a lot of time and energy on spreading hate in Firestorm's direction. His latest screed has plenty of it.

Fundamentally, it seems that Niran's complaint is that we're not dragging people into the glorious V3 future fast enough. He doesn't like that we port features from Phoenix and other V1 viewers. He thinks we're coddling people, supporting their "lazyness" and "stupidy" (sic) when we should be telling them to "STFU and get along with it".

Niran's argument shows a fundamental lack of understanding of at least three things.

To begin with, he fundamentally fails to understand the relationship between users and developers. There's no way a developer can force a user to do a damned thing. Users know what they want, generally, and will do what it takes to get that. They'll happily skip upgrades, they'll switch software, they'll complain mightily, and they'll do what they want to do. If we told them to "STFU and get along with it", they'd reply "FOAD, we're using what we like".

Second, he thinks we're not trying to drag our users along because we're afraid of losing our userbase. He has cause and effect backward. We're not doing this to amass the biggest userbase in SL. We have the biggest userbase in SL because we make a viewer that people want to use. We're giving people what they want, whether or not Niran approves. The moment we stop giving them what they want, they'll bolt - and rightly so.

Third, he doesn't get why we do this. We pour thousands of hours of volunteer effort into Firestorm because we want to improve people's SL user experiences - including our own. We do it to make a viewer we want to use ourselves. It's called "scratching your own itch", and it's the real reason open source volunteer developers do this. We know what we want from a viewer: fast, stable (comparatively), feature-rich, easy to use. Firestorm reflects those choices, as Niran's viewer reflects his.

We are all SL users, often heavy users with lots of activity inworld. We want a rich Second Life environment. That includes a wide range of other people, of varying levels of expertise and varying amounts of computer hardware, bleeding-edge and not-so-. We can't satisfy everyone's needs, nor do we want to. We want to satisfy the needs of the folks who use our viewer, though, and we're doing a pretty good job of that if I do say so myself.

Considering Niran's rant, I have to ask myself why he doesn't attack Singularity and CoolVL with equal or greater fervor. If we're not dragging people forward, they're firmly anchoring them in the past. I guess he just wants to tear down the biggest kid on the block instead. It's telling that, while many people moving away from Phoenix are moving to Firestorm, just about as many are moving to Singularity.

In any event, even if we were inclined to try to drag people into the future, there's no reason for them to actually go there. Users are remarkable that way. They'll do what they want.

If I wanted a buggy, unstable, bleeding-edge viewer, I'd run Niran's. I don't. I want what Firestorm gives me: feature-rich, a UI that makes more sense, and quite stable (as SL viewers go). I work on Firestorm to help provide that. The day Firestorm takes the direction Niran calls for is the day I fork it and keep it going in the direction we've been following.

Go ahead, fork Phoenix

Ever since we announced the end of Phoenix support, people have been bitching and moaning about it. As I said previously, this should be a surprise to nobody. We've been saying this is what we'd do for a solid year. We told everyone right up front that our development efforts on Phoenix have ended and that we would make no more changes.

Well, it's now come to pass. If you ask a Phoenix question in the support group that isn't related to migrating to Firestorm, you'll politely be told that we cannot answer your questions any more and directed to the self-help group. The support team was very happy when midnight SLT came around last night so they didn't have to deal with Phoenix any more.

There have been a few comments recently from folks claiming to fork - or even "take over" - the development of the Phoenix viewer. While it's not available for a takeover, a fork is entirely possible. Forking is inherent in open source development; indeed, nearly all experts in the field of open source development claim that the freedom to fork is at the very foundation of what makes open source successful. I have no particular problem with this view.

However, I think forking Phoenix to keep it running in SL is a very bad idea, for the same reasons we stopped developing on it. There will be a lot of work that needs doing in a very short time just to get the ability to deal with server-side baking into it. You might be able to piggyback off of Henri Beauchamp's work - as we did to get mesh into Phoenix - but that will only be the beginning of your problems.

You'll have a fair amount of work on your hands just to bring the mesh renderer up to speed. The one in Phoenix 1691 is based off of the LL 2.8 viewer. Every other one is based off of at least 3.3, if not 3.4 (I think CoolVL's current version is 3.4, for one example). You'll likely need to roll that work in to be able to use the other code that's floating around.

There are other things people have been screaming for and we haven't done. Multiwearables and RLV 2.7 are the two biggest, and neither one is going to be trivial. There are many others.

This is going to be an immense amount of work. Anyone who's not already intimately familiar with the code will have a steep learning curve, as well; Phoenix was hacked on by a cast of thousands, with decidedly varying levels of competence at programming and at C++ (and those are two independent variables). I'm not kidding when I say it's an unmaintainable tissue of hacks held together by spit, chewing gum, duct tape, and baling wire.

One thing I don't understand is the fetish some of our haters have for accusing us of lying. We don't lie. We tell the truth as we see it. That's exactly what I've done in every posting I've made publicly, both here, on Google+, on SLUniverse, and on the LL forums. I've been wrong sometimes. I'm not perfect. Even so, it's still the truth as best I can say it. Just because you don't like the answer doesn't make it incorrect, far less a lie.

And we're doing exactly what we said we'd be doing. Don't like it? Fine. Go right ahead and fork Phoenix. I double-dog dare you. Go ahead and prove me wrong.

But somehow, I don't think that someone who just today picks up the code and gathers programmers who know what they're doing will be able to have it working before LL breaks Phoenix. Anyone who claims that without some serious achievements under their belt to back up the bluster is just blowing smoke.