This week there is no roll to the main channel. Monday was a US holiday, which would normally through of this week’s rollouts. Since there is no rollout to the main channel, we should see the typical Wednesday rollout for the RC channels.
Blue Steel and Le Tigre will have the Experience Tools preparatory package running.
Magnum will have a maintenance release with bug fixes. One fix is: “Sim crossing on vehicle fails when parcel at opposite sim border is full.” (BUG-4152). Another is a case where a viewer with a high draw distance would not connect to distant regions which are within the draw distance area.
This package includes some new features:
- Objects which are rezzed by sat-upon or attached scripts no longer inherit the temp-on-rez or auto-return timer of the parent object
- Estate managers and region owners are now prevented from being teleported by llTeleportAgentHome()
- Estate managers and region owners are no longer affected by scripts which use ESTATE_ACCESS_BANNED_AGENT_ADD
- The grey goo fence is now stricter for large object rezzes
- More robust handling of inventory management within objects
- Cleanup of controls-grabbing in LSL scripts (no functional changes)
Grey Goo was first used in K. Eric Drexler in his book about nanotechnology , Engines of Creation . It has the same meaning in Second Life, out of control reproduction/rezzing in SL. It is typically a griefer thing done to purposely bring down a region. But, it can happen accidentally.
The Grey Goo Fence refers to the various programming measures used to limit run-away rezzing and griefer rezzing.
In certain cases llTeleportAgentHome() could be used to grief estate managers. Placing a device that uses the script command at the ‘home’ could lock the avatar in a repetitive loop of rez, tp, rez, tp…
It could also be used to keep a manager out of a region they manage, leaving a griefer free to mess with the region.
The ban thing with managers is about disagreement within a region’s group. Owners could have problems with members trying to ban them and take control.
The cleanup of LSL control scripts with no functional change… I suspect that has something to do with the coming Experience Tools. I suspect AET (Advanced Experience Tools) requires significant changes to the permissions system. This change could be a related change.
There is a GPU Table update out in an RC Viewer: GPU Update Viewer 184.108.40.2062997. The table is used to recognize your video card and figure out what graphics setting to use in the viewer. The table has been in need of an update.
The RC Breakpad Viewer is currently not available. It is being updated to have all the released viewer changes. I would guess we will see it popup this week.
Several viewer RC’s are stuck in QA. The Interest List viewer is one of them. Andrew Linden said at today’s (11/12) Server Scripting meeting that we would see it any day now. But, we have heard that for a few weeks now. QA gets to say when it will hit RC status. But, hopefully soon.
Bake fail problems remain in limbo as the Inventory Changes needed to improve how the Current Outfit Folder (COF) works are still in testing. The code has moved to be available to third party viewers. I suspect it is weeks away from coming out in an RC.
There’s been a slight change in how the viewer works. When a user logs in the server sends information about what the avatar is wearing. This is part of the process that was used before Server-Side Appearance was implemented. The process could only send information about one item per slot. It could not handle the five items per slot that we use now. So, recent viewers have simply been ignoring the information. But, the viewer waited for the information to arrive.
That wait has been removed from viewers. Servers will eventually no longer send the information. This will allow avatars to render a little bit sooner. However, some older viewers may have a problem when they first login. The problem is kind of limited to newer Second Life™ users. For that reason, I’m not going to go into the details. Suffice to say the Lab is providing a fix to third party viewer developers.
The Group Ban feature is still being reworked. Oz Linden reported last week that QA had been pretty hard on it. I suspect that means they found lots problems. The author of the feature, Baker Linden, is a relatively new Linden employee. Rack the delay up to part of his learning curve.
Figuring out how to play nice with several million lines of code that you have never seen before makes for a pretty high learning curve.
Remains in QA. It is performing slowly on Mac’s.
Monty is currently updating the Lab’s third party libraries. The Lab has not rebuilt them in the last 18 months. So, there is cleanup and update work going on there. This is good prep for moving to 64-bit.
Server side Monty Linden is looking at placing more connection limits. One of those is in regard to mesh downloading. We have a setting that users are abusing: Meshmaxconcurrentrequests (Debug Setting). Monty is watching stats. A few people are abusing this setting and impacting other users. Those creating 1,000 connections screw everyone else’s connections.
So, to get everyone better performance, the Lab will be introducing reward and punishment limiting. If you’re interested in the details of this see: Third Party Viewer meeting (01 November 2013) @ 40:00±. If you are using a setting of more than 32 connections, you may want to lower the setting.
Reward/Punishment limiting is about throttling your connection to SL. If the Lab detects excessive connections being made, they will throttle the connections. That will result in your having worse performance. If you are using fewer than average connections, you’ll be rewarded with better performance from priority handling.
The current Share Feature sends a highly compressed 1024×1024 pixel image to Facebook. Plus a SLURL is attached as is a load of Google Analytics info. Questions are being asked about whether these things can be changed.
Apparently the Lab is working on improving the compression for better image quality and possibly enlarging the image size.
The Lindens are going to have to consider whether the Analytics and SLURL info can be dropped by third party viewer developers’ versions of the feature.
Firestorm crashes are being reported by the viewer and recorded by the error system. But, viewer freezes are not being reported. This makes it look like Firestorm x64 is very stable.
Oz Linden explained some of the nature of Breakpad, the viewer’s error reporting system, that makes it skew reporting to look like a viewer is freezing rather than crashing. When Breakpad can recognize the error, we get a crash report. But, several of the error conditions are not reported as they are unrecognized. This makes it look like the entire viewer and reporting processes froze and failed to report.
The new Breakpad Viewer has revised the code and will do a better job of reporting. They Lindens are moving the code to earlier in the viewer initialization and later in the shutdown code. The change will catch more problems.
The 64-bit viewers are claimed to be faster on about half the systems running them and slower on the other half. Again, this would be a matter of your system being a major factor in viewer performance.
Those using 64-bit prototypes are saying they are more stable. But, we do not yet have good data on whether they are or aren’t.
We do have good statistics on how stable operating systems are. The 64-bit systems are significantly more stable than the 32-bit systems of the same OS. So, at this point it’s hard to tell if it’s bugs in the 32-bit OS that the 32-bit viewer is hitting and thus crashing more or if the 64-bit viewers are actually more stable. It may just be that the 32-bit bugs are not in the 64-bit system OS’s. Thus there are fewer bugs in 64-bit OS’s tripping up the viewer.
Oz Linden is telling us that people within the Lab are taking notice of the 64-bit viewers being released by third party developers. They’re watching to see how well all this 64-bit thing works out.