As we’ve been rolling out Server Side Appearance, a few reports have
been coming in about specific users having issues with the current outfit
folder. The good news is that very few users are reporting serious issues.
The bad news is that it looks like some viewers are not handling the COF
quite correctly. To help narrow down the possible issues below is a list of
how the COF should be handled, please take some time and look over the
following behaviors to make sure your viewer performs in a way that is
compatible with the standards defined by the secondlife viewer. This list
shows how our viewer handles the COF, which defines the protocol that is
compatible with the Second Life service. As long as these guidelines are
followed, your viewer should be compatible with other installed viewers and
with the Server Side Appearance system. If you deviate substantially from
this protocol, it could interfere with our ability to provide normal and
expected functionality. As always if you have any questions or concerns
regarding the appearance system, please do not hesitate to reach out to me
directly.
Keep reading to the end to get additional information on details of future
releases from the Sunshine team!
1.
There should be only one folder of type ‘FT_CURRENT_OUTFIT’.
1.
The ‘Current Outfit’ folder should be the special type
‘FT_CURRENT_OUTFIT’. There should be only one such folder, its
name should
be ‘Current Outfit’ and it should be a child of the root inventory folder.
2.
Please verify the following items in your viewer:
1.
Verify that there is not a code path for the end user to create or
delete this folder.
2.
Verify that no code path would allow this folder to be duplicated,
automatically or by user interaction
3.
Verify that no code path exists that would allow this folder to be
moved out of the root of the inventory.
4.
Verify that this folder will only be created on login, and only if
it does not already exist.
5.
Verify that no code path can rename this folder.
2.
The current outfit folder (COF) is the authoritative source for what the
user should be wearing
1.
Everything the user should be wearing should have a link in the COF.
2.
This should be kept up to date at all times (not just login/logout),
in case of viewer crashes
3.
The contents of the COF should be what is loaded and worn for the
avatar on login.
4.
Please verify the following:
1.
Verify that all clothing, body part, and attachments that a user
should be wearing have a link in the current outfit folder
2.
Verify that on changing outfits, this remains true once all
network operations resolve
3.
Verify that the avatar’s appearance is read from the COF and
loaded appropriately on login, without modification, except
if the COF was
left in a bad state.
1.
Note that inventory changes are most likely to fail during
times of heavy network usage - this includes login.
3.
All links in the COF should be “valid” links when at all possible.
1.
“Valid” links make a reference to an existing item in the user’s
inventory tree.
2.
Links can be presented as broken if they refer to an item in the
library, an item that has been deleted, or cannot be properly
fetched, but
viewers should avoid creating these links if possible
3.
Please verify the following:
1.
When a user wears an item from the library or from an object’s
inventory, it is copied into their inventory, and a link is
created to the
newly created instance.
2.
Links are not copied to the COF or worn if they are broken.
3.
The user has sufficient feedback to see which links are broken.
4.
The COF should maintain a ‘valid’ appearance
1.
A valid appearance requires exactly one link to each type of body
part: shape, skin, hair, eyes.
2.
Clothing and attachments can be added up to the normal limits defined
in the latest release viewer.
3.
Verify the following:
1.
Verify that there is no code path that will result in multiple
body parts of the same type being linked in the COF simultaneously
2.
Verify that even when an outfit is replaced, body parts will not
be removed unless they are being immediately replaced. Do not
assume the
replacement outfit necessarily has all body parts.
3.
Verify that the viewer will not allow more total attachments than
the Linden release viewer allows.
4.
Verify that the viewer will not allow more clothing items of a
given type than the Linden release viewer allows
If your viewer does not behave as described above, please let us know ASAP
as it will help us diagnose some of the issues that are being reported. If
you plan on making changes to your viewer to comply with this protocol, let
us know and keep us up to date on your progress. If you feel that there are
parts of this protocol that your viewer does not need to comply with,
please contact us to discuss it. Keep in mind that many users choose to
install and run multiple types of viewers from multiple computers, both on
SSA-enabled and SSA-disabled regions, and your viewer should operate
smoothly under such conditions. As always the final arbiter of the current
protocol is the source code of the latest Linden release viewer. This list
identifies some of the assumptions that our systems make in terms of how
compliant viewers should act. It is not meant to be exhaustive.
With the release of Sunshine (SSA) to the grid, we’re eliminating a lot of
the failure points in appearance resolution we were seeing. However, the
next largest failure point we’ve identified is the inventory system.
Specifically, the current inventory protocol relies on both HTTP and UDP
messages, some of which have failure callbacks and some which the viewer
assumes will complete successfully (not always accurate). If you’ve run
into situations where you have received a COF mismatch error, you have hit
this class of issue (it means that the viewer and server disagree as to
what the version number of the COF currently is).
For our next round of changes after SSA goes grid-wide, we’re working on
updates to the Agent Inventory Services (AIS), that should help alleviate
the most prominent causes of these errors, as well as hopefully reduce the
number of network calls needed to successfully update the COF. If you’ve
been tracking sunshine-internal, you may have seen references to these new
protocols. They’re not ready for release yet, and will require much
testing, but we’d like to start discussing in more detail what it will
involve.
Specifically, we will convert the most error prone operations on the COF
from using the old UDP-based system over to AIS. This includes operations
like creating and deleting links, etc. These new calls should always
resolve, and should throw sensible error codes if any operations fail.
Additionally, we’re adding some new functions that should allow common
appearance operations to resolve with less work on the viewer’s part. There
will be AIS calls for operations such as wearing an outfit from the library
(which will copy items to the user’s inventory), and wearing a complete
outfit from inventory (which will replace the current contents of the COF
with links to the items you pass to it).
We’ve been working on this new system in parallel with the first release of
Server Side Appearance. While we’ve made great progress, it is not yet
complete. Once it is we will let you know and provide more detailed
documentation about the methods involved, and try to stand up regoins on
Aditi to start testing project viewers against. It will require some time
before the code is ready to be in anyone’s release viewer, so keep it out
of your trunk branch for now.
If you have any questions about the release process, the way the current
system works, or the upcoming work around inventory, please let me know.
Thanks, and have a great week all,
-Nyx Linden
--
*Neal Orman* | *Senior Software Engineer*
Skype NyxLinden | Second Life Nyx Linden<https://my.secondlife.com/nyx.linden>
Linden Lab | Makers of Shared Creative Spaces <http://lindenlab.com/>
SECOND LIFE <http://secondlife.com/> | PATTERNS <http://buildpatterns.com/>|
CREATORVERSE <http://creatorverse.com/> | DIO <http://dio.com/> |
VERSU<http://versu.com/>
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
