• About us…

  • The archives

  • RSS The Gaming Session

  •  Better and faster with IPv6

  • ipv6 ready

I’ve already said that I think that Second Life basic mode is a good idea. I think it’s an excellent idea, in fact. I think it doesn’t go far enough, however.

What’s better than a basic and an advanced mode cobbled awkwardly on top of an aging and brittle presentation layer?

A customisable user-interface with the basic and advanced modes as preset configurations, among other possible options.

Work on Second Life’s user interface (like viewer 2, and basic mode) is somewhat akin to building household appliances from an Austin A40 Cambridge. That is to say, that the parts you’re making it from are dated, inappropriate, and inherently unsuited for the tasks that you’re applying them to.

Over the years, the Lab’s focus on low-cost/high-gain modifications to the Second Life viewer have resulted in a presentation layer that is almost inextricably threaded through every part of the code; indeed, flowing all the way back along the communications protocols.

Years of hacks have led to a situation where every modification visible to the user now yields a deferred cost in constraints to future modifications.

While there is ostensibly a communications layer, a presentation layer and a user-interface layer, the truth is that there isn’t any genuine separation. Every part of every ‘layer’ comes into direct contact with parts of each of the others.

Want to access (say) the description field on a prim or in-world object? Well, you can, but that reaches right down vertically into the bowels of the communications code, and horizontally affects object editing, or anything else that wants to get object data.

Touch one thing, and you have to be mindful of almost everything else. That’s where a lot of viewer bugs and regressions keep coming from. Not enough room to swing a cat, as they say, without causing UI features to malfunction, or the client/server communications to subtly misbehave.

With Viewer 2, Linden Lab had the opportunity to actually go back to the drawing board and fix this, producing a modern design that could cater to current (and projected-future) needs, and expand the scope of what was possible to implement simply, and more cost-effectively in the viewer, without painting themselves back into any corners for quite some time to come.

The Viewer 2 UI and Basic mode are intractable hacks build on an aging pile of organic code. That’s one of the reasons that you need to double-restart the viewer to switch into our out of Basic mode. Sure, that can be fixed, with yet more inscrutable hacks, that contribute to an increasingly brittle codebase.

I think it is past time to modernise, and perhaps we can have a properly customisable user-interface in the bargain, while the Lab gets code that is easier and cheaper and more predictable to work with.

Tags: , , , , , ,

Got a news tip or a press-release? Send it to news@taterunino.net.
Read previous post: