[kokua-dev] Fw: [TPVD Announce] Important news re: Server Side Appearance (SUN-74)
nickyperian at yahoo.com
Sat Jun 15 17:10:42 PDT 2013
----- Forwarded Message -----
>From: Oz Linden (Scott Lawrence) <oz at lindenlab.com>
>To: tpvdir-announce at lists.secondlife.com
>Sent: Friday, June 14, 2013 11:58 AM
>Subject: [TPVD Announce] Important news re: Server Side Appearance (SUN-74)
>We will be able to discuss this further at the TPV meeting (Noon SLT today)....
>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
>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
> 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.
>Scott Lawrence | Director of Open Development
>Skype ozlinden | Second Life Oz Linden
>Linden Lab| Makers of Shared Creative Spaces
>SECOND LIFE | PATTERNS | CREATORVERSE | DIO | VERSU
>You are subscribed to this list because this address was given as a contact address for a viewer listed in the Second Life Third Party Viewer Directory.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kokua-dev