Server-side Appearance – Page 8 – Inara Pey: Living in a Modemworld

SL project reports week 17 (2): COF corruption and SSB/A

Posted on April 25, 2013August 22, 2013 by Inara Pey

At the Open-source Dev meeting on Wednesday April 25th, Whirly Fizzle raised a concern on the status of JIRA SVC-7653, which relates to Current Outfit Folder (COF) corruptions leading to an avatar being unable to log-in to Second Life which may have an impact on the forthcoming Server-side Baking / Appearance switch-over.

The problem was first publicly reported by AngusGraham Ceawlin in February 2012, and at the time became of the focus of a campaign to Free Angus. After a total of some 63 days unable to log-in and with the (particular) support of Whirly herself and Nicky Dasmijn, Paspund Resident and Izzy Linden, Agnus was indeed freed. However the problem has become a matter of concern again because SVC-7653 remains marked as “unresolved”, and a workaround developed for it looks set to be “broken” when SSB/A goes live.

The "Free Angus campaign poster" produced by Sparkles Alchemi and used in a number of blog posts in early 2012 to highlight Angus' situation — The “Free Angus campaign poster” produced by Sparkles Alchemi and used in a number of blog posts in early 2012 to highlight Angus’ situation

The COF Corruption Issue

When this particular issue occurs, the user has no clear indication that there has been an inventory corruption specific to the Current Outfit Folder. There are only tell-tale clues, which Whirly Fizzle documented (on behalf of Kitty Barnett) as being:

Only one account is affected
A crash or timeout disconnect will occur at log-in, usually around “Downloading clothing…”
The affected account will crash/disconnect on any V3-based viewer or a viewer that uses COF
A clean install, cache clear, replacing outfit on a non-COF viewer will not fix the problem
The associated viewer logs will usually show:

INFO: newview/llappearancemgr.cpp(1998):LLAppearanceMgr::updateAppearanceFromCOF : starting

Generally (but not always) followed by numerous warnings:

WARNING: newview/llappearancemgr.cpp(2891) : WearablesOrderComparator::operator(): Warning # 0: either item1 or item2 is NULL

Followed by a crash or a timeout.

The Workaround

While LL’s support staff do have scripts to deal with various inventory corruptions and issues, under current rules, they will only run these scripts for Premium accounts. While it may be possible to get further assistance from the Lab if you’re not a Premium account holder, it is certainly going to take a good deal longer to gain assistance. As a result, Kitty Barnett developed a workaround for non-Premium members, which Whirly included in her comments on SVC-7653:

Use a viewer which does not have COF support and log-in to SL. Currently, Imprudence is possibly the most easily obtainable such viewer
Replace outfit with a Library avatar. Thus must be a complete outfit change (every layer / attachment)
Log out of the viewer
Launch a TPV which uses the VerifyInitialWearables debug setting (such as Catznip, Exodus, or Firestorm – note that the official viewer does not have this setting)
At the log-in splash screen:
- Go to the top menu bar and select Me/Viewer > Preferences > Advanced and tick Show Advanced Menu
- From the top menu bar, go to Debug > Debug settings > VerifyInitialWearables and set it to TRUE
Login to SL.

This should result in a message being sent to the server by the viewer using the VerifyInitialWearables which will result in the COF corruption being “fixed” and the avatar being able to log-in successfully to SL. A change of outfit should then verify that all is well.

The Workaround and SSB

Tests carried out by TPV developers have shown that the VerifyInitialWearables message sent by the viewer is ignored by the SSB/A servers. This has resulted in concern that unless the Lab have developed a resolution for this issue, anyone encountering it once SSB/A is “live” will not be able to utilise the documented workaround, and they’ll effectively be unable to log-in to Second Life unless they are a Premium member (or upgrade).

