13 July 2012

Viewer 1 is officially on borrowed time

At today's Third Party Viewer Developers meeting, Oz Linden announced three upcoming changes. (The audio recording of the meeting can be heard from the archive here.)

1) Pathfinding. The pathfinding code has been rolled out on the Magnum RC channel, after a few false starts, and seems to be running well. The pathfinding tools will soon be released in source form for integration into other viewers. They'll be needed to edit the pathfinding properties of objects, and to trigger a rebuild of the navigation mesh that pathfinding objects use to move around.

2) From the Shining Project, an overhaul of the HTTP interface in the viewer. The code has been completely reworked. The new code fixes many, many HTTP bugs in the current viewers - but it's incompatible. It'll go on a new TCP port. It'll also not work very well with older consumer WiFi or DSL routers.

3) Also from the Shining Project, server-side baking. Currently, your shape and hair and system-based (but not prim-based) clothing are all initialized and merged together by your viewer and then uploaded to the servers. This is known as baking, and when it doesn't work, you get bake fail. That's what produces the orange clouds you see when someone logs in sometimes. The new code will have your viewer attach whatever, update the Current Outfit folder, and then notify the server - which will then turn around and notify an internal server that does the actual baking. This should eliminate bake fail. However, once again, it is incompatible with current viewers.

The second and third changes are longer-term. Oz said that we should plan for two to six months; I don't know if that estimate is better than Linden Lab's historic estimates (which tend to be optimistic), but we should plan on their being accurate.

The result of the final cutover to the new HTTP library is that the viewer won't be able to communicate. The result of the server-side bake is that viewers that don't handle it will simply see gray avatars, with no way to fix them.

Needless to say, there will be plenty of warning before the switch gets flipped. Oz committed to giving us at least two months' notice, unless he is unable to convince higher ups that they need to give us that after making a decision to switch faster. There's not a lot he can do in that case.

When it does, though, viewers that have not been updated will simply refuse to work. 1.23 will not be updated, and this will spell the end of it on Second Life. Older versions of all other viewers will also stop working. Viewers that are not actively maintained will die off.

We will, of course, be fully ready with Firestorm, assuming that Linden Lab gives us enough lead-time to actually integrate the code and release with it before they flip the switch.

Other folks may choose to make the necessary adaptations to work in the new environment. It will be interesting to see whether Henri Beauchamp implements the new bake, since he doesn't like the Current Outfit folder and went to some lengths in CoolVL to avoid having to use it. Some viewers are in active development, and I expect them to continue. However, the only V1-based viewer that will survive is Singularity, I expect, with the possible exception of CoolVL. I expect Siana Gearz to do the needed work as soon as the code's available. Nobody else is developing a V1 viewer any more.

Phoenix is a more interesting question. Just in case there's any doubt, what I'm about to say is my own personal opinion, and not that of the Phoenix Viewer Project. The group has not made any decisions yet.

To me, it's time to say that we are not going to put any more effort into Phoenix.

Yes, that's right. As far as I'm concerned, it's time to put Phoenix to rest. The developers don't like working in the codebase, as in many ways it's an unmaintainable tissue of hacks, the support team barely remembers how to run it, and Firestorm now provides essentially all of the function Phoenix has and much more besides. There's even a selectable interface that caters to Phoenix users. (If you are one of those, select Phoenix mode at the login screen. Have fun.)

I realize this will be an unpopular change, especially for folks who refuse to run Firestorm or any other V2/V3 viewer. However, there comes a point when making an old program run in a new environment simply isn't feasible. We're a volunteer project. There's essentially nobody here who wants to keep putting effort into Phoenix any more. Firestorm does everything that Phoenix does. (Two exceptions: OTR IM encryption, which a small but very loud fraction of users want, and object import/export and some build tools that depend on it. I expect both to be in Firestorm by the time the incompatibility switches get flipped.)

There are some folks whose creaky old computers won't run Firestorm. Guess what, folks? It's time to upgrade. Past time. If your computer isn't hopelessly low-end and was built in the last 4 years or so, it'll run Firestorm. If not, then it's past time to upgrade anyway. Yes, I know this is hard-hearted sounding. It's also simple reality.

There are other folks who swear up and down they'l never run Viewer 2 or its descendants. Well, folks, your bluff is being called. You've been saying you'll leave SL before you'll run Viewer 2. It's time to shit or get off the pot.

Me? I'll be happily running Firestorm 5. (Or whatever we choose to call it.)