Wednesday, June 26, 2013

Why We Can't Have Nice Things

When the Firestorm team released its first Server-Side Appearance-compatible version of the viewer in April, one change particularly dismayed many users: the removal of the Height Offset feature that had conveniently been located in the Quick Preferences panel. Nyx Linden put in his personal (unpaid) time to create an alternative system to take its place, specifically to assuage the distressed Firestorm users who had come to rely on this functionality. But the replacement -- a shape parameter -- has shortcomings that have nonetheless disappointed the feature's users.

No one likes it when their toys -- or in this case tools -- are taken away from them after they've had the chance to play with them, get used to them, or even rely on them for critical functions. But the Height Offset example is not the first time this has happened, nor will it be the last.

Second Life residents have a history of creating things that go beyond what Linden Lab expected or intended them to create. This shows up most memorably with viewer features, but examples of inworld content that stretch the confines of Lab-given resources come up, as well. Here are some that come to mind:

  • Invisiprims: The inworld objects designed to hide body parts but not prim objects were popular shoe components until alpha layers came around. Plenty are still in use because not everyone is in a rush to throw their old, no-mod invisiprim shoes away, but the growing popularity of shadows and the introduction of Materials are their nemeses, since enabling Advanced Lighting Model (formerly known as Lighting and Shadows) conflicts with them.
    Old-style invisiprims are incompatible with Advanced
    Lighting Model, which is off in the image on the left but
    enabled in the image on the right.
  • Phantom mode: Phantom mode was a TPV invention used to prevent others from moving your avatar if they run into you. It was incompatible with Pathfinding (released in summer 2012) and was removed from viewer updates thereafter. These days, sitting is the fastest workaround, and you can load stands into your AO as ground sits if you want to appear to be standing.
  • Viewer tags: The ability to see what viewer others were using in their avatar tags and to have your own displayed was disabled by Linden Lab as a matter of policy last year, but they would have been incompatible with Server-Side Appearance this year anyway, since they worked by piggybacking on the "old" avatar baking process. If they hadn't been shut off already, they'd fall into this category now. Viewer tags still work on other grids, but if those grids move to SSA, then you can expect this feature to be a thing of the past there, too.
  • Temporary uploads: They still exist… for now. This is the next TPV feature to sit on death row, as it will be broken when Server-Side Appearance goes into effect in a couple of weeks. Instead of temp uploads, you'll want to use the Local Texture Browser. It actually does more than the old method of temp uploads did, but you won't be able to share the textures with others inworld. For that, there are plenty of temporary photo hosting websites that should work just fine.
    Local Texture Browser allows you to see what a
    texture on your computer will look like applied to an
    object inworld without paying to upload the texture.

These extensions of Second Life's inherent capacities, these Nice Things, fit some definitions of "hacking." Not the breaking-into-internet-security-and-causing-grief definition of hacking but the kind that simply refers to "exploring the details of programmable systems and stretching their capabilities." In the SL context, this practice is so commonplace that most who engage in it probably have no idea that they could be considered hackers until the foundation their hack is based on gets swept out from under them.

The fact that Second Life draws such creativity and innovation out of its users is one of the most fantastic things about our virtual world. It encourages the best kind of hacking, "white hat" hacking, the kind that enhances experiences and bends the system to greater potential.

But when innovation takes place outside of the institution that provided the tools for it (in this case, by users such as content creators and TPV developers, instead of by Linden Lab), there is both a positive side and a negative:
  • On the positive side, the ideas go beyond the ordinary and are based on how residents use the world. They stretch expectations and intended uses of the system beyond what its programmers could have anticipated.
  • On the negative side, they're always potentially temporary. They have no insurance. If LL didn't make them or intend them to be made, then they're unsupported, and there are no guarantees that the loopholes that were found to create them will always be open.

This means that when a Nice Thing goes away, it's not usually because the Powers That Be want it gone. More often, the innovations simply don't exist in the Powers' frame of consciousness at all. When they go, it's because the Powers have other plans that simply render your Nice Thing obsolete.

It also means that from a user's point of view, the idea of a "Nice Thing" can be understood as a "nice thing to have," not an entitlement. It may come, it may go, it may come back again through different means. Adaptability and flexibility become valuable traits for those of us who have no control over Linden Lab's priorities.

This tends to be true for lots of things in Second Life. And real life. Take it from the Buddhists, who base their Second Noble Truth on the belief that the origin of suffering is attachment.

The only aspect of the Height Offset example that is unique is actually the fact that a Linden made an effort to soften the blow to TPV users. Some appreciated this and adapted; others reacted as though this feature were something they were entitled to and as if any reduction in functionality would be a major setback to their virtual lives. How we react when we lose one of our Nice Things is our choice, though. No one else -- Linden dev, Firestorm dev, or content creator -- is responsible for that.

So why can't we have nice things? Because the brilliant, creative minds in Second Life exceed our ability to let go of what they create.

