We are getting a new rollout today. This is the package that ran on the Magnum channel last week. This is a package with fixes for Pathfinding. The continuous re-bake of the Navmesh is one of the problems solved.

If you had not turned off the terrain re-bake notification it could get annoying. So, this will be a welcome fix. It only affected regions that had multiple parcels with boundaries under water. So, not a common problem.

Release Candidates

Le Tigre is going to continue to run the Server Side Appearance (SSA) package. I was expecting this to move to the larger Magnum channel. But, that is not the plan now.

This version has a fix for a problem where a new note card with attachments could not be saved. Plus the package sent to the main channel has been added. Otherwise this is the same package that ran last week.

Blue Steel will continue to run the Experience Tools package. It seems only the main channel updates are added to this package. Otherwise, it is the same as last week.

Magnum gets a new package this week. It includes some fixes and a couple of additions. One fix is for a teleporting problem that broke collision detection. Run time permissions were not triggering in attachments, that should be fixed. There is a fix for Pathfinding characters that manage to get out of their home parcel and get stuck.

A new capability is ‘RenderMaterialsCapability.’ This has something to do with an access rate for render materials process. Previously this was set at 1 per second. They have upped that to 4. I’m not sure where this fits into the scheme of things are exactly what it does. I’m taking away that something could be faster. I think this was described by Maestro Linden as allowing viewers to send more requests for materials. Simon Linden conformed it does have to do with the new Materials; Normal and Specular maps.

Double Restarts

There was some problem with the Tuesday rollout. At some point the rollout was apparently restarted, which caused some number of regions to restart twice.

SSA Information

There is some information from Maestro and Nyx Linden on how SSA works.

SUN-38 is a JIRA about losing the avatar height adjustment that several third party viewers (TPV) have had. That feature is broken by SSA. Nyx says they know about the problem but did not consider it a blocker for the release of SSA. So, we are not likely to see a fix for the non-supported height adjustment that SSA breaks.

There is a height adjustment in Appearance that can help. But, it is a coarse control and leaves a lot to be desired.  For now we deal with it.

Cool VL Viewer has a feature to restore the feature. But, it only works with Mod-OK shapes and it has some limits.

Nyx Linden tells us, (I’ll paraphrase) …there are two stages to getting your server-generated appearance. First, your viewer requests an appearance message. This is the message that gives your avatar parameters (height, shape, etc), as well as a set of texture ID’s that represent your avatar’s baked textures. All this information is built into a request URL that is unique to your current appearance.

So, this is shape information  and a list of all the clothes on system layers. If I understand correctly this request for an appearance message contains all the appearance information. This request is sent to the SSA servers. They cache the URL and information and use it to bake your appearance. The baked appearance is tied to the URL. Everyone that sees you uses the same URL to retrieve your baked appearance.

When you force a re-bake request in the viewer, it asks the server again for your appearance for the current state of your inventory, your Current Outfit Folder (COF). If there was an error in processing your prior request, the server will try to bake it again.

I’m not clear on whether it always re-bakes or just resends the previously baked appearance texture. I’m guessing the SSA servers would know if they could not collect all the clothing textures. In which case I would assume in such a case it would attempt to retrieve the textures again and re-bake your appearance. Otherwise, it would know to just resend the cached appearance texture.

Nyx says our appearance is keyed on the version number of the current outfit folder. Your textures are keyed on the IDs that get generated from that version of the current outfit folder. If anything in the COF changes, the version number increments and you’ll be generating a new request and skipping the cached versions of your appearance.

So, if you have a bunch of outfits, say A, B, and C, and you wear A and tomorrow wear B and the next day wear C than on the fourth day switch to A or B will the system retrieve the previous bake? My understanding now is; no. The COF version number will have changed. So, you will get a new bake.

Is there any way to force an actual re-bake? Yes. In the SL Viewers you must change something in your appearance. I am unclear on this point, but I doubt you can take off a shirt and put the same shirt back on and get a re-bake. You can however add a tattoo, remove one, make any change that changes your appearance and that should force a re-bake.

Some third party viewers are adding a feature to bump the COF version number. That will make your appearance different as far as the SSA servers are concerned. They will then re-bake your appearance and send you a new texture.

The Lindens think such a feature is redundant. They do not expect to see the SSA servers corrupt a texture. They will either bake it or fail. In the later case they retry.

Time will tell who has it right.

There is some concern that COF version numbers on the server and in the viewer might get out of sync. Nyx says that is possible but, the viewer and server sync to the servers idea of what you are wearing at login. Nyx says they are looking at other ways to keep them from getting out of sync. But, just changing something in your appearance will likely pull the versions in the viewer and servers back into sync. Nyx says they have seen cases where that didn’t work, but it is rare.

About the only room for a bake-fail is in sending the baked appearance to the viewer. Or the appearance request to the SSA servers. The system should automatically self correct for those errors as the connection is an HTTP protocol.

So our current re-bake (Ctrl-Alt-R) is going to be more of a ‘resend’ than a re-bake.

We are unlikely to see any more controls for SSA on the viewer side in the SL Viewer. But, we’ll probably see some in the TPV’s that will trick the SSA servers into doing a new bake.

So, far SSA seems to be faster and working well.