Category: SL User Group Meetings

SL project update: week 9 (2): servers, HTTP, SSB

Posted on by Inara Pey

Server Deployments – week 9

Server Life Server (Main) Channel

As noted in part 1 of this report, the Second Life Server (SLS / Main channel) received the server maintenance project which was on all three RC channels in week 8, comprising miscellaneous bug fixes, and the improved region restart notification. Deployed on Tuesday 26th February, the roll-out was followed by a number of issues being reported via the deployment forum thread.

Issues have included:

  • Parcels / regions vanishing from search for a period of time following the restart (an issue WolfBaginski Bearsfoot gave some thought to in commenting on part 1 of this report)
  • Further region crossing issues, with loss of control followed by “broken” camera positioning after recovery. This issue has been reported at some of the Simulator and Server Beta meetings previously, and Eric Gregan has produced a video demonstrating the problem as it occurs on some aircraft, although he’s also come up with a means of avoiding the issue which may or may not work for people.

  • Problems with Dwarfins attachments.

Release Candidate Channels

On Wednesday February 27th, all three Release Candidate channels received a new server maintenance package which includes a fix for a crash mode (see the release notes (BlueSteel)). No significant issues have been reported for this deployment.

SL Viewer

The Communications Hub User Interface finally made its debut in both the SL development and SL beta servers, arriving as release 3.5.1.270826 for the development viewer on Tuesday 26th February, and 3.5.0.270825 for the beta viewer on Wednesday 27th. I’ve provided a brief introduction to CHUI, and there is also a video from Torley Linden.

CHUI is liable to remain in beta for a “Good long run”, to quote Oz Linden. Hopefully, this may mean that materials processing will be the next significant viewer update to arrive as a project viewer.

Interest List

The recent updates to Andrew Linden’s interest list work are apparently won’t reach a RC channel in week 10, but should see deployment in week 11 (week commencing Monday 11th March). This work includes fixing issues with avatar appearance teleporters which use llSetRegionPos(), as well as correcting problems where objects which change appearance behind the camera ‘snapping’ into place when you rotate the camera back.

Server-side Baking

On Friday March 1st, Linden Lab unexpectedly released an updated version of the SSB project viewer (release 3.4.5.271118), which includes their approach to overcoming the problems of the Z-offset capability common to many TPVs being broken as result of the SSB code. The new approach, which I was able to outline when it “launched”, introduces an additional shape slider into the Edit Shape floater; as such, the ease-of-use of the approach, particularly for those who may swap between different avatar shapes (e.g. “normal” and petite) is very questionable.

The new "Hover" option in the Edit Shape panel for adjusting avatar height offsets in the Sunshine project viewer. Not the most elegant solution
The new “Hover” option in the Edit Shape panel for adjusting avatar height offsets in the Sunshine project viewer. Not the most elegant solution

Continue reading “SL project update: week 9 (2): servers, HTTP, SSB” →

Linden Lab offer z-offset fix for Server-side Baking

Posted on by Inara Pey

Update March 4th: The main viewer download links on the Sunshine wiki page now all reference the updated viewer  version (3.4.5.271118).

Update March 2nd: Just as a point of clarification, the update discussed here is not currently linked-to from the Sunshine wiki page. To obtain a version of the viewer with the updates, you will need to download version 3.4.5.271118 of the viewer (link repeated here for ease-of-refernce).

As I recently covered, a problem has emerged with Server-side Baking in that it “breaks” the Z-offset capability found in the majority of third-party viewers.

The Z-offset allows the vertical height of an avatar above the ground to be adjusted, such that sits and kneels don’t leave the avatar apparently floating in the air, and which allow those with very tall / giant avatars or very small / petite avatars and those wearing full body mesh to similarly adjust their vertical placement relative to the ground / floor.

The problem was reported to Nyx in week 8, and SUN-38 was subsequently raised by Henri Beauchamp on February 24th to officially log the matter.

On March 1st, Linden Lab issued an update to the Server-side Baking project viewer (release 3.4.5.271118) which is an attempt to address the issue.

The new capability is referred to as SH-3909 Support avatar height offset and is described as, “Adding a new visual param that allows users to manually adjust an offset for how far off the ground (+ or -) their avatar’s root bone is.Supports the +-2m range people are used to adjusting in their viewers, but new implementation should support server-generated appearances.”

It appears within the viewer as a new slider in the Body section of the Edit Shape floater, called “Hover”.

The new "Hover" floater
The new “Hover” option in the Edit Shape floater’s Body tab

Moving the slider to the right or increasing the displayed value will move your avatar upwards, much as increasing the Z-offset value in a TPV will. Moving the slider to the left or decreasing the displayed value will move your avatar down. As with all the shape sliders, any changes must be saved prior to exiting the editor, in order to be persistent beyond editing.