The matter has apparently been brought to the attention of the SSB/A team (led by Nyx Linden), who have been engaged in a wide range of inventory updates and associated work, “More than they hoped would be needed,” as Oz linden put it at the Open-source Dev meeting. But whether or not their work extends to fixing this particular problem is unclear. SVC-7653 remains “unresolved” but inactive – so it is perhaps possible a fix has been developed internally by the Lab without SVC-7653 being updated. However, until greater clarification is given, this is likely to be a subject of note at User Group meetings which deal with SSB/A matters.

SL projects update week 17 (1): Server releases, SSB/A, particles

Posted on April 24, 2013August 29, 2013 by Inara Pey

Server Deployments – Week 17

SLS Main Channel

On Tuesday 23rd April, the SLS Main channel received the update package deployed to the three Release Candidate channels in week 16, primarily comprising the new server-side LSL Animation Override capabilities, complete with a fix for BUG 2164, wherein the new capabilities could conflict with built-in animation poses in chairs, etc., as discussed in my week 15 updates. This deployment additionally includes the slight region performance improvement when there are no pathfinding characters present. Release notes are available.

Release Candidate Channels

On Wednesday 24th April, the RC channels should receive the following updates:

BlueSteel and LeTigre: should gain a new project which brings preliminary server-side support for experience permissions – release notes
Magnum: should gain a new server maintenance project. This update brings some new minor features to LSL, and fixes some crash modes – release notes

So the long-awaited experience tools / advanced content creation tools permissioning system looks to be finally on its way, a little under a year since an exploit caused them to be withdrawn after their initial deployment.

Viewer Updates

Development Viewer Updates

The SL development viewer has been through a rapid series of updates over the last few days of week 16 and the start of week 17, with version 3.5.2.2744 released on Monday April 22nd. While release notes are not available, it is thought it includes (among other things), the fix for music stuttering every few seconds when using FMOD EX, as submitted to LL by Latif Khalifa (see OPEN-173).

Particle Project Viewer Soon (?)

It appears a new particle project viewer may be on the horizon in the near future. If it does appear, it is likely to be primarily aimed at testing a new capability to help deal with griefing attacks which use particle emitters. Speaking at the Simulator User Group meeting, Simon Linden said:

We’re doing some testing and may get a project viewer out, which would allow you to test it and (I believe) let other viewers check out the source code. This is right-click on a particle, and it kills the generator … We’ve tossed around a few ideas about blocking particles in other ways but definitely want to get these first steps out the door.

This sparked further discussion on ways and means to help stop particle griefing, which has been on the increase across the Mainland of late. However, given that particles are a viewer-side effect, “stopping” them is actually easier said than done from a server-side perspective. One idea which gained some interest, if it is feasible, would be a block of any particle emitters belonging to an avatar banned from a region / parcel.

In the meantime there are means of stopping the viewer from rendering all particles – such as CTRL – Alt – Shift – +, or going to Preferences > Graphics > and dropping the Particle Count slider to zero. These again only work in your own world view, and while not always ideal, do present an option.

Asked if such a particle project viewer might include the new LSL particle capabilities already deployed server-side, Simon could only say, “Hopefully yes … I’ve been working on getting that chunk of code solid for the last few days. Unfortunately it’s pretty easy to crash at this point and so it’s not ready for consumption.”

The particle ribbon effect is a particle which repeats the texture horizontally, and can follow the object creating them, which offers a lot of potential uses, as which forms a part of the new particle capabilities – soon to be seen within a project viewer? – Time will tell.

Server-side Baking / Appearance

The viewer-side code for SSB/A is starting to appear in more TPVs:

Cool Viewer has had SSB/A support in the “Experimental” branch for a while, and this moved to the “Stable” and “Legacy” versions on April 20th – see the Cool VL website and release notes
Singularity released version 1.8.0 with SSB/A support on April 21st, which I’ve reviewed
Firestorm released version 4.4.0 with SSB/A support on April 22nd, which I’ve reviewed
Kukua has had an experimental / development version since the start of April (version 3.5.1) which also incorporates SSB/A.

