Servers
Late yesterday, after 7PM PST, the Deploys post appeared. We did get a server update roll to the main channel today (2/4). Tomorrow, Wednesday, we will get a roll to the RC channels. There’s nothing earthshaking in either of the releases.
Server-Scripting UG 2014-5
The package that made it to the main channel is the one that includes the Linden Scripting Language (LSL) function: llModifyLand(). Inara has more on this change. See: SL projects news 6/1: Server, viewer, SSA and AIS project viewer.
The package going to the RC channels is a package with a crash fix. The package is going to all three channels. And that’s about all we know about.
Viewers
All the versions available were covered earlier in Second Life News 2014-5 #2. Since then only a couple of things have changed.
Second Life HTTP Viewer version 3.6.14.286010
This RC Viewer has updated since last week. For Mac users this version has an important fix; DNS problems. This is a long-standing problem that the bit and a lot of people. It isn’t limited to just Mac users. But it seems more Mac users than Windows users run into it.
If you know people that are having DNS problems, you might want to recommend this RC Viewer. Also, there are fixes a person can use to resolve the problem. See: Troubleshoot Your #SL Connection.
Some of the errors this addresses are listed as:
- DNS could not resolve the Host Name
- I can’t log into Second Life with WIN 7
This version is also using the new HTTP protocol for downloading mesh objects. This change should reduce the number of connections needed by 75%. So, those with connection issues and/or older routers may find that this RC Viewer gives them a better connection to Second Life™.
This RC Viewer also uses the new HTTP protocol in the mesh upload process. Apparently several things have been done to make this more reliable.
So, uploading or downloading this viewer should handle mesh better.
Mesh2MaxConcurrentRequests
You may have found this Debug Setting (Mesh2MaxConcurrentRequests) and/or heard about it in various forums, posts, and group chats. Until now the conventional advice has been to increase the value of this to improve your performance for downloading mesh. With the release of this RC Viewer that changes.
The problem with this setting is many users were setting it to ridiculously high values. If there are numerous people in the region that have high values for this setting throws a heavy load on the region server. The net result is things slow down. The really unfortunate part is the slowdown for everyone, not just those with the high-value setting.
The Lindens have talked about penalizing those that are using high values. So if you’ve been using a high-value for Mesh2MaxConcurrentRequests and you install this version of the RC Viewer your want to go back to a default setting.
The new recommendation from the Lindens is to decrease the value from the default setting to improve download performance.
MeshUseGetMesh1
This Debug setting, MeshUseGetMesh1, can be used to revert this RC Viewer’s download protocol to the old-style. The Lindens did not expect this to be needed. But, it’s there.
The Cool VL Viewer has been implementing the new mesh fetching code for a few weeks now (i.e. I backported it as soon as LL made the code public), and it works beautifully !
Note that the crazy increases in former mesh mesh concurrency setting by some (many ?) users was due to bugs in the mesh repository code, namely lack of proper locking (the mesh repository runs as a thread, and if both that thread and the main thread modify the same data because of a missing lock, that data becomes inconsistent). This problem sometimes made the mesh fetching queue stall (it got stuck with pending downloads, filling up HTTP connection slots and keeping them \locked\ forever); the only work-around was then to increases the mesh concurrency to gain more free slots and resume mesh data downloads.
I had one such missing lock fixed in the Cool VL Viewer, but the new fetcher caught two more missing locks, fixing the mesh repository for good (so the benefit of the new fetcher is not just about using less HTTP connections, but also about fixing what was *very* buggy code).
As for the old (v1) mesh fetching capability, it is essential to keep for OpenSim compatibility (at least till OpenSim folks updates their server software to cope with the new protocol).
Thanks for the insights. 🙂