The slider offers a huge range of height adjustment compared to the z-offset slider in the likes of Firestorm, and is somewhat less accurate – with most TPV Z-offset options, height above ground can be precisely adjusted to 2 decimal points, whereas the Edit Shape floater only allows whole numbers in the range 0-99.

The "Hover" option presents a huge range of vertical motion when adjusting
The “Hover” option presents a huge range of vertical motion when adjusting, which should accommodate the both the tallest avatars …

The vertical range of movement can be considerable, and lead to some interesting results when saved – your avatar can currently disappear entirely underground, for example. Also, adjustment made using the slider are not apparent in viewers which do not have the SSB code – something which shouldn’t be a major problem, given the need for people to be using SSB-enabled viewers once the server-side code starting deploying to the main grid anyway.

What might be of greater concern, however, is the fact that the control has been incorporated into the Edit Shape options means that it cannot be used on No Modify shapes, which could leave those using such shapes still feeling aggrieved if they are impacted by the height offset problems resulting from SSB.

...and the shortest.
…and the shortest.

It’s an interesting approach to solving the problem – and it would appear that LL consider the matter now resolved, Nyx Linden having issued an e-mail to the opensource dev list which reads in part:

Added a new parameter to shapes to replace the viewer-side height offset. Since it is stored in a wearable, the new back-end can read and use the value. Will send an email to third-party devs later today to let them know to pick up the patch.

Marking SUN-38 as resolved.

Given that earlier in the week – at the Content Creation User Group meeting on Monday February 25th, where the subject of SUN-38 was raised, Nyx commented, “It hasn’t escaped our notice. We’re considering a couple different approaches … we’re considering a few different options. Suggestions appreciated, but we haven’t officially settled on an approach we’re going to commit to publicly just yet”, it will be interesting to see the response is to this particular fix.

With thanks to Latif Khalifa, who both provided me with news of the arrival of this update, and provided the necessary links for me to have a play.

Lab updates on recent improvements – no date for materials processing

Posted on by Inara Pey

Linden Lab issued one of their (increasingly rare) blog updates on ongoing work with Second Life. The updates comes on the heels of the release of CHUI, the Communications Hub User Interface, which reached LL’s development and beta viewers on the 26th and 27th February respectively, and which I’ve briefly overviewed. Until now, the only official notice of CHUI’s arrival had been via a forum post which hasn’t been entirely visible, so the blog update include Torley Linden’s informative YouTube video on the release.

The update also references the e-mail preference changes made to the Marketplace at the start of February, as well as passing comment on region crossings, noting:

We have made several improvements to region crossing that allow a smoother transition between regions, instead of the jerky transition some users experienced in the past. This change also reduces the rate of teleport failure rate. This went out the full grid on January 25, 2013. Since that date, the number of reported teleport failures has dropped by 91%.

While teleport failures may have been reduced, many are still seeing continued issues with vehicle crossings …

The Cocoa project for the Mac builds of the viewer, which I made mention of in week 8, and offers a link to the Cocoa Project viewer for Mac users.

Finally, the post looks ahead to upcoming features and updates – but sadly, only makes passing mention of the materials processing project. One can hope that as CHUI is now in the beta viewer and there was, s of week 8, apparently only one remaining issue with materials to be dealt with, a project viewer will finally be appearing sooner rather than later …

Related Links

CHUI reaches the SL beta viewer

Posted on by Inara Pey


CHUI, the Communications Hub User Interface has taken two major steps towards official release, having been integrated into both the SL development and beta viewers.

The release of the SL development viewer containing CHUI came on February 26th (3.5.1.270826). This was followed 24 hours later with a beta viewer release on the 27th February, again containing the CHUI code (3.5.0.270825). Both of these releases see the SL beta and development viewers move to the 3.5 code base.

As well as CHUI’s new conversational and chat log floaters, which I previewed a while back – although it has had a number of changes since then – the viewer brings a number of changes to the overall way in which user communications are handled by the viewer, including a new set of chat preference options for handling incoming messages and notifications.

The most immediate change with CHUI is the conversations floater, which may open automatically as the viewer is started if you have received offline IM or are receiving incoming messages from HUDs, etc., while logging in.

Conversations Floater

For those who have been using TPVs as their primary viewers, the updated CHUI Conversations floater will appear very familiar, as it gathers IM windows and Local Chat into the same panel. On the left is a vertical tab display which will list all open conversations, whether individual IMs or group chats, and which includes four buttons. On the right is the actual conversation window, which has six buttons associated with it, not all of which many be active at all times (the first three are automatically disabled in local chat, for example).

CHUI Conversations floater
CHUI Conversations floater

