In the course of testing in the restricted access regions on agni for server side appearance (SSA), a serious backwards-compatibility problem was detected.  Many thanks to Jessica Lyon for the initial report, and to a number of other open source devs for help with characterizing the problem.  The problem was detected on Phoenix, but may affect any viewer that does not have support for multi-wearables as implemented in the official viewer and does not have support for server side appearance.

Stated simply, the problem may be triggered by entry into or rebake in an SSA-enabled region, when the simulator sends an AvatarAppearance message to the viewer for its own agent.  In pre-SSA simulators, the AvatarAppearance message was sent only for other agents - never for yourself, but in SSA the viewer is sent one for its own agent as well.  This message causes at least some older viewers to delete the textures from any currently worn modifiable avatar layers, and because those assets have been modified the user is prompted for whether or not to save them.  If the user does save them, those wearables are permanently corrupted (or, technically, replaced in inventory by new assets that have no textures).

Note that any affected viewer is incompatible with SSA anyway - avatars will not render correctly in SSA regions, but that may cause users to attempt to modify their appearance and/or explicitly rebake, possibly triggering the problem rather than upgrading to a compatible viewer.  The only real solution is to upgrade to a compatible viewer, but clearly we'd all like to prevent asset damage in the meantime.

We are attempting to make server side changes to prevent triggering this problem by not sending an AvatarAppearance message for its own agent to any viewer that the simulator does not have reason to believe is not subject to this bug (yes, there are three negatives in that sentence - you're programmers, you should be able to sort it out).  Our current plan is to make that determination in two ways:

1) A new flag will be added to the RegionHandshake message sent by the viewer to the simulator when connecting to a new region.  The viewer sets the new flag to affirm that it is SSA-compatible.  This is the permanent solution.

A patch against viewer-release will be made available as soon as possible to implement the RegionHandshake change.  This allows the simulator to send the AvatarAppearance message quickest.

I'll follow up this message with a pointer to that change as soon as it's available, and you should integrate it at the earliest opportunity.

2) If the viewer makes any request to the new "UpdateAvatarAppearance" capability on the simulator, the simulator will mark it as compatible.  Whether or not this recognition will be permanent or just a transitional measure remains to be seen, but you should not count on it being permanent.

Note that the viewer doesn't normally send anything to the cap on region entry, so the avatar may not render correctly when first entering SSA regions using viewers that are only recognized this way.  Our expectation is that users will respond to the rendering failure as they do now - by doing something to rebake - which, in a compatible viewer, will trigger this recognition.

Until the simulator has recognized the viewer as SSA-compatible with one of the methods above, it will not send any AvatarAppearance message for the viewers own agent.