The status of the SL beta viewer with the SSB/A code will take place around the middle of week 17, when a decision taken as to whether to incorporate the code into the SL release viewer or run a further beta release. The expectation is that the code will move to the release channel unless a last-minute significant issue is found within the code which prompts a further run in beta.

Assuming the code does make it to the release channel, it is likely that a release viewer will appear early in week 18 rather than late week 17, due to the time required to test and QA a build.

SUN-72 – Fix Submitted

One issue which is known to exist within the current beta release of the SSB/A viewer code and which has caused considerable problems is SUN-72 – if you have inventory items with special characters (including the likes of asterisks) in their names, they will fail to load. Similarly the use of accented characters (e.g. such as René) in things like chat log path names, the logs are not saved.

Nicky Dasmijn of the Firestorm team developed a patch for this specific problem which is already incorporated into the recent Firestorm 4.4.0 release, and which has been contributed to, and accepted by, the Lab for integration into the SSB viewer code. Hopefully, it should be appearing in the next SSB viewer release, whether beta of SL release viewer.

Sun-38 – Avatar / z-offset

As noted in my last major update on SSB/A, the ability to offset an avatar’s height on-the-fly to accommodate various animations (e.g. kneeling), or to adjust an avatar’s height when sitting / walking of floors, etc., and which will effectively be “broken” as reported in SUN-38, remains an issue for many.

While the Lab have produced an alternative approach which addresses some issues around avatar height offset using new appearance sliders, and which Nyx Linden and others have been continuing to tweak, there is no solution on the horizon for maintaining any form of on-the-fly adjustment; nor does the proposed solution work with no-mod shapes, as noted when I first reported on the “fix”.

During the Content Creation User Group meeting on Monday, April 22nd, a request was made for the Lab to not shut-down the existing baking service until such time as SUN-28 is “solved”, which prompted Nyx to comment:

SUN-38 is not currently considered a blocking issue for our initial release. It’s on our list to investigate, but we don’t have a patch or update immediately. There is a new hover parameter, which should work for attachments that affect your avatar, but the bug reported is also discussing the need to adjust the offset on the fly without changing wearables. Having both the new and the old system enabled is not an option … We are investigating options, but it is not a hard requirement for the initial release.

Continue reading “SL projects update week 17 (1): Server releases, SSB/A, particles” →

SL projects update: week 16 (4): More on SSB, materials and FMOD Ex

Posted on April 20, 2013August 22, 2013 by Inara Pey

Server-side Baking / Appearance

Viewer Releases

An updated beta viewer was released on April 19th (3.5.1.274264, with release notes here), which contains a range of updates, including several for SSB/A. Speaking at the TPV Developer meeting on Friday, 19th April, Oz Linden indicated that the current plan from the Lab is that this is likely to be the last beta viewer release for the SSB/A code unless a major blocker shows up. Assuming this doesn’t happen, then it is more than likely the SSB/A will move to the SL viewer release channel and arrive as a viewer update towards the middle of week 17 (week commencing Monday, 22nd April), which should hopefully be an automated update for most users on the SL viewer, given the majority appear to keep that option active on their viewers.

Given us, it is liable that we’ll start seeing more TPVs updates appearing in the near future – and people using TPVs are going to need to start installing and using those updates rather than remaining with older versions of their viewer if they are to avoid the “grey people” syndrome as the server-side of SSB/A is deployed.

Users will need to update to version of their preferred viewer supporting SSB/A as they are made available to avoid seeing grey people — Users will need to update to a version of their preferred viewer supporting SSB/A as they are made available if they are to avoid seeing grey people once the deployment of the server-side of SSB/A commences

Server-side Deployment

The precise means by which the server-side will by deployed is still not absolutely clear. As noted a number of times in this blog, Nyx Linden is hoping that things will progress somewhat cautiously, possibly starting with a set of “carefully selected and constrained regions on Agni” as the viewer code reaches the SL release viewer. This still appears to be the case, but it is possible that it will not – as Nyx has previously hinted – roll through the Release Candidate channels.

