Hypergrid Business has an article by Maria Korolov titled: Linden Lab cuts viewer link to OpenSim. This is about a rather subtle change in the Lab’s viewer that creates a not so subtle result.
To use the viewer on a grid other than the Linden grids a small change is made in the desktop icon used to start the viewer. If you right click on the icon and select Properties, you will see a field labeled: Target. It is in the Shortcut tab. The instructions there tell the computer how to start Second Life™.
Knowledgeable computer users will recognize the text as a command line instruction. If you open a command line window you can type in or paste in the text you find there as a command and Windows will start and run the viewer.
To get my copy of the Development Viewer running on OSGrid I use the command:
“C:\Program Files\SecondLifeDevelopment\SecondLifeDevelopment.exe” —channel “SL Development” —settings settings_osg_dev.xml —loginuri http://login.osgrid.org —loginpage http://osgrid.org/ —helperuri http://helper.osgrid.org/
There is a wiki page listing the viewer’s command line options. See: Viewer parameters.
The parameter being removed is: —loginuri = Login server to connect to. We know some of what is happening because Nebadon Izumi, one of OSGrid’s movers and shakers was talking with Oz Linden about the change. See: Chat Fragment. I can understand Neb’s frustration and annoyance.
This will mean that all OpenSim grids will eventually be accessed only by Third Party Viewers. THAT IS A PROBLEM for a number of reasons.
It is inconvenient for me. I often use the LL viewer for visiting OSGrid. Lately I have been using Dolphin 3 as it has better multiple grid support than the LL viewer and is about as current as the Linden Release Viewers. Occasionally it has some new bugs of its own and can miss out on some of the Linden’s latest bugs. In general it is a good viewer and works well. Firestorm and Phoenix have had a problem with littering the landscape with their ‘bridge’ device/attachment.
This change is a hint at where the Havok License is taking the Lab. The inclusion of Havok on the client side (meaning in the viewer) has it benefits and problems. We get features that we would not have otherwise. Currently Havok is only used client side to create the convex hull representations on mesh upload and to render the Navmesh used with Pathfinding. The rest of Pathfinding is server side.
The Lab is making a library of Havok functions needed by the viewer. The library can then be used by third party developers to compile a viewer that includes the Havok functions. The license permits the Lab to make the library and distribute it for use with Second Life where Havok is further licensed to provide the physics engine for the server side of SL.
The license in some measure prohibits the distribution by the Lab of the functions built into the library using Havok’s code with any platform or game not owned by Linden Lab™. That is a bit of simplification, so don’t try to extrapolate. But it essentially means: you can’t use the Linden made library based on Havok code on the OpenSim grids.
Removal of the command line switch -loginuri removes a simple means of directing the SL Viewer to use a grid other than the Lab’s. That removal is likely a show of good faith on the Lab’s part to meet their contractual obligations to Havok.
For third party developers the problem becomes whether to support the viewer functions based on Havok and available in the library or not. The Firestorm Team licensed Kakadu to handle images as the Linden viewer does. It is unclear whether they can use some of the free license options Havok makes available to those writing code for games not sold for profit, or at least not significant profit. I’m not sure whether purchasing a Havok license is economically feasible. Whatever the case, the team has said they will split the Firestorm viewer to create an SL and an OpenSim versions of the viewer. One version will use the Lab’s Havok library file and one won’t.
That splitting into multiple versions of the viewer may be what other third party developers do also. Whatever problems that makes for the developers, it means I’ll have double the viewers installed. I also expect to start having cache and appearance problems again. So, I’ll be trying to run versions of viewers that try to combine; settings, chat logs, logs, crash reports… and separate all those things to minimize problems.
When we had these problems with caching it took some time for viewer developers to make their caches separate by default. So, if you are a Windows user and run multiple viewer brands, if you look in AppData\Local now you will find a number of viewer folders holding a separate cache for each viewer. These tend to be folders using a huge amount of disk space, several gigabytes. My Second Life Development Viewer currently has a 5gb+ collection of cache files.
Some brands of viewers are already creating folders separate from chat, logs, and settings. Looking in AppData\Roaming you’ll find a number of folders named after viewer brands.
Now we are likely to need separate caches and settings for the two types of grids or viewers dedicated to a specific grid. We may not need this level of separation. But, it will be sometime before we know and it will be dependent on how OpenSim and Second Life develop as we move forward in time.
I think it is becoming clear there will be more separation between OpenSim and Second Life. As any network gets smaller it is less useful. So, I don’t see this as a good thing for either OpenSim or SL. But, I suspect the Lab has little room to maneuver within the Havok license they signed.
While the Bullet physics engine is getting more love and developing for use in OpenSim, there is no practical chance that the Lab will abandon Havok and switch to another engine. The Lab is using more features from Havok, like Pathfinding, that would require major refactoring to change to another engine. So, this division will likely continue to produce more incompatibilities between the two grids. Only time will tell us how well the open source people will cope with these challenges.
For now it would probably be a good idea to keep a copy of the 3.3.4 or earlier version of the SL Viewer, if, of course, you play on multiple grids.