The third party viewer (TPV) development meeting was Friday August 9th. This is information from that meeting. This is usually the stuff that is fun to know.
Viewer Release Pipeline
There are currently 5 release candidates in the people line. Oz Linden says this is going to a larger number of candidates than he expects to be normal. This is a backlog of viewer work winding its way through the testing process.
The Vivox candidate viewer has made it all the way through the new process. It is now the new primary release for the SL Viewer 3.6.2-279258. The updates in that viewer are now being merged into the remaining candidate viewers. We should see those all updated during week 33.
The Lab is going to make this Viewer Update code available to TPV Dev’s. They have already tested it with some of the viewers with a small user base. Oz says it seems to work. The nuance of his voice suggests to me there are some doubts and concerns. Enough so that this code will likely appear last in the Firestorm Viewer. The Lab wants to make absolutely sure the code is working before the largest user base in Second Life™ starts using it.
It is uncertain whether this code will be made available. It may turn out that it won’t be. However, the Lab wants some means of keeping all SL users on recently updated viewers. We had information on the nearly 2,000 version of various viewers being used to log into Second Life.
Of course, if it is made available, there is no requirement that the FS Team add it into their viewer. That will be the FS Team’s decision.
I am not at all sure that adding it would be a good thing for FS. I think they were moving toward their own update process.
Whatever the case, adding this update process to all viewers could really complicate running multiple viewers. I’m in the process of trying to debug what I have to do to run multiple Linden viewers with the new update pipeline. If TPV’s get thrown into the mix I think we will see lots of install problems over the coming months.
On a new Win7 install, I am amazed at the SL garbage I’m already finding in my new registry. I may have to setup a test machine just to analyze what is happening in the registry.
BUG-3522 – Auto update of Viewer 3 release installs to the last location you installed any build of Viewer 3 and does not overwrite your previous install of Viewer 3 release.
Oz Linden addressed this point in the meeting. They are looking at the problem. It appears there is something in the automatic-installer program that remembers the last location used and installs to that location. It seems to be a Windows specific problem. Changing the installer is not something they want to do. Especially since the work-around is to simply turn off Automatic Updates.
While the Lindens are highly appreciative of the small core of users that test multiple viewers at the same time, it is a small number. The priorities for other problems are higher and the work-around exists.
Settings.xml & Arguments.txt
If you are a non-geek-ified user these files are not something you deal with. The settings file is mostly where your viewer’s Preference and Debug Settings are remembered. Project Viewers have and currently continue to use their own settings file. Oz tells that will be ending. As will use of the arguments.txt file, may be.
This will means all Linden Viewers will use the same settings file. I think arguments.txt is just going away.
The Snowstorm Candidate, I think, will be the first release to have this change. Whatever channel it is in, it is build 220.127.116.119634 (Release Notes).
It is unclear whether they are removing the command line option to specify which settings.xml file to use. We used to be able to add a –settings: [filename] to the Windows shortcut’s command line and the viewer read settings from that file. It sounds like they are removing that capability, but maybe not.
To know how well a viewer is running the Lab looks at Crash Rates. Oz gave us a more precise definition of what the term means to the Lab.
When a viewer is running it is setting what I’ll call state flags. When a viewer exits normally the state flag goes to zero. On the following viewer start it looks at the last state flag reported from the viewers previous secession. Anything other than a zero is reported as a crash.
Oz tells us this rate is determined by the region servers. A disconnect is reported when the server decides a user has gone away. A normal log off tells the server ‘bye’. If the viewer stops communicating and never says ‘bye’ the server counts that as dissin’… er… disconnecting.
Closing a laptop or powering off a computer while the viewer is running is going to register as a disconnect. Viewer crashes are going to report as a disconnect.
Google Breakpad Candidate
The definitions above will give us ideas of what is being done with the Google Candidate. Breakpad is all about error reporting. Implementing Breakpad is going to give the Lab better crash data and make tracking down bugs easier.