“I don’t know whether it will go through the normal RC process,” Oz Linden commented at the TPV Developer meeting, “Because it’s not actually a server software change; it’s a configuration change, so they don’t need to deploy it through the RC progression. All they have to say is, ‘Yes, throw the switch!'”

If this approach is taken, it’s currently not clear whether or not it will require a region restart.

In terms of time frames as to when this might happen, things are similarly unclear at this point – a lot depends on how well the testing on the selected Agni regions progresses. However, Oz suggested that the time frame in which the “switch may be thrown” to be anything between 2 and 6-8 weeks from when the viewer-side code appears. His analogy was that of a bell curve, wherein the switch-over could occur at the top of the curve – but could, if circumstances dictate, occur at either end of the curve.

Communications

It is still hoped that there will be a concerted effort on the Lab’s part to communicate server-side baking ahead of any server-side flipping of switches. A blog post is apparently in preparation, which should go out when the SSB/A code is issued in the release viewer; whether this will be supported by other means of communicating the changes is unclear.

However, communications on the whole is not easy – even with the TPVs also liable to be spreading the word through blogs, etc., (as Firestorm have already). This is because even with the official blog, TPV blogs and blogs such as this one, the vast majority of SL users do not read blogs.

Matters are also further complicated by the fact that there are over 1700 different viewer strings which are used to connect to SL (even if not on a daily basis). These not only include the official viewer and current versions of TPV-registered viewers, but also many instances of older versions of TPVs, Snowglobe (1.x) based viewers, several versions of the official 1.x viewer (some of which date back over 5 years), viewers which are not registered with the TPV directory, self-compiled versions of various viewers, and so on.

As such, whatever the effort made to communicate the arrival of SSB/A is liable to be missed by a good number of users and people are going to find themselves facing grey avatars as a result of the switch to SSB/A, because many of these additional viewer strings will not have the necessary viewer-side code. This inevitably means that there is going to be some disruption and upset. While this in turn doesn’t mean that attempts to communicate the coming change shouldn’t be made – but it does mean that even with the best efforts of the Lab and TPVs combined in communicating SSB/A, there is going to be an outcry. So anything all those who are aware of the upcoming changes can do to communicate it to others – particularly when there is a visible log post from LL on the matter which can be referenced – can only help lessen the volume of that outcry.

Continue reading “SL projects update: week 16 (4): More on SSB, materials and FMOD Ex” →

SL projects update week 16 (1): SL viewer, materials, SSB and other bits

Posted on April 15, 2013August 22, 2013 by Inara Pey

SL Viewer Updates

There’s no movement on the release viewer, and likely won’t be until Server-side Baking moves to it, having finally arrived in the Beta viewer on April 12th (see below). The Development viewer was also updated on April 12th, with the release of version 3.5.2.273873, which includes both SSB and CHUI updates.

Materials Project

An update to the materials processing project viewer was released on Friday April 12th – 3.5.1.273855 – with a series of bug fixes included in it. There are further updates on the way, with the next release due around the middle of week 16, which will have further bug fixes and, hopefully, some Alpha mode updates as well. Commenting on the latter at the Content Creation User Group on Monday April 15th, Geenz Spad said, “Actually just got normal maps working on alpha blended objects, and trying to get everything else working on them as well.”

One fix currently pending is that for MATBUG-16, Changing one material, or setting causes another material texture to be lost. This is an issue which can happen as a result of several factors. For example, setting a normal or specular map for one face of an object can result in maps already applied to other faces of an object either being removed or replaced with the most recently added map. The same issue can occur when applying a setting such as glossiness to one face of an object using materials.

MATBUG-16 demonstrated using 2 deiffuse maps and their associated normal maps. (l) the prim with a diffuse map added to one face & with the "stone" normal map still showing for all faces. (r) the normal map add — MATBUG-16 demonstrated using 2 diffuse maps and their associated normal maps. A prim previously set with a stone diffuse map and associated normal map has a green diffuse map applied to one face – the normal map is unaffected (l). However, when the normal map is updated, it changes for the entire prim (r)