I believe it is safe to assume and hope that users will continue creating things that stretch beyond what is intended of the system they're creating in. And while they do, by all means take advantage of them. That's what they're there for. But you'll enjoy SL most in the long run by accepting things both as they come and as they go. Some Nice Things are unsupported and, thus, uninsured. If we lose them someday, it is your decision whether you cling and complain or whether you say, "Well, that was a nice thing to have while it lasted."


  1. The invisiprim feature is *not* a hack: it was implemented by LL in early SL days for shoes and other attachments that needed to hide body parts, and yes, even nowadays, even with the Alpha wearables, it is still useful (e.g, for in-world items your avatar 'sits' onto and that need part of the latter's body to disappear from sight while not impairing the view of what is behind: example, a Halloween table that would show only your avatar's head on top of the said table when you "sit" the said avatar on it).
    Note that some TPVs (Cool VL Viewer and Singularity) *can* properly render invisiprims in deferred rendering ("advanced lighting) mode, and LL is only two (!!!) lines of code away from having it working properly in their own viewer (why they didn't yet fix it is a mystery only LL could explain...).

    Note also that, while the "AvatarZ offset" feature is seriously impaired by the current server-side implementation of SSB, I came up with a work-around that works (much slower than in non-SSB sims, but it works) as long as your avatar is wearing a mod-ok shape: that work around will be in tomorrow's Cool VL Viewer releases.

    Henri Beauchamp.

  2. Sorry Henri, that's incorrect.

    Invisiprim was indeed an hack, but technically was a render glitch.
    It was never intended by Linden Lab and this was discovered by a user who was messing around with UUID key from list of texture asset that came with the client. It had some texture on it and the user would just stretch it out to only use the portion of the glitched area. This was one of the special kind of texture that can not be uploaded, thus only access through this one texture on UUID key.

    Many years later, Linden Lab decided to fix this large alpha order issue bug and the fix broke invisiprim texture. This upset a lot of people because of the shoes/avatar and etc etc... Caused an uproar and Linden Lab later decided to support it with a quick fix and provided a much better and cleaner texture version of that glitch. Then it became some-what implemented "feature".

    Nonetheless... it was about time we have alpha layer for avatars. :D

  3. for attachments, invisiprim got imho some well working substitute with alpha-layers. And that with less negative side-effects as invisiprim had. For this alpha-layers look to me as the right solution.
    But now we have to see how our friends jump gleefully in water filled, already sinking boats! OH NO! And we can't hold them back from doing so!
    Also all the dry-docks are filled with water now.
    For hiding water i do not see any nice substitute in the moment.
    Even if that is often frustrating to see our long years learned and appraised 'hacks' seeing gone, imho it could really be a somewhat good trade. Personally i think this creative 'hacking thinks better' would not being stopped as long as Resis are have a true interest in SL.

  4. I'm sorry, Nacon, but you are plain wrong, and if you had the slightest idea of what you are speaking about (that is, any knowledge about the renderer pipeline code), you would know that the so-called "invisible texture" is in fact just an arbitrary UUID (it could be any other UUID, really, and the corresponding "invisiprim" texture doesn't even exist in the asset server) used to ***flag*** invisible faces (that got their own, specific code path in the viewer and could in no way be a "render glitch": it's a voluntary code path, very specific to the viewer renderer and *not* an exploit).

    I'm working on the SL viewer sources for over 7 years now (and I got 35+ years experience in computer programming, from machine code (yes, I started programming on a MC6800 in hexadecimal opcodes, with and hexadecimal "keyboard" (more like a phone keyboard" and a 6-digits, 7 segments "display": 4 for the address, 2 for the opcodes/data !) to the latest highest level languages), so I know pretty darn well what I am speaking about...

    Plus, like I explained, the alpha wearables don't suffice to cover all use-cases for "invisiprims".

    Henri Beauchamp

    1. Hmm 7 years, that's neat. Oh my... not the hexadecimal!

      You should stop before making a big fool of yourself.
      Feel free to ask any devs out there.

      PS: It's not on server, because it was a client-asset. Derp.

  5. Local texture browser is fine for items you can directly mod, but more and more vehicles are coming out no-mod with texture paint scripts and local doesn't work for those. The ideal situation would be for LL to eliminate the texture upload fee entirely or come up with a workable temporary texture system of their own that wasn't a hack.

  6. Obvious one does not know how much Sl community owns to Henry (V1 interface tpv's being able to see mesh anyone?)
    I would love to see that solution being implemented on LL viewer as less then a minority of regular Sl users have Always Lightning and Shadows on, as i can attest cause im one of those few, that still sees in any public place, more then 35 pct of screwed shoes, cause users don't really use lightning and shadows option enabled and therefore they will not notice the problem, that is of easy fix for most of the shoes (just wear a alpha of the size of the feet and they will render proper, i even carry a folder with fp layers and a notecard for those i see and i try to explain them the diff in how they look to me and to them).
    How much i would love to not see fu****up feet!
    And that makes me wonder on another subject, how many users will ever see materials!