These buttons put all of the most common controls required for text / voice conversations within the floater itself, providing it with considerable power and ease-of-use. The chat window display options, of example, allow you to switch quickly between displaying chat headers (the little icon bars within the conversation) or removing them (so that just names and text are displayed) and whether or not to show the time, or even the name of the other person in one-to-one IM conversations.

As noted in my original preview of CHUI, the minimise buttons on the floater are particularly useful, as they offer a number of ways in which the amount of screen space is taken up by the floater. The buttons can be used individually or together, to radically reduce the amount of space the floater takes up.

CHUI: The new conversations floater in three display modes - open, collapsed, & minimised (image uses the CHUI project viewer)
CHUI: The new conversations floater in three display modes – open, collapsed, & minimised (image uses the CHUI project viewer)

Continue reading “CHUI reaches the SL beta viewer” →

SL project news 9 (1): servers, SSB, materials and Aditi

Posted on by Inara Pey

Deployments for Week 9

It’s a “lightweight” week for deployments, with all channels receiving one of two maintenance packages.

Server Life Server (Main) Channel

Region restart notifications: the "old" stayle (top), and the "new" style (bottom)
Region restart notifications: the “old” style (top), and the “new” style (bottom)

On Tuesday February 26th, the Second Life Server (SLS / Main channel) received the server maintenance project which was on all three RC channels last week.  This project has miscellaneous bug fixes, along with an impoved restart notification (which will only be apparent when this new version restarts for the next update) – see the image on the right.

While this is much better than the previous notification, it does suffer from the fact it will still fade from the viewer’s window and become a chiclet whether or not the OK button is clicked – and thus can still be missed if attention is not on the screen when it appears. To help avoid this, it is possible to set a sound for the alert using the Debug Setting UISndAlert, which requires the UUID of the sound, which coule be one you’ve uploaded to inventory yourself (Firestorm additionally has UISndRegionRestart, which can be set through Debug Settings or Preferences > Sound & Media > UI Sounds 2).

This release  means the until the RC channel deployments take place (see below), almost the entire grid is running the same server code – the only exceptions being a few “special” regions (such as the Linden Realms regions) – release notes.

Release Candidate Channels

On Wednesday February 27th, all three Release Candidate channels should receive a new server maintenance package which includes a fix for a crash mode – release notes (BlueSteel).

As always, there is a forum thread for discussing the deployments.

Server-side Baking

Following-on from his initial feedback given at the TPV Developer meeting on Friday 22nd February, Nyx Linden gave a further update on the recent Sever-side Baking (SSB) pile-on / load test when chairing the Content Creation User Group meeting on Monday 25th February

Thanks all for everyone who helped out with the pile-on test of server appearance last Thursday. The results tended to be that when the system worked, it was nice and speedy, however there were a number of issues that prevented it from working for everyone all the time. We got a good bit of data on the bugs we knew were there as well as a couple new ones. we’ve been crunching on the results and are starting to attack the issues, so it was definitely successful in achieving what we wanted: more data :). There will be future rounds, so thanks in advance for anyone who comes back to help us test again.

Z-offset Issue and SUN-38

As noted in the comments following my quick SSB test using currently available TPVs with SSB enabled, there is an issue with the “Z-offset” capability common to many third-party viewers, which allows the vertical height of an avatar above the ground to be adjusted, such that sits and kneels don’t leave the avatar apparently floating in the air, and which allow those with very tall / giant avatars or very small / petite avatars and those wearing full body mesh to similarly adjust their vertical placement relative to the ground / floor.

The problem was reported to Nyx in week 8, and SUN-38 was subsequently raised by Henri Beauchamp on February 24th to officially log the matter. Commenting on the problem during Content Creation meeting, Nyx Linden stated. “It hasn’t escaped our notice. We’re considering a couple different approaches … we’re considering a few different options. Suggestions appreciated, but we haven’t officially settled on an approach we’re going to commit to publicly just yet.” He also suggested that any questions on the subject be asked again next week, presumably by which time LL will have had time to consider the problem in detail, and hopefully consult with TPV developers.

Interest List Updates

Andrew Linden is continuing to work on the interest list code, with more refinements to come, as well as looking at a number of bug fixes. The updates about to go to LL’s QA include changes which should make scenery load faster  / more correctly when first logging-in to SL or teleporting to a region.

Aero Pines Park
Future updates to the interest list code should see scenery in your world view rezzing a lot faster

Continue reading “SL project news 9 (1): servers, SSB, materials and Aditi” →

Playing with SSB and viewers (quick test)

Posted on by Inara Pey

Update February 24th: Henri Beauchamp has filed a SUN JIRA on the Z-offset issue mentioned in comments following this article. Z-offset is an opton found in many TPVs which allows the vertical height at which an avatar stands / kneels / sits / lays to be adjusted through the viewer, allowing users to compensate for their avatars appearing to float in mid-air. The SSB code effectively “breaks” this capability. The JIRA description carries a comprehensive description of the issue for those unfamiliar with the problem.