This problem doesn’t happen every time mixed materials elements are used on object faces, but can occur when adding multiple materials elements to an object in quick succession. “There are a couple of problems there,” Oz Linden said while discussing the problem at the Open-source Dev meeting on Monday, April 15th. “The updates to the server are happening faster than it will allow, which is one problem. The other is that the updates are not applied locally as smoothly as they should be.”

Tonya Souther, who re-worked the Build floater for materials processing added, “Yeah, that bug has been driving me batty ever since I first did the UI. And I think that’s due to the design of the system…the UI has to ask the server for the material separately, and apply the values retrieved from it to the UI components when they arrive. That ‘s the only way that the UI won’t get out of sync with the actual values stored on the server … I just need to find a way to make the delay not apparent to the user and handle changes that come along in that period.”

For now, the answer seems to be that if you experience any issues with normal / specular maps vanishing or being replaced when using multiple maps / effects across different faces of an object, then allow a short pause between adding the various maps / effects so the viewer and server can keep pace with your work.

Elsewhere, Geenz Spad, one of the architects of the materials processing system, has started a new blog series on materials, Second Life Materials: A Content Creator’s Guide. In the first part of the series, he answers the question, What’s a material? In the next installment, he promises to take a look at some of the tools which can be used to create normal maps.

Server-side Baking

The viewer Server-side Baking /Appearance code reached the Beta viewer in week 15 with the release of 3.5.1.273869 on April 12th. The initial stats apparently show it is doing well, crash-wise, but the status of incoming bugs is currently unclear. However, it still looks as if the code is currently on course for around a two-week stint in the beta viewer prior to moving to the release viewer channel.

A key bug fix for the system has been SUN-57, which now allows multiple layer of clothing to be worn / swapped on regions which are not running the SSB server-side code (on Aditi), which removes a potential road block from server-side code deployment (remembering that for a time during the server-side deployment, updated viewers must support both the old and new avatar baking services).

The SUN-57 issue, as defined by Whirly Fizzle: left - Outfit A from her My Outfits folder replaces whatever she was previously wearing, and appears correct; centre - after a relog, she repalces Outfir A with Outfit B, and again, everything appears correct; right - she replaces Outfit B with Outfit A, but her skin fails to bake correctly, the head and legs showing the skin associated with Outfit A, the torso still showing the skin from Outfit B (shown naked for clarity) - images courtesy of Whirly Fizzle / JIRA SUN-57 — The SUN-57 issue, as defined by Whirly Fizzle, which saw issues occurring in avatar baking using a viewer supporting the upcoming “new” SSB/A service and changing outfits on a region only supporting the current avatar baking process, which saw outfits and skins failing to update correctly following changes. Reportedly now fixed

There are still no definitive timescales for any Agni deployment for SSB/A. As previously reported in this blog, it is still unlikely that any major deployment operations will commence prior to the SSB cove reaching the release viewer.

Other Items

I recently blogged about Oculus Rift and speculation as to whether it would see use in Second Life. On April 7th, Jon Brouchoud blogged on why SL would be a “killer app” for the headset – an article which has seen widespread reprinting / referral in SL / Opensim related blogs. While I have no particular opinion either way as to Oculus Rift / Second life (although how it will work with the SL UI does intrigue me), I have to admit the following video demonstrating Oculus Rift had me smiling from ear-to-ear. It’s not really related to Second Life, but it is well-worth watching.

Server-side Baking / Appearance update

Posted on April 6, 2013August 22, 2013 by Inara Pey

The Server-side Baking / Appearance (SSB) project took a significant step forward when, as reported in my week 14 projects update, the viewer-side code reached the SL development viewer. Barring any significant issues, it should also be appearing in the SL beta viewer very shortly.

While it will still be a while before the new service makes its debut on the main grid, viewers supporting the new service are liable to start appearing over the coming weeks and communications from the Lab and TPVs on the subject are liable to increase. As such, it seemed appropriate to blog on the most recent discussions on viewer updates in general (LL and TPV) and on the upcoming server-side code deployment, using the TPV Developer meeting on Friday April 5th as a reference.

