tag:blogger.com,1999:blog-36244899054392841372024-03-04T23:34:52.963-06:00The Tigress's Second DenTonya Souther's comments on Second Life, from the perspective of a user, builder, vendor, and third-party viewer developer.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.comBlogger69125tag:blogger.com,1999:blog-3624489905439284137.post-46036369642811567212021-07-31T19:00:00.002-05:002021-07-31T19:00:58.681-05:00Leaving Firestorm<p>If you're running the Mac version of Firestorm downloaded from the official website, it was built on my desktop computer, most recently a Mac Mini I purchased last year mainly for that purpose.</p><p>The current version, 6.4.21.64531, is the last for which that will be the case. Effective immediately, I have resigned from the Firestorm team as developer.</p><p>This is very bittersweet for me. I was one of the very last of the original project team to still be a part of the project. In a very real sense, it would not exist without me: I am the one who convinced Jessica Lyon to fork the Emerald project in the first place. (Perhaps she'll forgive me for that one day.) I have put 11 years of my life and a substantial amount of money into it.</p><p>The simple truth is that being a developer for Firestorm has gotten to be un-fun. The group dynamics have become toxic for me, and I've been keeping my involvement down to the amount I could take. I believe things are not going to get better.</p><p>In addition, I have started a new job recently - a job I got in no small part because of my involvement with Firestorm. That is taking more and more of my time.</p><p>Even so, this is a painful decision for me to make, and one I do not make lightly. It is my hope that the team can continue to serve the users of Second Life with the high quality, well-tested code it has become known for.</p><p>I am not leaving Second Life; far from it. It is perhaps the biggest part of my life outside of family and work. I have too many close relationships, too many good friends, and too many fun things to do to leave it. But I will no longer be active in viewer development.</p><p>I hope that I have managed to give at least something back to the Second Life community. I wish the team well.</p>Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com0tag:blogger.com,1999:blog-3624489905439284137.post-76170408922790553732020-08-19T06:27:00.002-05:002020-08-19T06:28:30.102-05:00Backing away from leftism<p>I think very highly of Wendy Starfall, formerly of OpenCollar and later of Peanut No. 9 and Heartcore. She has put in a lot of hard work to make collars and other RLV devices that work well and are easy to use, without being as heavily resource-intensive as earlier OpenCollar versions. The folks behind OpenCollar took the group away from her and have been waging an unjust, constant campaign of hate and slander to try to drive her out of Second Life for it. I use and recommend her stuff wholeheartedly.</p><p>I think it's unfortunate that Wendy feels the need to have the collar and the group espouse her political views. This would be unfortunate no matter what those views are, but she is an avowed leftist, and pushes political causes at the far left end of the spectrum. I disagree with nearly all of those stances, as a conservative who believes in freedom and individual rights.</p><p>Last night, Wendy posted this to the channel on the Discord server for her products used for updates:</p><h2 class="header-23xsNx" style="background-color: rgba(250, 166, 26, 0.08); border: 0px; display: inline; font-family: Whitney, "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 16px; font-weight: inherit; margin: 0px; padding: 0px; text-indent: -64px; vertical-align: baseline;"><span class="latin24CompactTimeStamp-2V7XIQ timestamp-3ZCmNB" style="border: 0px; color: var(--text-muted); cursor: default; display: inline-block; font-family: inherit; font-size: 0.6875rem; font-style: inherit; height: 1.25rem; line-height: 1.375rem; margin: 0px 0.25rem 0px 0px; outline: 0px; padding: 0px; pointer-events: auto; text-align: right; text-indent: 0px; vertical-align: baseline; width: 3.1rem;"><span aria-label="1:05 PM" style="border: 0px; font-family: inherit; font-style: inherit; font-weight: inherit; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;"></span></span></h2><blockquote><h2 class="header-23xsNx" style="background-color: rgba(250, 166, 26, 0.08); border: 0px; display: inline; font-family: Whitney, "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 16px; font-weight: inherit; margin: 0px; padding: 0px; text-indent: -64px; vertical-align: baseline;"><span class="latin24CompactTimeStamp-2V7XIQ timestamp-3ZCmNB" style="border: 0px; color: var(--text-muted); cursor: default; display: inline-block; font-family: inherit; font-size: 0.6875rem; font-style: inherit; height: 1.25rem; line-height: 1.375rem; margin: 0px 0.25rem 0px 0px; outline: 0px; padding: 0px; pointer-events: auto; text-align: right; text-indent: 0px; vertical-align: baseline; width: 3.1rem;"><span aria-label="1:05 PM" style="border: 0px; font-family: inherit; font-style: inherit; font-weight: inherit; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;">1:05 PM<span aria-hidden="true" class="separator-2nZzUB" style="display: inline-block; opacity: 0; position: absolute; width: 0px;">]</span></span></span> <span aria-controls="popout_55002" aria-expanded="false" class="username-1A8OIy clickable-1bVtEA focusable-1YV_-H" role="button" style="border: 0px; color: #f382aa; display: inline; font-family: inherit; font-size: 1rem; font-style: inherit; line-height: 1.375rem; margin: 0px 0.25rem 0px 0px; outline: 0px; padding: 0px; position: relative; vertical-align: baseline;" tabindex="0">Wendy Starfall</span><span class="separator-2nZzUB" style="display: inline-block; opacity: 0; position: absolute; width: 0px;">:</span> </h2><div class="markup-2BOw-j messageContent-2qWWxC" style="background-color: rgba(250, 166, 26, 0.08); border: 0px; color: var(--text-normal); display: inline; font-family: Whitney, "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 16px; line-height: 1.375rem; margin: 0px; outline: 0px; overflow-wrap: break-word; overflow: hidden; padding: 0px; user-select: text; vertical-align: baseline; white-space: break-spaces;"><span class="mention wrapper-3WhCwL mention" role="button" style="background-attachment: initial; background-clip: initial; background-color: transparent !important; background-image: initial; background-origin: initial; background-position: initial; background-repeat: initial; background-size: initial; border-radius: 0px; border: 0px; color: #7289da; font-family: inherit; font-style: inherit; margin: 0px; outline: 0px; padding: 0px; position: relative; unicode-bidi: plaintext; vertical-align: baseline;" tabindex="-1">@everyone</span>
<span style="border: 0px; font-family: inherit; font-style: inherit; font-weight: 700; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;">A kind, public reminder that I love all of you very much</span>
<span style="border: 0px; font-family: inherit; font-style: inherit; font-weight: 700; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline;">Tue, Aug 18 2020 11:04:46 AM PDT</span>
Climate change is no political propaganda.
Polar bears, caribous and hedgehogs are not antifa terrorists.
The wearing of protective face masks during a pandemic is not fascist oppression.
Asking for racial equality, gender equality and no discrimination of any kind against people based on their sexual orientation is something we stand up for as HUMAN BEINGS and not as "political parties".
Please stop politicizing everything. Believe in what your heart tells you. We flinch before we punch for a reason.</div></blockquote><div class="markup-2BOw-j messageContent-2qWWxC" style="background-color: rgba(250, 166, 26, 0.08); border: 0px; color: var(--text-normal); display: inline; font-family: Whitney, "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 16px; line-height: 1.375rem; margin: 0px; outline: 0px; overflow-wrap: break-word; overflow: hidden; padding: 0px; user-select: text; vertical-align: baseline; white-space: break-spaces;"></div><p style="text-align: left;">I object to every one of these statements, some more so than others: Climate change is not political propaganda, but it has been weaponized by those on the left to try to force through the kind of socialist economic destruction they have been pushing for a century; polar bears et al are not Antifa terrorists, but Extinction Rebellion and similar groups are; the wearing of protective face masks during a pandemic is not fascist oppression, but forcing people to do so on pain of fine and imprisonment is; racial equality and the rest is something we should all support, but not the Marxist, segregationist, black supremacist demands of the Black Lives Matter movement or the rioting that goes along with it. The politicization of all of these issues started on the left, and while conservatives push back, if the left would stop politicizing everything, we would see a sharp drop in the level of rancor in our society.</p><p style="text-align: left;">Let me clear: socialism is the most destructive, evil ideology ever put on paper. It has killed over a hundred million people, and made billions more people's lives hell on earth. Not only that, but while it's possible to vote socialism in, you have to shoot your way out of it. The United States will only become a socialist country literally over my dead body.</p><p style="text-align: left;">I found it extremely jarring to see her push those hard-left viewpoints under the headline that she loves us all very much. Those two are polar opposites of each other. I know Wendy means well, but I just can't sit idly by and let that kind of thing go unchallenged.</p><p style="text-align: left;">I asked where I should post a rebuttal. Wendy laid into me and basically told me that that server is her space and if I wanted to rebut her posts, to do it on my own space. Others there dogpiled on top of me. I finally decided I, and others who believe as I do, wasn't welcome there any more and left.</p><p style="text-align: left;">Wendy has now apologized to me. I accept that apology. It doesn't mean that I feel any more welcome there, however, given the reactions of others. I have rejoined the server, but have muted every channel in it so that I no longer receive any Discord notifications. I will use it for technical support exclusively and leave the leftists there to their echo chamber.</p><p style="text-align: left;">Conservatives on Second Life, as with much of online society, have to censor themselves severely. We cannot state our opinions with the same freedom as leftists, lest we be hounded out of our own spaces and off of the net entirely. I, for one, am sick of it.</p><p style="text-align: left;">I believe our society is rapidly approaching the point of a real, shooting civil war. We have gotten to this point because we can no longer discuss our differences calmly and rationally. In the past, Wendy and I have discussed those differences without shouting at each other. I understand the stresses she has been under lately, and am sorry I added to those stresses. I think it's best for now that I disengage and let things lie where they are.</p><p style="text-align: left;">I consider Wendy a friend. She's a genuinely caring person who has put up with far more crap than anyone ever should. I've tried to help what little I am able. But now...I'm sorry, but I just can't get close enough, any more. Maybe in the future, but for now, it's best we go our separate ways.</p>Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com1tag:blogger.com,1999:blog-3624489905439284137.post-72954342279668272952018-06-18T08:29:00.000-05:002018-06-22T06:32:39.712-05:00Firestorm and OS X MojaveAt the Apple Worldwide Developer's Conference held a few weeks ago, Apple announced OS X 10.14 Mojave. In amongst all of the other things Apple announced, one announcement has made waves in the gaming world: they announced that, as of Mojave, OpenGL was deprecated and would no longer be maintained.<br />
<br />
This is important because Firestorm, like every other graphical Second Life viewer, is based on OpenGL<br />
<br />
I got an email from a concerned user this morning asking about the problem and urging us to convert Firestorm to Metal, Apple's new and improved 3D graphics API. Here's my reply:<br />
<br />
***<br />
<br />
What follows is my own personal opinion. I’m not speaking for the Firestorm team, and certainly not for Linden Lab.<br />
<br />
I think Apple seriously shot themselves in the ass with their recent announcement. In essence, they told the gaming world to drop dead.<br />
<br />
First, what they did and didn’t announce. What they did announce was that Mojave would deprecate OpenGL. What they did not announce was a drop-dead release beyond which OpenGL would not work. Indeed, OpenGL works in Mojave, and with a couple of fixes not related to the graphics subsystem, the Linden viewer (and, presumably, Firestorm; we haven’t tested it ourselves) runs on Mojave just fine. Those fixes will be in the next release of Firestorm, which we are moving toward.<br />
<br />
To understand the magnitude of the problem, let me lay a couple of numbers on you. Firestorm currently consists of 25,649 files of source code, containing well over 1.2 million lines. I don’t know just how much of that is OpenGL code. What I do know is that there is no clean boundary in the viewer’s source code between the parts that use OpenGL and the parts that don’t; OpenGL is scattered throughout the entire codebase. This is true of every viewer based on the Linden Lab code, which is all of them that do graphics (with the notable exception of Lumiya, which was a ground-up implementation for Android, and a remarkable technical achievement in its own right). Some of that code is over 20 years old at this point.<br />
<br />
Simply to factor all of that out so there’s a clean separation between the graphics code and the rest of the viewer is a monumental task. And that’s just a preliminary. Once that’s done, then a separate renderer would need to be written just for the Mac. That’s not a trivial undertaking, and to the best of my knowledge, there are exactly five people on the planet who understand the Second Life render pipeline well enough to do it: two of them work for Linden Lab, and the other three are certifiably insane. None of them are on the Firestorm team. In any event, the effort required to do this is measured in man-years.<br />
<br />
It’s telling that Apple committed large amounts of time and money and people resources to Unity and Unreal to get their game engines ported to Metal. I’d be astounded if they did the same for Second Life. The market is simply too small.<br />
<br />
My understanding of the Linden Lab position on this is that they’re evaluating what they are going to do going forward, and that no decisions have been made. I would hope they are at least talking with Apple to see how much time they have. They probably have contacts that let them do that. I do not, and in any case we’re dependent on what the Lab does.<br />
<br />
While I am a faithful Mac user and have been for the last 16 years, I have not actually used a Mac as my primary Second Life system in a few years. Apple’s OpenGL implementation, not to put too fine a point on it, sucks. I usually get 30-40 FPS on one scene I spend a lot of time in, on my dual-hex MacPro 3.3 GHz/64 GB, with a Radeon R9-280X. I have actually wound up running Linux Mint natively on a second Mac Pro, this one a dual-quad 2.9 GHz/48 GB with a GTX 960. On that same scene, with the same window size, I easily turn 140 FPS or so.<br />
<br />
Personally, I don’t see how Second Life on the Mac, at least natively on OS X, will survive the loss of OpenGL. The market’s too small and the effort’s too large to make it economical. I personally expect to find myself running Firestorm exclusively on Linux, or else under Windows in a virtual machine on OS X (which I haven’t tested at all in the past several years) at some point in the future.<br />
<br />
Again, I must remind you that Apple has deprecated OpenGL on OS X. All that means is that they will stop supporting it at some point in the future. That point is not today, and they have not said when that point is. Until they do, Second Life, and Firestorm, will run on OS X as well as it does now.<br />
<br />
***<br />
<br />
<b>Update, 22 June:</b> At his Meet the Lindens interview with Saffia Widdershins at the SL15B celebration yesterday, Oz said that "we will find a way to keep Second Life running on the Mac." This is good news. I hope it comes to pass.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com1tag:blogger.com,1999:blog-3624489905439284137.post-83303552799269081552018-01-24T17:25:00.001-06:002018-01-24T17:25:40.540-06:00Don't just turn up RenderVolumeLODFactor!Firestorm, like all Second Life viewers, has a large number of configuration settings. One of the most widely misunderstood is named RenderVolumeLODFactor. It’s not at all uncommon for Second Life content creators to tell their users that this should be set as high as possible so their creations can be seen properly.<br />
<br />
But what is this magic value, and what does it really do?<br />
<br />
LOD stands for “level of detail”, which means in how fine detail the viewer will render an object. A higher LOD means that the viewer will show the object with greater detail than a lower one. A small object rendered at a lower LOD will be shown as a simpler shape; a higher LOD will be rendered more accurately.<br />
<br />
Of course, it takes more work to render a complex object then a simpler one, and the higher the LOD required to render it correctly, the harder your computer and graphics card have to work. If there are many objects with high LOD in a scene, your computer will slow down.<br />
<br />
The viewer manages this by determining the required LOD based, in part, on how far away you are from the object. A small, complex object 20 meters away can be rendered with a lower LOD, and you’ll never notice the difference, because it doesn’t take up enough space on your screen to show all that detail anyway. If you move yourself (or the camera) closer, the LOD will go up because the object appears larger, and the details will become visible.<br />
<br />
RenderVolumeLODFactor controls how the viewer adjusts the LOD based on your distance from the object. It’s used in calculating the actual LOD. A higher value makes the viewer compute a higher LOD, and render objects with more detail, than a lower value would for any given object and distance.<br />
<br />
Content creators love to set this value high, so that your viewer shows their creations with all of the details they build in. Some creators recommend numbers in the thousands. This is a very, very bad idea.<br />
<br />
Because a higher value makes your computer work harder, raising it needlessly slows your computer down without really doing anything to make things look better. A detail that takes up a third of a pixel on your screen won’t be visible no matter ho high you set the LOD factor. Your computer will still do extra work trying to show it, though.<br />
<br />
Not only that, but the calculation that uses the RenderVolumeLODFactor value gives a totally meaningless result for any factor above 10. It won’t crash the viewer, but it doesn’t help matters, and you’re still running the computer much too hard to no purpose.<br />
<br />
For the past couple of years, Firestorm has enforced a limit of 8 on that value. We recommend no higher than 4, and will reset the value to 4 if it’s set higher than that. The next release will also give you a warning if you attempt to set it higher than 4.<br />
<br />
If you’re doing high-quality photography, then you may wish to set your RenderVolumeLODFactor higher than 4. before you do so as a matter of habit, though, try it at 4 and see if it makes any visible difference. Chances are it won’t.<br />
<br />
We hope that creators who tell their customers to use extremely high RenderVolumeLODFactor values will stop doing so. All they’re doing is showing they don’t understand how things work.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com2tag:blogger.com,1999:blog-3624489905439284137.post-33940453808885763012016-10-05T10:40:00.000-05:002016-10-05T10:40:28.812-05:00Announcing the Hospes LategumMy wife Chibi Souther and I have been working on a new project. We've created a world, and a roleplay environment, for latex lovers in Second Life: Hospes Lategum.<br />
<br />
***<br />
<br />
The Hospes Lategum is a society of people who, since about 500 BC, have permanently joined physically and mentally with living latex symbionts known as Lategum. The joining gives the Host greatly extended life and immunity from a wide range of environmental and biological hazards. No Host has ever died of old age or illness, though many have died of violent causes. Their need for food and water intake is greatly reduced, as well.<br />
<br />
In their unjoined state, Lategum are, for all intents and purposes, liquid latex. They form a hive mind and communicate among themselves. In joining with a Host, they leave the hive mind, and in return gain access to the Host's mind and senses. This allows them to experience life much more directly.<br />
<br />
The Lategum retain their telepathic communication abilities. As the bond with the Host grows, the Host gains the ability to use that to communicate with other sufficiently advanced Hosts, and in rare instances with the hive-mind itself. This is the basis for the ranks in the Hospes Lategum. The more fully joined the Host is with their Lategis, the higher their rank. The very highest ranks, Beta and Alpha, serve as senior leadership, but that is as much due to their ability to understand what the Lategum want and give those intentions effect as it is any other factor. Further, all Hosts are equals, regardless of rank, and the Alpha is subject to the same rules and penalties as the Zeta just putting on his leotard for the first time.<br />
<br />
When one becomes a Host - the term refers to all members, even Zetas who have not been joined to a Lategis yet - one gives up their name and clothing and other trappings of one's former life. A Zeta is given a transparent latex catsuit and a leotard, which they will not remove until they enter the tank to be joined to their Lategis. The leotard bears their Host ID. This ID is assigned by the Lategum and molded into the leotard when the dispenser gives it to the new Host. From that point forward, they are known by their rank and ID, as in "Zeta 7703". All hosts are referred to as Brother or Sister, as appropriate, as well, so one might address "Sister Zeta 7703" or "Brother Gamma 3501" or "Sister Alpha 8369". They also wear a collar that not only serves as a reminder of their service, but also bears the mark of the Hospes Lategum. The collar also marks the boundary above which the Lategis will not encase the Host.<br />
<br />
When the Zeta is ready to be joined to their Lategis, they first remove their uniform, and stand naked for the last time in their lives. They then swear the Hospes Lategum Oath, by which they devote their lives to serving the peoples of the Earth, before entering the joining tank. The Lategum flow into the tank, and one of them joins with the new Host. The tank empties, and the newly joined Host, now at the rank of Epsilon, steps out to begin their new life.<br />
<br />
Part of progressing through the ranks of the Hospes Lategum is spending time in silence, surrounded by liquid latex, meditating and learning to communicate with the Lategis. The required time increases as the bonds one seeks to form increase. As the Host ascends in rank, the color of their uniform leotard changes, as does the rank letter on it next to their ID.<br />
<br />
With the sole exception of the current Alpha, all who are not fully human within the Hospes Lategum are products of the society's genetic engineering efforts. They do have human characteristics to varying degrees, ranging from nekos with feline ears and tail to people who differ from their feral antecedents only in being bipedal and sapient. Not all Children of the Lategum, as these are known, are joined to a Lategis and part of the society; many have, at their own request, been sent out into the wider world.<br />
<br />
***<br />
<br />
The Hospes Lategum group in Second Life is open to both sexes and all species, subject only to whether the avatar's body is such that a uniform can be made for it. The story is flexible enough to allow for a wide range of personal histories.<br />
<br />
As a roleplay community, members are expected to be able to roleplay. In order to advance in rank, those who don't have a known history in other RP groups will be expected to demonstrate those abilities. This requirement isn't intended to discriminate, but rather to ensure that people can actually roleplay.<br />
<br />
The only cost to become and remain a member of the Hospes Lategum is the MD Pod Prisoner suit, which is used for the meditation system. If you already have one, you'll need to have available (either saved or unpacked from the original box) a level 0 helmet. If not, the cost is L$300, and it may be purchased in the uniform fitting room. The Hospes Lategum uniforms and accessories are free of cost.<br />
<br />
We do not require that you remain in uniform when not at the Hospes Lategum island. When there, however, you must be in uniform, including an enabled renamer and group tag. At Epsilon rank and above, you have been joined permanently with your Lategis, and so may not appear there without it.<br />
<br />
***<br />
<br />
Interested? Check out the documentation at the <a href="http://hospeslategum.wikidot.com/" target="_blank">Hospes Lategum wiki</a>. The Hospes Lategum headquarters are in the Catalina region of Second Life. Any Gamma or above member can invite you to the group.<br />
<br />
I hope to see you there.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com0tag:blogger.com,1999:blog-3624489905439284137.post-60180153105842250782015-07-17T14:03:00.001-05:002015-07-18T07:33:04.343-05:00LL to merchants: No TPV for you!Yesterday, Linden Lab <a href="https://community.secondlife.com/t5/Commerce/Viewer-Managed-Marketplace-Released-Migration-Begins-July-23/ba-p/2949604" target="_blank">announced</a> that merchants would be migrated to the new Viewer Managed marketplace beginning next Thursday, July 23, and that once migrated, merchants would need to use the <a href="http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.8.2.303583" target="_blank">Second Life VMM Viewer</a> to manage their stores.<br />
<br />
Never mind that the viewer is, as I write this, only a release candidate, not even in full release yet.<br />
<br />
I've written before about the process we follow to keep our code up to speed with LL's. The main thing of interest here is that we need to do things in the same order as LL releases them, so as to keep merges from becoming an unmanageable mess. LL only released the prior merge, the series of attachment fixes known as Project Bigbear, this past Tuesday.<br />
<br />
On top of that, the Lab insists that we not release code of theirs until it's at least at RC status. We can merge earlier if we wish - at our own risk. We did, actually; Ansariel Hiller has a repository she's been merging the VMM stuff into. Repeatedly. LL has, more than once in the process of VMM, reformatted the XML code that describes the user interface. Every one of those merges has been a major effort to clean up. When she complained, she was told "that's what you get for merging early". The clear message: don't merge things until they're RC.<br />
<br />
So with all of this, we're just now getting to the point we can merge VMM into the mainline viewer. That's when we begin to make sure it fits in with the rest of the code, and find and fix bugs (often, LL's), and basically make sure it's up to our standards. Our release cycle takes a few weeks because we actually test things before turning them loose.<br />
<br />
The upshot: We will not have a Firestorm release with VMM in time for our users who are being forced to migrate to VMM.<br />
<br />
This is not a problem to LL, of course. As far as they're concerned, users should be on the official viewer, anyway.<br />
<br />
To our users, however, it is a problem. LL has a terrible track record of listening to users, and it shows in their viewer. We're already starting to hear complaints from folks who want no part of the LL viewer. <a href="http://www.sluniverse.com/php/vb/blog-feed/108018-viewer-managed-marketplace-released-migration.html" target="_blank">This thread</a> on SLUniverse is typical.<br />
<br />
Jessica Lyon <a href="http://www.sluniverse.com/php/vb/blog-feed/108018-viewer-managed-marketplace-released-migration.html#post2151505" target="_blank">posted late in that thread</a> (as I write this) that we may release a preview viewer for merchants to use to do VMM while we rush through the QA cycle for the full release. This is a much less than ideal solution; previews are explicitly unsupported, may change, and aren't guaranteed to work properly. We don't <i>like</i> doing them. In this case, LL's ...planning may force our hand.<br />
<br />
I don't know why LL feels compelled to force people into VMM while the viewer that's required to support it isn't even an official release yet. Whatever the reason, this seems like particularly poor planning, as well as a distinct "see figure 1" to TPV developers and users.<br />
<br />
Sadly, it's in line with their normal ways of doing things, and what we've come to be used to.<br />
<br />
Update, 18 July: According to <a href="https://community.secondlife.com/t5/Merchants/Viewer-Managed-Marketplace-Released-Migration-Begins-July-23/m-p/2949943#M53334" target="_blank">this post on LL's forums</a>, the VMM version of the official viewer won't be a full release by the 23rd either! Not only is this a "<a href="http://www.dourish.com/goodies/see-figure-1.html" target="_blank">see figure 1</a>" to TPV-using merchants, but merchants in general. The net effect, since Oz will not commit to releasing the VMM viewer next, is to force us to either push VMM as it stands now and deal with potential merge headaches should they decide to release something else first, or else hold off on our release and force users to use the LL viewer to manage their Marketplace items.<br />
<br />
Real TPV- and merchant-friendly, LL...Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com1tag:blogger.com,1999:blog-3624489905439284137.post-26254851134862601892015-07-07T13:37:00.000-05:002015-07-07T13:37:23.725-05:00Another one bites the dustI did something this morning I haven't done in years on my main account: "set home to here".<br />
<br />
For the last several years, my home is on a sim run by my good SL and RL friend Axi Kurmin. Cursed is a Goth village, home to the last true Goth club in SL, Gothika, and carefully curated to keep an overall theme. Axi did all of the landscaping and, after an incident with a former business partner, controlled all of the building as well. There's a small commercial section, and Tonya's Restraint Works' main store and demonstration playroom are there.<br />
<br />
All of that is, at minimum, moving elsewhere. Axi finally gave in to the stress and the economic pressures and is dropping the sim. Gothika and the cemetery that goes with it are moving. So is Axi's workshop. The other rentals are ending as of July 23, the due date of the next tier payment.<br />
<br />
Why? Put simply, the US$295 a month sim rental is too much for Axi to support. Having her own sim let her run events her way, on her schedule and on her terms, but that's become far more stressful than fun. The rents she was able to bring in didn't come close to covering the cost. And she's got a lot better use for US$295 a month these days than running a sim that's become a source of stress.<br />
<br />
So now we have one fewer privately-run sim in SL.<br />
<br />
Last night, my wife Chibi and I moved our home to a new location. I have my own homestead that I used for other things, but mostly rented out. My home is now there, on a very tall hill another friend terraformed for me. (I can't terraform worth a crap.) We got a copy of the house, and moved everything to the new one in just the same spots as before so it immediately feels like home. There's still some work that needs doing, but not much.<br />
<br />
The store and playroom are, at least for now, going to close. It's not like I got a lot of business out of them anyway. I've got a project percolating in my mind that will eventually require a new physical store, but for now my stuff will only be available on the Marketplace.<br />
<br />
Perhaps I should rename my sim, though...somehow, Catalina doesn't seem appropriate any more.<br />
<br />
I have to wonder how many sims are going away because of the price. US$295 a month is pretty stiff for a hobbyist, after all. With the release of experience tools, LL is giving creators the wherewithal to create the kind of experiences that Ebbe Linden says he's after. That's great, but it's getting harder and harder to be able to afford the kind of space needed to create a great experience. (And individuals are not getting grid-wide experience keys.) LL's just shooting themselves in the foot keeping tier as high as it is.<br />
<br />
I know tier's LL's cash cow...but is that business model sustainable in the face of the outlays needed for Sansar? How many more sims can LL afford to lose? Axi's one sim isn't much, true, but it is emblematic of a bigger problem.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com0tag:blogger.com,1999:blog-3624489905439284137.post-68931601751730033422015-03-19T21:03:00.000-05:002015-03-19T21:24:44.434-05:00LL says "we know what's best for you!"Inara Pey posted <a href="https://modemworld.wordpress.com/2015/03/19/vwbpe-2015-ebbe-altberg-lls-next-generation-platform/" target="_blank">a very good rundown</a> of Ebbe Altberg's comments on SL:TNG at VWBPE 2015. There's nothing really new there, but Altberg did come flat out and say what LL had danced around before:<br />
<blockquote class="tr_bq">
We have stated that we’re not planning for our client, at least for the beginning – and possibly never, but never say never -, but we’re not starting with it being open-source.</blockquote>
I can certainly understand why they're doing it, but it doesn't speak well for their openness to NIH ("not invented here") ideas on the new platform. Basically, they're saying "we know what's best for you, so shut up and eat your Brussels sprouts".<br />
<br />
We've been here before. Remember Viewer 2? Yeah, me too. There's a reason that Firestorm has the overwhelming majority of users on Second Life, and Viewer 3 (the descendant of Viewer 2) is in third place: LL's viewer does not fail to suck. Users told LL all about that, loud and long - and LL didn't back off and didn't listen.<br />
<br />
I'm sure LL has a vision for SL:TNG. I'm sure it's great stuff, working equally well on platforms from the iPhone to the Nexus 9 to the PC/Mac to Oculus Rift to...you name it. I'm equally sure it, like every software system, is designed with a specific usage style in mind. Programmers develop software with a mental model of how it is supposed to work and how users are expected to use it. No matter how hard they try not to, they can't help it.<br />
<br />
Those mental models are very difficult for a programmer - or a system architect - to overcome as he works, and yet they're the first thing to go by the wayside when actual users start to use the system. Just like no battle plan survives contact with the enemy, no software system survives contact with users intact. This is the way of the software world. A wise system architect takes that into account, and designs systems with maximum flexibility for different usage styles and patterns and needs.<br />
<br />
LL's track record in this regard, not to put too fine a point on it, sucks rancid pond water. Why? Because they have a terrible record when it comes to listening to what their users have to tell them.<br />
<br />
In an ideal world, there would be little need for a Firestorm, let alone room for it to demonstrably become users' favorite viewer. That's because, in an ideal world, LL would implement the capabilities of the viewer that users want and need themselves.<br />
<br />
As I said, I can understand LL's hostility to the idea of SL:TNG being open source. When it comes to SL, LL is in a very unenviable position for a business: they do not control their own platform. They can't make significant changes to it without getting viewer developers - a bunch of unpaid volunteers who have other things to be doing with their time - to line up behind changes. No business wants to be in that position, and most businesses can't afford to be there for very long. In fairness, the only way LL was going to regain control of their platform was to do exactly what they're doing.<br />
<br />
This is the nightmare scenario that LL, at least in their own minds, cannot afford to repeat with SL:TNG. If I trusted them to actually listen to their users when we tell LL what we want and need, it wouldn't bother me very much. The problem is that I don't and neither does anyone else. Can you see LL doing the equivalent of RLV in SL:TNG? Me either.<br />
<br />
And that's the problem. They don't understand that there are people whose use cases for the platform do not match what their intentions are for it. Yeah, they'll probably accommodate furry avatars. (And the folks who can get in early with good stuff will do well. But Maya, LL? A 3D modeling program that's hideously expensive and has a reputation of being even harder to use than Blender?! Forget about user-created content...) But the adult BDSM community, for example, can go whistle.<br />
<br />
Make no mistake, there's lots to like about what Ebbe laid out for SL:TNG. A new avatar skeleton and base that fails to suck is a welcome advance. C# as a scripting language is a sensible choice, if not the choice I'd make. (I'm a Python bigot.) (And to the guy who claimed on Inara's blog that LSL is a functional, fourth generation language: What are you smoking and where can I get some?) An emphasis on new user discoverability is a good thing, to draw people in and keep them. Scalability is immensely important. And the change in emphasis in revenue generation from tier to sales taxes is imperative.<br />
<br />
Still, there's a big gaping hole in LL's plans, labeled "user direction for the platform". LL's not going to hand over control to outsiders. But there has to be a happy medium there somewhere. I'm disappointed they're not even trying to find it.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com1tag:blogger.com,1999:blog-3624489905439284137.post-74347507007656330592015-02-15T17:11:00.002-06:002015-02-15T17:11:34.679-06:00Thrown out of paradiseA good friend of mine is currently spending time as a bane. He may be the last bane in Marine Kelley's program, as it's been shut down, but he's still sealed into his banesuit. He's serving a 96-hour sentence that's grown by about 8 hours' worth of penalties, and he's about 44 hours in.<br />
<br />
Needless to say, he's been spending a lot of time sitting around, enjoying the scenery. He'd settled on the spectacular sims that make up the Calas Galadhon park as being wonderful places to hang out. He even wanted to contribute to the park, so he donated L$5000 to its upkeep. This is his second sentence, and he spent most of the first there, as well.<br />
<br />
This afternoon, though, he was informed that he wasn't really welcome at Calas Galadhon. One of the owners there asked him to stay away from places where others might want to enjoy the park, and that while the sims weren't designed for role-play, the owner would let it go as long he was somewhere out of the way.<br />
<br />
I know all this because the conversation was routed through me. My friend contacted me outside SL, since as a bane he's thoroughly locked down with RLV, and I spoke with the owner on his behalf.<br />
<br />
My friend isn't sure what he did to cause the problem, but he's decided to stay away from Calas Galadhon so as not to cause any more problems than he already has. He's looking for other places to hang out where he won't get run off.<br />
<br />
Speaking for myself...I've long thought Calas Galadhon was one of the jewels of SL. The builds are spectacular, and obviously a labor of love. The owners have poured their heart and soul, as well as a highly nontrivial amount of money, into those sims, and it's their right to run them as they choose.<br />
<br />
Still, I'm a bit disappointed that my friend feels unwelcome there...Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com1tag:blogger.com,1999:blog-3624489905439284137.post-75318218322960105942014-08-06T15:01:00.000-05:002014-08-06T15:01:20.345-05:00LL, it's time for 64 bitsThe latest viewer statistics are out. There are no real surprises in them; they continue trends we've seen for quite a while now. Firestorm is still by far and away the most widely used viewer on Second Life. There are still substantial numbers of users on older viewer releases, but the usage of non-SSA-capable viewers is low enough that they don't show up in the statistics at all. Pretty much all of the viewers now in use are at least capable of rendering materials, as well (though many users still leave Advanced Lighting Model turned off for performance reasons).<br />
<br />
Two facts caught my eye this time around:<br />
<br />
For the last two releases of Firestorm (4.6.1 and 4.6.5), there are more users of 64-bit versions than 32-bit versions.<br />
<br />
The crash rates for those 64-bit versions are just over half those of the 32-bit versions. Not only that, but the session disconnect rate (defined as the session ending without an explicit logout by the user and without crashing) for 64-bit 4.6.1 is the only one for any Firestorm version, and only one of two for any viewer version, that's below 10%. (The other is 64-bit Singularity 1.8.5, which crashed more often than Firestorm but disconnected less often for other reasons.)<br />
<br />
In fact, 64-bit Firestorm crashes less often than any other graphical viewer - and the difference is dramatic: for 4.6.5, it's 6.11% as opposed to 11.30% for the 32-bit version, itself one of the lowest crash rates measured.<br />
<br />
(At this point, I have to issue the obligatory grumble about how even a 6% crash rate is horrible to one with my background in mainframe computing, where that kind of problem rate would get someone fired. We've grown to accept crappy computing in general, and that's a bug.)<br />
<br />
This tells me one thing: It's time for LL to quit stalling and embrace 64 bits.<br />
<br />
64-bit viewers are more stable, and from the reports we get from users, they perform at least as well as, if not better than, the 32-bit equivalents. The end result is a better user experience. It's not universal, but it's quite widespread.<br />
<br />
The biggest hold-up in the move to 64 bits is the Havok library. LL distributes that to qualified TPV developers in object form only, and only in a 32-bit version. That means that the Havok version of Firestorm can only be built as a 32-bit program. This only matters to people who make mesh content, or to people who need to see the pathfinding navigation mesh on a sim; there probably aren't many of the latter, but there are lots and lots of the former, and they're people that the Lab actively courts.<br />
<br />
What's more, the kind of professional content creator that's taking over SL commerce almost always has the latest, most powerful tools ready to hand - and those tools are 64-bit. They make full use of the power. To stick them with a 32-bit viewer is a bit backward.<br />
<br />
The reason that 64-bit viewers are more stable almost certainly has to do with the viewer's memory usage. For at least as long as I've been working on the viewers, they've been plagued with memory leaks: the program allocates memory and never releases it, which reduces the total amount of memory available. When it can't allocate any more, bad things happen. The Lab has been chasing them for years, with at least two major pushes to stamp them out, and yet they're still prevalent. In their defense, the viewer is complex enough that finding and fixing them all will probably never happen. There's just too much code there.<br />
<br />
In a 32-bit viewer, the amount of memory one program can use is limited to, at best, 4 GB - and on Windows, it's more like 2.5 GB. A 64-bit viewer can theoretically access up to 256 TB of memory. (Current implementations of the x86_64 architecture have a 48-bit virtual address.) That's effectively infinite.<br />
<br />
To borrow a line, "Memory? Leak all you want. We'll make more."<br />
<br />
It's getting hard to buy a computer these days that doesn't handle 64-bit programs. Even the lowest-end hardware is 64-bit capable, and is more often than not equipped with a 64-bit version of Windows. Every Mac made in the last 5 years - more importantly, every Mac that's supported by LL and current versions of Firestorm - can run a 64-bit program. Most Linux systems can, as well.<br />
<br />
It's time for LL to join the 2010s. TPV developers have done nearly all of the work. I'm sure we'll happily help LL do the rest. Oz is publicly committed to making sure SL gets as much technical goodness as it can.<br />
<br />
What are you waiting for, LL?Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com2tag:blogger.com,1999:blog-3624489905439284137.post-65744651727429480262014-07-02T19:50:00.003-05:002014-07-02T23:14:42.665-05:00Finally, 64-bit Firestorm for OS XOne of the requests we get a lot from folks is for a 64-bit version of Firestorm for Mac users. There have been a few Firestorm releases in 64-bit versions for Windows, and a couple for Linux, but OS X has been a tougher nut to crack. The big problem has been the stack of libraries that needed to be rebuilt for the Mac.<br />
<br />
Cinder Roxley took up that challenge about a month ago. There were some universal (64- and 32-bit combined) libraries already, but she went through and redid the rest, and published the results. She also made the necessary changes to Firestorm itself. That was a pile of work, and I'm thankful she did it.<br />
<br />
This past week or so, I went through and reproduced her results. The goal here was to make sure everything would build and run on OS X 10.7, the Lion release. In several cases, I had to redo how the libraries were built. There were a couple where the programmer who wrote the library was just too damned smart and checked at the time the library was used in an application that the library was built for the same architecture as the source code used in the application. (Yes, <span style="font-family: Courier New, Courier, monospace;">curl</span> and <span style="font-family: Courier New, Courier, monospace; white-space: nowrap;">c-ares</span>, I'm looking at you.) That broke rather badly for a universal library.<br />
<br />
The biggest headache was in the <span style="font-family: Courier New, Courier, monospace;">apr</span> (Apache Portable Runtime) library. I spent two days trying to figure out why it would simply hang at login time, with no error messages or any other indication of a problem. It turns out that, while the library is supposed to work when built as a universal binary, it's subtly broken. I wound up using the same trick I'd used on <span style="font-family: Courier New, Courier, monospace;">curl</span> to make that work.<br />
<br />
I had to rearrange a couple of things. <span style="font-family: Courier New, Courier, monospace;">curl</span> also required a copy of <span style="font-family: Courier New, Courier, monospace;">libidn</span>, so I sucked that down, made an <span style="font-family: Courier New, Courier, monospace;">autobuild</span> package out of it, and built it. There's also a change in how the <span style="font-family: Courier New, Courier, monospace;">colladaom</span> library is packaged: it used to include a binary blob of <span style="font-family: Courier New, Courier, monospace;">libminizip</span>, but LL has recently changed the package to build it as part of <span style="font-family: Courier New, Courier, monospace;">zlib</span>, instead. I tracked that change.<br />
<br />
Many libraries would not build as universal easily. For those, I built 32- and 64-bit versions separately, and used the <span style="font-family: Courier New, Courier, monospace;">lipo</span> tool to glue them together. If you want to see how that worked, check out <a href="http://bitbucket.org/tonyasouther" target="_blank">my Bitbucket repositories</a>; everything I did for the libraries is there.<br />
<br />
With all that done, I went through, looked over the changes to Firestorm itself, and then pushed them to the master repository. The result builds properly in either 32- or 64-bit versions. (To build a 64-bit binary, you need to use <a href="https://bitbucket.org/NickyD/autobuild" target="_blank">Nicky Dasmijn's version</a> of the <span style="font-family: Courier New, Courier, monospace;">autobuild</span> tool and specify the <span style="font-family: Courier New, Courier, monospace; white-space: nowrap;">-m64</span> switch; nothing else changes.) If you're switching from building a 32-bit Firestorm to building a 64-bit version, you should probably specify <span style="font-family: Courier New, Courier, monospace; white-space: nowrap;">--clean</span> to make sure you start fresh with everything at 64 bits. You also need to do a <span style="font-family: Courier New, Courier, monospace; white-space: nowrap;">--clean</span> when building for OS X from repository revisions after the change (revision 42327 or higher) if you've previously built for revisions before the change (42298 and lower).<br />
<br />
It should be noted that with this change, Firestorm no longer supports OS X 10.6 (the Snow Leopard release). LL dropped support for that back in April, and we're following suit. There will be no SL-specific version of this package, like there is no SL-specific version of Firestorm for Linux and Windows. The reason is the same: the SL-specific version includes the Havok library we get from LL, and they have not provided a 64-bit version of that. When they do, we will think hard about dropping the 32-bit OS X version entirely, since any machine that can run Lion can run a 64-bit program.<br />
<br />
Unless something breaks badly, this will be part of the next release of Firestorm. We have no plans to release anything before then. There's still a whole lotta debugging goin' on.<br />
<br />
Still, i'm happy to have that chore out of the way. it will be interesting to see what difference it makes for users.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com3tag:blogger.com,1999:blog-3624489905439284137.post-17743445388699014672014-06-24T15:58:00.000-05:002014-06-24T15:58:14.875-05:00The new SL announcement is not the end of the worldI can't recall the last time I saw as big an earthquake roll through the SL community as the one that hit last Friday with Ebbe Linden's off-the-cuff comment about LL developing a next-generation SL that would not be constrained by compatibility with the existing one. Ever since the story broke, there's been a lot of panic and a lot of misinformation floating around.<br />
<br />
Folks, SL is not in any danger of disappearing any time in the near future.<br />
<br />
To begin with, the timeline is well out there. LL is just now ramping up hiring to develop SLTNG, as I'll call it (by analogy to <i>Star Trek: The Next Generation</i>, commonly referred to as STTNG). It will take those new folks a fair amount of time simply to learn where the bathrooms are, never mind become truly productive in building a new platform. The estimate I've seen is beta in late 2015, and release sometime in 2016. I think this is optimistic.<br />
<br />
Then there's the time it'll take to ramp up the new service and get people to join and make things and in general make it a viable, going concern. This will not be trivial; I wouldn't be surprised if it wasn't really viable until Christmas 2017.<br />
<br />
Until that happens, LL will need money. Guess where they're going to get it?<br />
<br />
If you guessed SL, you're right. They have no other real source of income. Their other products either withered to begin with or else were killed outright. Oh, there's a possibility they may raise some venture capital, though I'm skeptical. Given LL's trajectory, that would be a risky play for a VC, and they're not looking for risk. They're looking for the next sure thing.<br />
<br />
So this means that LL will continue to support and, where appropriate, enhance SL. SLTNG is a bet-the-company proposition. They're hiring a nontrivial bunch of people to take on a big challenge that will take years to pay off, and whether it will pay off at all is very much an open question. SL is profitable, and they need those profits to keep the doors open while they develop SLTNG.<br />
<br />
This isn't the first time that a company has pre-announced a new product while depending on the original. The standard business-school example of this is referred to as the Osborne Effect, after Osborne Computer Corporation, which went bankrupt in 1983 after pre-announcing new computers sent sales of the existing machine into the tank.<br />
<br />
I don't know if this is a case where Ebbe's comments were a slip of the tongue - though one doesn't get to be CEO of a corporation, especially one with as much social media experience as Ebbe, without understanding exactly how widely his words would be reported - or if this was a calculated announcement before a carefully selected audience. Either way, he's running the risk of triggering the Osborne Effect.<br />
<br />
Folks, this is a <i>bad thing for LL</i>. The only thing that could make it worse is the user community bailing prematurely. Guess what's happening? You're doing <i><b>exactly that!</b></i><br />
<i><b><br /></b></i>
LL's not about to kill off, or even cut back on, SL any time soon. They can't afford to. And there's another reason, too. His (SL) name is Oz Linden.<br />
<br />
Yeah, people love to bash Oz, but I'm very happy that he was chosen as the technical director for SL. Folks, he <i><b>believes</b></i> in Second Life. Disagree with his approach all you want to, but you have to admit that everything he's done has been with the best interests of SL at the forefront of his mind. Further, he's a long-time advocate of open source, well before he ever got on SL, and SL needs open source now more than ever: if the technical team for SL is being pared back, they have to leverage the efforts of other folks even more now than they used to. That means working <i>with</i> TPV developers closely.<br />
<br />
Oz is sticking his neck out one hell of a long way by taking this position. If SL goes in the tank, his job goes with it.<br />
<br />
All of this means that the sky is not falling. It's not even clouding up. SLTNG won't even be anything to take a sneak peek at for at least another year, and that's highly optimistic. It won't be a serious competitor to SL for two years at an absolute minimum, three more realistically, and four is not outside the realm of possibility. It's also possible that SLTNG will flame out and not work at all, or not achieve the desired results.<br />
<br />
Now, this does not mean that there's nothing to be done to help SL and its users in the meantime. SL's not the perfect service, as many (including I) have argued. But it's still the same great place to be it was Friday morning, before Ebbe teleported into Hippotropolis. It's still worthy of the same care, and the same effort, and the same support, that it was then.<br />
<br />
Jess asked, in <a href="http://www.firestormviewer.org/second-life-needs-you/" target="_blank">a post to the official Firestorm blog</a>, for ideas for one big change that would help SL not only stay around, but grow and thrive. Everyone's got their own thoughts on the subject; here's mine.<br />
<br />
Before we think about what needs fixing, we first need to define the problem. The biggest problem SL faces is a simple one: what's there to do inworld? Personally, I think the reason that people join SL, log in a few times, and then go away and do something else is that there's nothing interesting to do. The platform is interesting in and of itself for about 15 minutes. Then the user is going to want to do something fun.<br />
<br />
There used to be lots of fun places to go and do things. They've steadily dropped from sight, one by one. It's not that their makers lost interest; rather, it's that they couldn't afford to keep them running. Big, fun builds, testing the limits of the capability of the platform, are expensive to run - because the price of sims in SL is high. Even folks who have full sims at a grandfathered US$195 a month each are still laying out a significant chunk of change for the privilege. I am at a total loss as to how the folks behind Calas Galadhon afford their 10 sims (or is it 8 now?). Most of these things are a labor of love, and that kind of love gets hideously expensive. It's still worse for folks who can't get the grandfather deal.<br />
<br />
This also raises the barrier to entry for new folks with new experiences to build. Even a homestead at US$125 a month is expensive for what you get, and you have to either have a friend with a full sim to hang it off of or else rent from a land baron, as I do, and he has to make his money, driving the cost up further.<br />
<br />
The long and the short of it is that tier is a major issue, if not <b><i>the</i></b> major issue. Everything else comes back to it. Yes, it's LL's major income (at least I'm pretty sure it is, though exchange fees on L$ purchases and Marketplace commissions can't be trivial). Cutting tier would represent a major hit to LL's bottom line. The flip side of it is that a sim just isn't that expensive for LL any more. Hardware power has gone up as costs have gone down, and they can run more full sims on a physical box than they could five years ago when the current prices were set. The $1000 setup fee is ridiculous, as well: if it takes more than one person filling in one web form and clicking OK to provision a new sim, I'll be stunned. So LL's costs have to have gone down, but tier has remained the same as content providers and folks who give SL the richness that makes it the place to be wither up and blow away.<br />
<br />
LL needs to lower tier. Now. Especially now, as a statement that SL is here to stay.<br />
<br />
Meanwhile, there's one other aspect of this whole business that troubles me more than a little bit. Ebbe has very carefully not said that there's a place for open source in SLTNG. I've asked repeatedly, in channels I know he's reading, and he hasn't said word one to even acknowledge my existence, let alone answer the question.<br />
<br />
I think this says it all, really. There <b><i>is</i></b> no place for open source in SLTNG.<br />
<br />
I can understand why LL might reach this conclusion. From their point of view, it has to be frustrating as hell to roll out a new feature and then have to depend on a volunteer team of open source programmers to update their software to make the feature have a decent chance of being used by the SL user community. In a real sense, they've lost a big measure of control over their platform. That's a situation no business wants to be in.<br />
<br />
Still, this ignores the simple fact that, by and large, Lindens don't understand how the platform is really used by the folks who pay the money. If you need an example, you need look no farther than Viewer 2. $DEITY, what a hideous mess that was. It took us a solid year of effort to de-suck that. LL adopted a lot of our ideas, but their viewer is still a pain to use for anyone who's become accustomed to Firestorm.<br />
<br />
TPV developers have expanded the platform in many ways, all of which have kept users around on the platform. I personally would not be here if not for RLV, and that's entirely an open source effort. (At least I can't see LL adopting it as part of the standard platform!) Throwing us under the bus cuts off an important source of improvements.<br />
<br />
I'm not aware of any company that's made the transition from open source to closed source and survived. LL may be between a rock and a hard place, but keeping SLTNG closed source would be a big "fuck you" to a large part of the user community - and community is what LL has to have above all. Communities form around the places I discussed earlier, and communities are what keep people coming back even when they've explored all the fun places.<br />
<br />
So far, what I'm seeing is that LL doesn't want communities, but disconnected consumers. That, more than anything, will kill SLTNG, and SL, and LL as a company.<br />
<br />
No, the sky's not falling yet. It could, though, if LL doesn't handle this right. Fortunately, there's lots of time between now and then.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com2tag:blogger.com,1999:blog-3624489905439284137.post-7102260350757520652014-06-17T10:37:00.000-05:002014-06-17T10:37:20.350-05:00Kludges in the name of compatibilityThe verdict is in, and server-side appearance is a big win all around. Bake fails have dropped to being very rare and fairly easy to fix. One whole class of copybots has been rendered much less useful (those that copied system clothing). Rezzing is much faster, as are outfit changes.<br />
<br />
Nevertheless, not all is rosy in SSA-land. Before SSA, the viewer had the ability to set the avatar's bounding box height. The bounding box is the box the server's physics engine uses to decide when the avatar is going to collide with something and take appropriate action. Adjusting the height had the effect of changing the center point of the avatar, and thus making it rise or sink vertically.<br />
<br />
SSA changed that. Since all of the parts of the avatar's bounding box are determined by the shape and attachments the avatar's wearing, the SSA bake oven can figure it out all by itself. So it does. Since it's being done server-side, the viewer now has no ability to control it.<br />
<br />
This removed a useful and popular feature. Many pre-SSA viewers had a control, like the one Firestorm called Z-offset, that let the user move her avatar up or down. This was useful for mundane things like not sinking into a chair, as well as compensating for some rather extreme clothing and the like.<br />
<br />
It was also widely used to compensate for animations that were set up for one height of avatar, making them lift smaller avatars into the air and sinking larger avatars into the ground. This capability was automated in the RLV specification with the @adjustheight command.<br />
<br />
When it was discovered during SSA testing that the Z-offset feature no longer worked, we raised the issue with the folks at LL. Nyx Linden went out of his way to implement a fix on his own time: the hover attribute on an avatar's shape layer. The fix works well for what it does, but it doesn't cover all of the use cases - and arguably the ones it doesn't cover are the most common ones.<br />
<br />
Henri Beauchamp fixed the omission. Unfortunately, he did it in a really hackish way: he took the Z-offset specified with the control, or @adjustheight, and modified the shape the user is wearing. It works, to be sure, but it's a real kludge.<br />
<br />
There are several problems, most notably that the shape must have modify permissions for the feature to work at all (else the SL permissions system is violated, a strict TPVP violation) and adjusting the height results in modifying an asset on the SL asset server. I find the latter most curious, since Henri resisted implementing the current outfit folder in CoolVL Viewer based on his unwillingness to depend on automatic asset updates from the viewer.<br />
<br />
The Firestorm team discussed it internally, and decided not to implement this kludge. We felt it was just too problem-prone, as well as either being limited by the permissions system or else requiring a violation of it to be useful in many cases where the user has purchased a no-mod shape. As it happens, LL has said that shapes are not intellectual property and therefore not protected by the permissions system...but bypassing it on this basis makes us vaguely uncomfortable. (And yes, allowing shape import/export makes us a bit uncomfortable as well, but since the LL viewer does exporting without considering permissions...)<br />
<br />
Marine Kelley now has a product, the <a href="http://realrestraint.blogspot.com/2014/05/new-release-pretty-mummy.html" target="_blank">Pretty Mummy</a> set, that depends on @adjustheight to work properly. It looks really nifty, with several components, both fitted and unfitted rigged mesh, and has a lot of capability and a lot of complexity. However, it apparently does not work well if @adjustheight is broken. Marine's answer is to tell people to use her viewer or CoolVL Viewer, which have Henri's kludge in them. (She also tells people to use Singularity, but according to one developer, that viewer doesn't have the kludge - and won't implement it either, for the same reasons we won't. We're not sure why Singularity users can see the item properly, if in fact they can.) Further, the product seems to issue @adjustheight whenever the avatar is moving - several times a second. This is a recipe for corruption.<br />
<br />
The right answer is not to kludge around the lack as Henri did, but rather to implement a proper Z-offset mechanism in SL that propagates through the SSA bake process. This will require LL to help out. What we don't know is why Nyx did it the way he did. We suspect, but do not know for sure, that a real fix was suggested and turned down internal to LL. If that's the case, then we may not be able to convince LL to implement it properly.<br />
<br />
Until this is fixed right, we see no reason to implement Henri's kludge. We've come up with a tiny bit less kludgy solution internally, and may implement it if nothing better is possible (involving physics layers, which aren't protected assets). Still, the right answer is to get LL to do it right.<br />
<br />
We're especially not going to implement Henri's kludge for the sake of compatibility with one product. Sorry, Marine.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com0tag:blogger.com,1999:blog-3624489905439284137.post-78314844498378527512013-11-17T17:28:00.001-06:002013-11-21T00:39:34.681-06:00Some Mistresses are more equal than othersFor a couple of years, I was a member of the <a href="http://thelatexdolls.net/" target="_blank">Sisterhood of the Latex Dolls</a>. 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Unfortunately, this is only true if you're not a HeadMistress. If you are, Obedience to Equality does not apply to you.<br />
<br />
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.<br />
<br />
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 <strike>Riona not following SSC.</strike> <b><i>Edit</i></b>: 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<i><b>Edit, 21 November:</b></i> This was Kiri's response to seeing this post:<br />
<blockquote class="tr_bq">
[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.<br />
[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.<br />
[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.<br />
[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.<br />
[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.</blockquote>
She missed a couple, but I left them myself when I saw this.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com2tag:blogger.com,1999:blog-3624489905439284137.post-37837327730858045762013-09-28T15:42:00.000-05:002013-09-28T15:42:56.806-05:00*!:{[%CuteStoreName%]}:!* and other annoyancesI 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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 *<i>item</i> by Jaimie Earst. That means that it's scattered around everything else where the vendor used a * for decoration.<br />
<br />
Why do vendors feel the need to get cute like this? I wish they'd stop.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com0tag:blogger.com,1999:blog-3624489905439284137.post-9368509443092073022013-08-30T13:24:00.001-05:002013-08-30T13:24:21.011-05:00Worse than uselessEver 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.<br />
<br />
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.<br />
<br />
(There's another, smaller problem: The code itself is, to put it bluntly, unreadable crap. That can be cleaned up, though.)<br />
<br />
Cryptography is incredibly hard to get right, and incredibly easy to <i>almost</i> 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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?)<br />
<br />
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.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com2tag:blogger.com,1999:blog-3624489905439284137.post-58697769914937781882013-08-29T10:18:00.000-05:002013-08-29T10:19:58.026-05:00"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.)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.)<br />
<br />
Needless to say, this offended most of the team.<br />
<br />
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...<br />
<br />
McCabe <a href="http://inworldz.com/forums/viewtopic.php?p=138601#p138601" target="_blank">posted</a>:<br />
<blockquote class="tr_bq">
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.</blockquote>
I'm happy to hear that. Now, how about apologizing for that slam you laid on the team for the world to see?<br />
<br />
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.<br />
<br />
The ball's in your court, IW.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com5tag:blogger.com,1999:blog-3624489905439284137.post-44568156416551290642013-08-27T10:13:00.001-05:002013-08-28T07:40:00.384-05:00Exports and imports and permissionsRecently, 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.<br />
<br />
The baseline for this discussion is paragraph 2.b of the <a href="http://secondlife.com/corporate/tpv.php" target="_blank">Third Party Viewer Policy</a>, which says:<br />
<blockquote class="tr_bq">
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."</blockquote>
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.<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.) <strike>But no, nobody's got an exporter that will do mesh objects.</strike> <b>Edit</b>: 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com0tag:blogger.com,1999:blog-3624489905439284137.post-58315037200640631222013-08-24T13:02:00.000-05:002013-08-24T13:02:39.667-05:00SSA is a success, first time outWe'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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
That's the whole idea behind server-side appearance. Its purpose is to fix bake fail once and for all.<br />
<br />
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".<br />
<br />
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 <i>and</i> 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.<br />
<br />
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.)<br />
<br />
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.)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
We complain at LL when they screw up. Let's cheer them on when they get it right. This time, they got it right.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com0tag:blogger.com,1999:blog-3624489905439284137.post-50502651264423914952013-08-19T14:53:00.001-05:002013-08-19T14:54:37.727-05:00Last callLinden Lab has announced that <a href="http://community.secondlife.com/t5/Featured-News/Project-Sunshine-Goes-Grid-Wide/ba-p/2148427" target="_blank">server-side appearance will go live across the entire grid this week</a>.<br />
<br />
This is it, folks. No more dithering. No more procrastination. No more excuses.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Upgrade. Now.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com0tag:blogger.com,1999:blog-3624489905439284137.post-8883417007753171732013-07-25T00:59:00.000-05:002013-07-25T00:59:14.471-05:00The default SL avatar mesh sucksI'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 <a href="http://www.grometsplaza.net/" target="_blank">Gromet's Plaza</a> 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.<br />
<br />
I've been using <a href="http://blog.machinimatrix.org/avastar/" target="_blank">Avastar</a> 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.<br />
<br />
This picture shows the biggest problem for what I'm doing:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiaafiOMUPV9E0PoUDqJfNlE4EbM1OLaRpeCsDvsf6-r9VD5oFGESISlpjuXHAOQCff726LnmVJjNvWGuLaNmoTWZMaZTOQ2XC23EHf2gXP-RJxyHJIBIzwCoFRInuSswzrOmGfAUC3gys/s1600/avatar+thigh+deformation.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiaafiOMUPV9E0PoUDqJfNlE4EbM1OLaRpeCsDvsf6-r9VD5oFGESISlpjuXHAOQCff726LnmVJjNvWGuLaNmoTWZMaZTOQ2XC23EHf2gXP-RJxyHJIBIzwCoFRInuSswzrOmGfAUC3gys/s320/avatar+thigh+deformation.jpg" width="240" /></a></div>
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.<br />
<br />
There's a JIRA, <a href="https://jira.secondlife.com/browse/STORM-1800" target="_blank">STORM-1800</a>, 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.<br />
<br />
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.<br />
<br />
Compare this:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPxUTeCAqaCOYIUzup8DbZKGutHu98lLjiMK4XZ-TGf6ybhwpbg2ri9Sh-xsWeBMaXcRxDXaM15yNKQ1dBa3J5Og-lqehKTulREDKGDujFOfuSi3eZT0rEf_7ag4BYzQTmMpXgVLiXFnE/s1600/standard+avatar+mesh.tiff" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgPxUTeCAqaCOYIUzup8DbZKGutHu98lLjiMK4XZ-TGf6ybhwpbg2ri9Sh-xsWeBMaXcRxDXaM15yNKQ1dBa3J5Og-lqehKTulREDKGDujFOfuSi3eZT0rEf_7ag4BYzQTmMpXgVLiXFnE/s320/standard+avatar+mesh.tiff" width="239" /></a></div>
with this:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_0K3vtd4boj5J2kdHMXy29lyO8mgLA-m8gAfzYCo7uCyUpL7UTMcG54LzODyi-WddNaVq1zMmSYEMycV9KpIeMUAHrFDfTnOTymu9MzknqVj6GPu2MfzVOH2R7gMnHYMFmEP1PztQ-WY/s1600/Utilizator+avatar.tiff" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg_0K3vtd4boj5J2kdHMXy29lyO8mgLA-m8gAfzYCo7uCyUpL7UTMcG54LzODyi-WddNaVq1zMmSYEMycV9KpIeMUAHrFDfTnOTymu9MzknqVj6GPu2MfzVOH2R7gMnHYMFmEP1PztQ-WY/s320/Utilizator+avatar.tiff" width="240" /></a></div>
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 <a href="https://marketplace.secondlife.com/p/UTILIZATOR-Avatar-20-beta/2861916" target="_blank">Avatar 2.0</a>, his idea of what a replacement avatar should be. He gets it right, for everything I've seen.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com2tag:blogger.com,1999:blog-3624489905439284137.post-8166700987152423802013-07-22T14:31:00.000-05:002013-07-22T14:35:20.138-05:00A difference in approachThere'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.<br />
<br />
Henri <a href="http://secondden.blogspot.com/2013/07/tracking-lls-big-changes.html?showComment=1372791057742#c8752849800961389190" target="_blank">commented</a>, on <a href="http://secondden.blogspot.com/2013/07/tracking-lls-big-changes.html" target="_blank">an earlier entry</a> on this blog,<br />
<blockquote class="tr_bq">
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.<br />
For your info, the *only* tools I'm using to program are a text editor (nedit), and the 'grep', 'diff' and 'patch' commands.</blockquote>
He also noted, in <a href="http://secondden.blogspot.com/2013/07/tracking-lls-big-changes.html?showComment=1372771834515#c5805272808762944989" target="_blank">another comment</a>,<br />
<blockquote class="tr_bq">
Also, April is quite late for SSB support (I had it fully working and released in January, i.e. 3 months sooner)</blockquote>
There's only one problem, but it's a doozy. As it turns out, his SSB code has a major bug in it. <a href="https://jira.secondlife.com/browse/SUN-99" target="_blank">SUN-99</a> 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.<br />
<br />
Henri has never made it any secret that he disagrees strongly with the whole idea of the COF. In <a href="http://blog.nalates.net/2013/07/11/ssa-follow-up-2013-28/#comment-119604" target="_blank">a comment</a> 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.<br />
<br />
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.<br />
<br />
(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.)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Nyx Linden just sent out <a href="https://lists.secondlife.com/pipermail/opensource-dev/2013-July/009662.html" target="_blank">a long email</a> 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.<br />
<br />
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 <i>have</i> 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.<br />
<br />
Henri may be able to do things faster, but a wrong answer is still wrong no matter how fast you get it.<br />
<br />
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 <i>right</i>.<br />
<br />
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 <a href="http://secondden.blogspot.com/2013/07/dealing-with-screwup-story-of-firestorm.html" target="_blank">Firestorm 4.4.1</a>). We can always improve. We know enough to realize that. So do our users, and that's what really matters.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com10tag:blogger.com,1999:blog-3624489905439284137.post-66033561116014727822013-07-10T09:24:00.001-05:002013-07-10T09:24:16.081-05:00Server-side appearance is rollingLL has started rolling out server-side baking.<br />
<br />
Inara Pey has <a href="http://modemworld.wordpress.com/2013/07/09/ssba-rolling-to-letigre-wednesday-july-10th-plus-catzip-updates/" target="_blank">an excellent treatment</a> of just what it means, especially to folks who aren't running SSB-capable viewers. Phoenix users, this means you.<br />
<br />
Still don't want to upgrade? <a href="https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CC8QFjAA&url=http%3A%2F%2Fwww.dourish.com%2Fgoodies%2Fsee-figure-1.html&ei=dW7dUbniB4rS9QTC2ICYDA&usg=AFQjCNEObGNFwhTZv3txNxzeDqR3v9ONmg&sig2=mFBnT2U17xIDWbDPR-ZH8Q&bvm=bv.48705608,d.eWU" target="_blank">See figure 1</a>.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com1tag:blogger.com,1999:blog-3624489905439284137.post-10810081607353080232013-07-02T04:29:00.000-05:002013-07-02T04:29:09.429-05:00Dealing with a screwup: The story of Firestorm 4.4.2Monday was Canada Day, eh? It was also a big, busy, pain in the ass of a day for the Firestorm team.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
There's a clause, 2.f, in the <a href="http://secondlife.com/corporate/tpv.php" target="_blank">Third Party Viewer Policy</a> that says:<br />
<blockquote class="tr_bq">
You must not impose an unreasonable or disproportionately large load on our infrastructure or interfere with our providing the normal functionality of Second Life.</blockquote>
(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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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, <b><i>SHIT!</i></b>".)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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 <a href="http://www.firestormviewer.org/emergency-4-4-2-update-coming/" target="_blank">the first of two blog posts</a> telling people we were going to have to force an update.<br />
<br />
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 <a href="http://www.firestormviewer.org/mandatory-firestorm-4-4-2-update/" target="_blank">the second blog post</a>, waited a few minutes, and blocked 4.4.1.<br />
<br />
Then we all joined the support groups and dealt with the flood of questions and complaints from the users. Oy.<br />
<br />
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 <a href="https://jira.secondlife.com/browse/SVC-7031" target="_blank">SVC-7031</a>? :-) ) 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.)<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
We did learn a lesson about our release process: Once we branch for release, <b><i><u>nothing</u></i></b> 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.<br />
<br />
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.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com2tag:blogger.com,1999:blog-3624489905439284137.post-60126404235508841372013-07-01T08:09:00.002-05:002013-07-01T08:09:50.199-05:00Tracking LL's big changes<div class="tr_bq">
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.</div>
<br />
There's a big roadblock for us, though. <a href="http://www.sluniverse.com/php/vb/general-sl-discussion/82275-materials-project-viewer-out-play-15.html#post1788272" target="_blank">As I pointed out</a> in a thread on SLUniverse:<br />
<blockquote>
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.</blockquote>
<blockquote>
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.</blockquote>
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.<br />
<br />
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.<br />
<br />
Nalates Urriah <a href="http://blog.nalates.net/2013/06/24/firestorm-update-2013-26/" target="_blank">pointed to my comment</a> 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.<br />
<br />
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,<br />
<blockquote>
“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.</blockquote>
<blockquote>
This proves how prominent is a development model over the size of the developers team…</blockquote>
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Niran's comment is more revealing:<br />
<blockquote class="tr_bq">
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.</blockquote>
"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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.Tonya Southerhttp://www.blogger.com/profile/14697801744191587576noreply@blogger.com8