Update, February 23rd: The Catznip team (which includes Kitty Barnett, have added a post to their blog on the subject of RLVa and SSB. Be sure to read it! 

Following the recent Server-side Baking (SSB) pile-on / load test, I took a little time out to try-out the various viewer versions which are starting to appear which provide SSB support. This was not intended to be an extensive break test or anything – just something to sate my own curiosity on a number of points.

As such, the tests I conducted were simple, and as they were performed on Aditi, they may have been influenced by some of the inventory issues being experienced there. For the tests, I used my main account, and my CTA – Crash Test Alt, which routinely gets used when testing experimental viewers, etc.

Testing covered the Cool VL experimental branch, Singularity Alpha release with SSB support and Radegast 2.8. Throughout the tests, my CTA was running the official Sunshine (SSB) project viewer 3.4.5.270409. Testing did not include Lumiya, which has SSB support implemented. The reason for this is that I remain unable to log-in to Aditi with Lumiya.

I started with a couple of baseline tests to remind people of what is going to happen once SSB is deployed to the main grid.

The three faces of SSB:
The three faces of SSB:On the left, what is seen when running a viewer which does not support SSB: the viewer user looks fine, but everyone else is a grey ghost. In the centre, what is seen when looking at someone who is using a viewer which does not support SSB: they are a cloud. Right: what is seen when both parties are using a viewer with SSB support: properly rendered and dressed avatars (remember: SSB does not affect prims / sculpts / mesh, hence why these render OK in the non-SSB viewer)

Following this, I switched to using Singularity first and then Cool VL.Results wer as expected – both accurately rendered outfits and outfit updates without any significant issues.

SSB on Singularity:
SSB on Singularity: Top: as I render in Singularity with SSB, as seen by myself (l) and with the official SSB viewer (r). Bottom: as I appear after an outfit change to both myself in Singularity (l) and the official SSB viewer (r).

Testing Radegast 2.8 also generated the expected results: outfits rendered correctly in both the Radegast 3D viewer, and in the SSB viewer, as did any outfit changes made via Radegast. Furthermore, and as expected, outfit changes made using one viewer were accurately reflected when logging into another viewer (so outfit changes made in Singularity were accurately rendered by Radegast, for example).The only issue I actually encountered was that footwear would not render correctly – which is not an SSB issue.

baking-rad
Baking on Radegast: (top) outfit changes on an SSB-enabled region render correctly in Radegast and (bottom) are also correctly rendered in other SSB-enabled viewers

SSB and RLVa

While carrying out these tests, I also took a look at RLVa on SSB, and confess to not finding any obvious issues when using Singularity or Cool VL (which uses RLV). All RLV/RLVa options functioned as expected:

  • Items “locked” as non-detachable remained undetachable until “unlocked”
  • Restrictions applied through RLV/a all functioned as expected (e.g. map restrictions prevented access to the World or Mini-Map; inventory denial prevented inventory access, etc.)
  • Remote access to #RLV Shared Folders worked as expected (i.e. remote changes of outfit worked and were accurately rendered)
  • Remote (HUD-based) access between avatars worked as expected
  • Control zone restrictions applied / released as anticipated.

This does not necessarily mean that RLVa is not “broken”. I actually have no idea if the Cool VL experimental or Singularity Alpha contain specific updates for RLV/RLVa outside of any work Kitty Barnett may be undertaking for RLVa and SSB.Aslo, just because the basic functionality of RLVa appears unaffected by SSB does not means that there are deeper, more subtle issues which need to be addressed in order to ensure all of RLVa continues to function correctly under SSB.

Summary

SSB is beginning to find its way into TPVs and appears to be working well – which is not to say that there are not bugs and issues still to be resolved with the service as a whole. Doubtless, we’ll find out more on this as LL continue to analyse the results of the initial pile-on test, and further tests are undertaken in the future. As a result of this quick-and-dirty play with the service over a number of viewers, I’m certainly curious to know if some of the issues encountered during the pile-on / load test (such as a noticeable slow-down in the time needed for outfits to render after a change) might be indicative that the system still needs tweaking in order to handle larger numbers of outfit changes, rather than all the problems being related to other issues on Aditi itself.

In terms of potential RLVa issues, I draw no conclusions; as mentioned above, the fact that the most obvious RLVa functions worked OK for me is not to say RLVa and SSB are without issues; there is much which goes on “under the hood” with RLVa which could very well be affected by the arrival of SSB which requires code refactoring but which does not result in outright / obvious breakages.

If you’d like to have a play with SSB for yourself, use the links below.

Related Links