A Quick Recap

For those who are still perhaps unaware of what Server-side Baking / Appearance is, I have an overview of the project, with detailed information on what it is, how it will work and what will change. However in short.

What is it all about? Primarily solving the issue of “avatar bake fail” (when your skin or clothing layers appear blurry to you or those around you, or when you change outfits and you see yourself wearing the “new” outfit and those around you still see you in the “previous” outfit). This happens because the current process of “baking” your avatar’s appearance (the skin and clothes it is wearing) is driven by the viewer, and hiccups c in the viewer / server communications can result in the server failing to receive all the necessary information following a change of outfit & is unable to process it, leading to the problems mentioned above.
What does it do?
- The new service moves much of the emphasis for the baking process from the viewer to a series of dedicated servers (sometimes referred to as the “ovens” required to do the baking), which should reduce the amount of viewer / server communication and ensure the “bake” process is more robust.
- As some of the work is still carried out by the viewer, it also is being updated with new code
Why Should I Care? The new service is incompatible with the avatar baking mechanism currently in use. This means that once the server-side of the new baking service starts to be deployed on the main grid, viewers which have not been updated to use the new service will no longer function correctly; people using them will see those who are using updated viewers as permanently grey figures (other than attachments).

The SSB problem in part: I'm stabding on an SSB-enabled region. On the left - as I appear to others who are using an SSB-enabled viewer; On the right, as I appear to others who are using a viewer which does not support SSB. — The SSB problem in part: I’m standing on an SSB-enabled region. On the left – as I appear to others who are using an SSB-enabled viewer; On the right, as I appear to others who are using a viewer which does not support SSB. The latter group would appear as unrezzed ghosts to me

Where Things stand and the Road Ahead

In order to try to make the switch-over between the “old” and “new” baking services as smooth as possible, and minimise the issue of “grey” avatars, the actual deployment of the new service will effectively be in two parts:

Because the viewer side of the SSB code will work with the existing baking service, this will be deployed first, in the hope that people will upgrade their viewers as new versions (both the official viewer and TPVs) become available
The server-side code will start to be deployed on the grid as the viewer code reaches the SL release viewer; however, this will be a gradual process, driven in part by the number of people either updating to or transitioning to SSB-capable viewers.

The Viewer – LL and TPVs

As noted above, the viewer code for SSB is now available in LL’s development viewer (as of release 3.5.0.273529), and will shortly be arriving in the SL beta viewer before moving to the release viewer (possibly in around two weeks, although this does depend on whether or not unforeseen issues arise when the code is in either the development or beta viewer).

Third-party viewer developers have also been working on integrating the SSB code into their viewers (and several already have pre-release / alpha / experimental versions of their viewers with the code already implemented, which they have been making available to their users for testing purposes). As such, TPVs are liable to be releasing updates to their viewers in the next few weeks which users will be strongly advised to take for the reasons noted above.

Quite when TPVs will start releasing SSB-capable versions of their viewers is going to be something of a balancing act. Given that there is a chance that unforeseen bugs / issues are found within the viewer code while it is in the SL beta viewer channel, some may opt to not make any release until after the code reaches the SL release viewer channel in order to avoid the risk have having to make two (or more) updates in quick succession as a result of bugs being found. Others may opt to make a release alongside the upcoming SL beta viewer release, and track how things progress, updating their viewer as required.

Communications

A vital part of the deployment process is that of communications. Therefore, in the coming weeks users can expect to see both LL and their preferred TPV developers communicating directly on SSB as viewers become available / server-side deployment commences in order to encourage as many as possible to update to a viewer supporting SSB ahead of the the server-side deployment.

Continue reading “Server-side Baking / Appearance update” →

SL project updates week 14 (2): Server releases; deformer

Posted on April 3, 2013August 22, 2013 by Inara Pey