Some big news from this week is the release of the ‘Interesting Viewer’, this is the viewer with improvements from the Interest List project (ILP).  The project is about doing a better job of deciding what to render first.

Torley did a good job of illustrating what the project does.

For months we have been getting the server side changes from the project. For weeks we have been promised the viewer side changes. Now those changes are out in a RC Viewer release: Second Life 3.6.11 (283895) Nov 13 2013. 

If you are using the current main release viewer, 3.6.10-283403, you may want to change your Preferences (Top menu: Me->Preferences->Setup tab-> enable ‘Willing to update to release candidates) then download the Interesting Viewer RC. It is important you enable release candidates BEFORE installing the RC Viewer. Otherwise the system will try to switch you back to the main release viewer.

Don’t get confused. The Help->About… panel has the viewer miss named as: Second Life 3.6.11 (283895) Nov 13 2013 20:19:17 (Second Life Release). Normally RC viewers have the project name in this slot. So, Interesting Viewer should have appeared in the ID field. I think someone goofed.

The improvements in this viewer are listed as:

• More viewer-side control of which objects are loaded in memory at any given time
• More aggressive scene caching – viewer stores whole region in cache, not just the parts in view when you log out
• Faster scene load when visiting a region you’ve never been to before
• Viewer does not load object from cache that are completely hidden by scene geometry
• Expanded performance metrics

None of these new features change your user interface, no new buttons or controls. But, the viewer does work differently. When returning to an area things rez much faster. Also, as the video says, things rez in a better order, near things first.

How the viewer works with the servers is the big change. A part of the work done on the server is now done on the viewer. The viewer makes more decisions about what is rendered when. The viewer also sends the server information on whether the avatar has visited the region before. If not, the server and the viewer avoid the long and boring conversation of the viewer telling the server what items it needs to render. The server just sends everything. As counter intuitive as that may seem, it reduces the total communication load.

With new HTTP pipelines being added and improved the server can poor all the region’s information through the pipe. Only one connection has to be negotiated. It can be maintained while all the data is pumped to the viewer. That makes things easier on routers and the entire Internet connection path. As we see more pipeline improvements in the coming phase II HTTP project the download speed will improve.

Server News

Nothing has changed since Tuesday. See: Second Life News 2013-46.

But, you may have noticed that rezzers rezzing large objects are broken on Magnum. When the Lindens tightened the Gray Goo limits they broke a number of rezzing devices. They are looking at a fix.

The change was made to block a type of griefer object that rezzes large physical objects to overload the servers’ physics engine. So, the increased limit is being adjusted to ONLY apply to the rezzing of physical objects. With any luck that change will be in an RC update next week (47).

Mæstro Linden tells us, “…[in] an upcoming maintenance project we have a fix for ‘ Vehicles containing a mesh are returned to the owner upon region crossing when destination parcel is full’, which was similar to BUG-4152, but only affected meshes and involved the actual entry parcel being full.

also there’s a fix for “Temp Attachments are sometimes not removed on the viewer when detached from a region change event.”

To follow up on “llTeleportHome() [it] should not teleport estate managers”, there’s one about that function not affecting the parcel owner either  (or a group owner if the parcel is group owned).”

These fixes should appear in a package rolling out in week 47.

Group Ban

Baker Linden is still working his way through the QA required changes. He explained, “I’ve also (hopefully) figured out how to handle granting ban power to roles. By that, I mean what happens when you give a role the ban ability. Since I’ve really been hating how weak the ban ability is (in that you need to be able to eject and remove roles from members in order to truly ban anyone).

I’ve decided that if an owner grants a role the ban ability, it will implicitly give them BOTH the “Eject Ban Members” AND “Remove Roles from Members” ability.  This will be the default, but there is nothing stopping the owner from removing those abilities.

I will be displaying a dialog box warning the owner of this. So, if they want to make ban only eject Everyone roles, then they can remove the “Remove roles..” ability. And I’m going to make the simulator smart enough to simply strip the roles from the member and eject them automatically, so no more having to remove roles before ejecting!

I’ll also make that happen in the old eject code too, but only if you have both roles enabled. So you should be able to click “ban” on member and they’ll be added to the list and ejected, no matter their role. It’s a powerful role, but you shouldn’t be giving away ban hammers to any schmo.

I’m doing some backend stuff still, and I’m going to change the ban reason field to a ban priority field instead, taking some numbers or something, and it’ll be a way to anonymize the reason for banning, but still allowing for easy sorting of lesser offenders. So there will be SLID, Date, and Priority (or whatever I end up calling it).”

Zindra Expo

The Zindra Expo group is meeting Saturday morning at 11AM SLT/PST. The meeting is in Eichorn Cove, just down the beach from my home. Everyone is welcome.