Category: SL Tech

LL announce revamp to the viewer release process

Posted on by Inara Pey

secondlifeLinden Lab have announced a revamp to the way in which they will be releasing viewer updates in future.

Currently, the process for the majority of viewer changes is that they go through a progression – generally being seen first in the development channel (or sometimes prior to that in a project viewer), before moving through to the beat viewer (where updates go through what is effectively a final validation  / user test) prior to being adopted into the SL release viewer.

This system has generally worked, but can cause problems, particularly when there is a lot going on in terms of projects and updates, and things end up being “queued up” for the release (as is currently the case, where CHUI, Server-side Baking / Appearance, and a host of other updates / fixes are concerned all being “queued” awaiting their turn in the beta viewer release channel.

Another problem – as seen at the end of last year – can be that should a significant issue occur within the beta viewer code, it can completely block further viewer releases until such time as the problem can be tracked down and effectively fixed. Last year this meant that viewer updates were effectively stalled for around a two month period while LL sought to isolate and fix the problem.

To try to overcome any bottlenecks which might occur with viewer releases, the Lab is adopting a similar process to that used by the server-side code release mechanism, as the blog post explains:

We’ll release more than one new version at the same time in parallel to subsets of users for final validation, and then promote the most important of the best of those to the default Release Viewer when that testing shows it to be ready.

If a development project wants to put out an early version for testing prior to it being ready for the Release channel, a channel specific to that project (either ‘Project <project>’ for very early versions, or ‘Beta <project>’ for more mature ones) will be created, just like we do today. These will be shut down when the project is ready to move to final testing in the Release channel, and users in the early project test channels will automatically be upgraded to the corresponding Release candidate version.

This means that in the coming weeks, we’ll start to see different versions of the viewer start to appear in parallel in their own “release candidate” channels, and people will be able to choose which versions they want to download and try-out. Once it is deemed the code from a specific “release candidate” viewer is ready for release, it will be integrated into the SL viewer and made available to the community through the established mechanism. As such, the beta viewer channel will be vanishing in the near future.

Quite how well different flavours of the viewer will run together on a single computer for those who want to try-out more than one upcoming release remains to be seen. Generally, different versions of the SL viewer tend to play nicely together. However, as was seen with the 3.4 and 3.5 code base changes problems can occur. In that particularly instance, running a development or beta viewer using the 3.5 code and then swapping back to the SL release viewer on the 3.4 code resulted in all the toolbar buttons vanishing from the latter.

The overall hope is that this change will mean that specific features and updates will reach the release version of the viewer at a greater pace than can be achieved with the current process, which in turn should not only smooth the path for new capabilities and features to reach users quicker (allowing for the inevitable bugs and hiccups such projects tend to encounter anyway), but perhaps also help in get fixes for significant issues and problems out to the mainstream viewer.

SL projects update week 18 (2): server releases

Posted on by Inara Pey

Deployments for Week 18

The week 18 deployments make for interesting reading.

SLS Main Channel

On Tuesday April 30th, the Main channel was rolled back to release 13.04.05.273580, as a result of a widespread performance issue.

Release Candidate Channels

  • BlueSteel and LeTigre: both of these channels should remain on the Experience Keys project, but will also be reverting some changes, due to the same performance issue which is affecting the Main channel – release notes
  • Magnum: should remain on the same server maintenance project as week 17.  This project brings some new minor features to LSL, and fixes some crash modes.  This update fixes the grid performance issue, and fixes an issue in which llDialog() messages sent to the object owner could be incorrectly throttled – release notes.

The performance issue which caused the Main channel to see the re-deployment of an older release was described by Simon Linden as being related to problems with regions locating their neighbours. “The performance problem was really showing up between any one region trying to locate another on the grid … the system was actually working, but too close to the cliff for comfort.” The re-deployment means that the new LSL AO capabilities can no longer be compiled / run on any Main, BlueSteel or LeTigre regions, until the supporting code is rolled-out once more.

There is still no further detail on the Experience Keys project and whether this may / may not be more than a deployment of the Advanced Creation Tools permission system.

Interest List Update

Andrew Linden has been working on fixing a bug related to Meeroos (but which I’ve seen affecting other animals as well), which he describes as, “If you turn your camera away from a crowd of Meeroos, wait several seconds, then turn back around… the Meeroos will be updated, but not quite in the right order. So sometimes you’ll see a head move to the new position, then a fraction of a second later the rest of the body.  So I have a theoretical fix that doesn’t crash the simulator (anymore).” The fix in question has yet to be tested and QA’d, so there is no time frame for any release.

“Missing” Prims

While talking about the interest list work, Andrew answered a question on missing prims / linksets, again acknowledging it to be a viewer-side issue, before going on to say:

We think maybe it is fixed in a new viewer. But this new viewer I mention happens to be very crashy, so we haven’t opened up the source code for it yet nor have we submitted it to our QA team since they’ll just crash …  This is the viewer that goes with our new interest list changes which I mentioned a few weeks ago and people were wondering when the code would be put up on a public repo.

"Missing" prims - viewer-side fix possibly on the way?
“Missing” prims – viewer-side fix possibly on the way?

So a viewer-side fix, along with viewer-side interest list updates, looks to be somewhere on the horizon.

Region Crossings

There have been a number of reports of region crossings worsening again after seeing a significant improvement with the release of the fix for BUG-1814. A common issue has been avatars becoming “snagged” at a region boundary while the vehicle they were travelling in continuing on its way, sometimes being returned to their Lost and Found folder from a location two or three regions beyond where the avatar became stuck. Both prim/sculpt and mesh vehicles are affected when the problem occurs, and it is an issue which had been encountered prior to the widespread deployment of the BUG-1814 fix.

Getting "snagged" at a region crossing while my aircraft flew on was a problem I encountered several times over Blake Sea early in April. The problem has again manifested itself to many, and I've again encountered it while flying my mesh Spitfire Mark IX
Getting “snagged” at a region crossing while my aircraft flew on was a problem I encountered several times over Blake Sea early in April. The problem has again manifested itself to many, and I’ve again encountered it while flying my mesh Spitfire Mark IX

I’d actually encountered the problem on April 4th during a series of region crossing tests, but the problem no longer appeared to be occurring by the middle of the month.

The issue of region crossings was raised at the Simulator Meeting on Tuesday May 30th, but the discussion was dominated by the problems being encountered by one particular type of train. In commenting more generally on region crossings, Andrew Linden said, “I agree that region crossing on vehicles needs more work. I can’t promise that I’ll be working on that as soon as I’m done with this interest list project, but I’ll try to bring it up in the next ‘what do we work on next’ brainstorm that we have.”

SL projects update week 18 (1): viewer, SSB/A and materials

Posted on by Inara Pey

Server-side Baking / Appearance

The viewer-side SSB/A code continued in the SL beta viewer with a release on April 24th (3.5.1.274588). However, the crash rates from that version were sufficiently low for the go-ahead to be given for the deployment of the SL viewer with the SSB/A code incorporated, which reached public release on April 30th (3.5.1.274821).

SSB/A in the SL release viewer: I'm running the SSB/A-enabled SL release viewer and can see both myself and my alt (running SSB/A-enabled Firestorm) rendered correctly, and she can see fully rendered.
SSB/A in the SL release viewer: I’m running the SSB/A-enabled SL release viewer and can see both myself and my alt (running SSB/A-enabled Firestorm) rendered correctly, and she can see fully rendered.

This now means that the following viewers and clients are, at the time of writing, now SSB/A capable:

  • SL viewer 3.5.1.274821 (release)
  • Firestorm 4.4.0.33270 (release)
  • Kokua 3.5.2.27969 (development)
  • Nirans 2.2.0.2692 (alpha test)
  • Cool VL 1.26.8.2 (stable release)
  • Kirstens S19.1.19.4 (unsupported)
  • Singularity 1.8.0.4114 (release)
  • Lumiya 2.4.4 (release)
  • Metabolt version 0.9.66.0 (Beta)
  • Radegast 2.12 (release)

The remaining major players for Second Life – Catznip, Dolphin and Exodus will doubtless have SSB/A versions out in the very near future.

Z-offset

Cinder Roxley is working on an alternate approach to the issue of the z-offset and is meeting with some success. However, there is still a problem with the distance offset being inconsistently reported between the user’s viewer and by other viewers (so the avatar may appear at a different height above ground / an object when seen by others in comparison to how they see their own height. Cinder is continuing to work on the problem. If she is successful, the code will doubtless be made available to all TPVs should they wish to adopt it.

Current Outfit Folder Corruption

I reported on this issue in week 17, wherein a Current Outfit Folder (COF) corruption can leave a user unable to log-in to SL and – unless they have a Premium account – beyond official help. This has been something of a longstanding issue, as per JIRA SVC-7653, and has an associated work-around. The concern here is that the workaround will no longer work once SSB/A is enabled server-side.

Commenting on the situation, Nyx Linden said, “we’re looking into a number of fixes around COF for followup releases,” before going on, “Yep, we have people looking at this. Please do continue to let us know as you see cases come up. I’ll sync up with our engineers looking at this and make sure that we have these cases covered.”

SUN-69

Whirly Fizzle recently reported an issue arising from the recent SSB/A code – removing any worn item from avatar results in all temp attachments being taken off (see JIRA SUN-69). This problem occurs whether or not an avatar is on SSB/A regions. It was first noted in the SL development and beta viewers, but appears common to all viewers with the SSB/A code, including the new release version of the viewer referred to above (3.5.1.274821).

Server-side Deployment

With the arrival of the viewer SSB/A code into the SL release viewer, deployment of the server-side code is liable to commence on the main grid. As previously noted in these updates, the plan is for a “constrained” number of regions on Agni to be SSB/A-enabled in order to load test the system. It appears likely that these regions will not be a part of the normal Release Candidate channels (although this is not absolutely clear).

The purpose of this action will be to further stress / load test the new server-side baking service and (hopefully) ensure there is sufficient hardware deployed to support the capability and that there are no unexpected issues arising from large numbers of people starting to the use the system.

Continue reading “SL projects update week 18 (1): viewer, SSB/A and materials” →

Viewer release summary 2013: week 17

Posted on by Inara Pey

This summary is published every Monday and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:

  • It is based on my Viewer Round-up Page, a list of  all Second Life viewers and clients that are in popular use (and of which I am aware) and which are recognised as adhering to the TPV Policy
  • By its nature, this summary will always be in arrears
  • The Viewer Round-up Page is updated as soon as I’m aware of any releases / changes to viewers & clients, and should be referred to for more up-to-date information as the week progresses
  • The Viewer Round-up Page also includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.  

Updates for the week ending: April 28th, 2013

Discontinued Viewers

  • Phoenix – Development and support officially ended December 31st, 2012
  • Zen – Development and support officially ended January 27th, 2013.

Related Links

Firestorm clouds

Posted on by Inara Pey

One thing I neglected to mention in my recent review of Firestorm 4.4.0 is the inclusion – by Cinder Roxley – of Vincent Nacon’s alternative cloud maps, which can be used to change / enhance the rendering windlight clouds.

The default cloud layer seen over Extropia, using the
The default cloud layer seen over Extropia, using the AnaLutetia-outdoor windlight setting and the sun adjust to around 10:00.

I’ve no excuse for this, given Cinder actually nudged me on the matter prior to the release; just blame it on me having a blonde moment…

So, what is it all about? Quite simply, Firestorm now includes additional cloud maps made by Vincent Nacon, and which Cinder has added to the Preferences > Firestorm > Windlight tab for easy selection.

The Windlight cloud options
The Windlight cloud options

This presents you with four basic cloud types – the default map, Altocumulus (a middle altitude cloud, usually characterised by globular masses or rolls in layers or patches), Cumulonimbus (the familiar towering cloud formations associated with thunderstorms) and a “Layered” map. Do note that selecting any option other than the one already in use appears to require a viewer re-start in order to take effect.

Exactly what effect these different maps will have on your in-world view is a matter of experimenting with the various available windlight settings within Firestorm (a task made easier thanks to William Weaver’s Phototools). However, they can be used to produce some stunning effects – the images here are simply to provide some form of comparison.

Extropia
Extropia seen under the same windlight setting as the first image in this article, but using the Layered cloud map.

What’s more, as Cinder indicated in her little nudge to me, you can create (or obtain) cloud maps of your own and add them to Firestorm to create your own unique cloud looks. “Drop any 8-bit grayscale tga with a power of 2 size you make or find under app_settings/windlight/clouds,” she comments, “And they’ll be automatically added to the list.”

For those wishing to try the cloud maps on other viewers, Vincent provides forum thread in which his discusses the maps and provides guidelines and caveats on their usage in viewers. Links to download the maps are also provided.

The Cumulunimbus map applied to the sky, using the same windlight setting and time of day - note the "stacking" effect visible in the formations on the right of the image
The Cumulonimbus map applied to the sky, using the same windlight setting and time of day – note the “stacking” effect visible in the formations on the right of the image, given the impression of some additional vertical height

The maps appear to be particularly well-suited to sunrise / sunset images, where the combination of sun and clouds can be particularly dramatic and result in some incredible images.

Why not have a play yourself?

With thanks to Cinder Roxley.

Related Links

SL projects report week 17 (3): server, group bans and Oculus Rift

Posted on by Inara Pey

Server Deployments – Week 17

The scheduled server channel deployments took place as planned this week.

The SLS Main channel

As previously reported, this 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 – release notes

BlueSteel and LeTigre

Both of these channels received the first part of a new experience tools project – referred to as the “Experience Keys project” in the release notes.

Interestingly, the release notes refer to BlueSteel and LeTigre receiving server release 13.04.19.274370; however, the viewer reports both of the channels running 13.04.05.273550. I contacted Maestro on this, who replied, “There was an error during the roll, so a slightly older version (which doesn’t include the changes from this week’s main channel update) was deployed.”

Not too much is known about the new Experience Keys project, although the emphasis on “new” indicates this is more than just a deployment of the outstanding permissions system for the current advanced creation / experience tools, and speculation has been running high. At the Simulator User Group meeting on Tuesday 23rd April, Simon Linden indicated he was unsure as to what he could / could not say on the matter (particularly as it appeared the documentation was still being written-up).

Commenting on the Bluesteel / LeTigre deployment at the Server Beta meeting on Thursday 25th April, Maestro Linden was also somewhat circumspect on the matter, commenting, “The team doesn’t want to announce the features yet, so I can’t give many details … some other parts need to be released for the new features to be usable. So ideally, nothing visible should change there.”

The reference to “some other parts” which need to be released for these new features may include a viewer update. Whether such an update will appear ahead of or behind the materials capabilities (still currently in a project viewer) is unclear at this point in time.

Magnum

Magnum received additional LSL support for new HTTP contents types, as document in the release notes. It also received a change to how certain message types are handled by the server, which Maestro described thus:

There’s a change to make the server smarter about how it throttles certain messaging types to prevent certain types of ‘DoS’ attacks, where a ‘bad’ object could prevent your avatar from getting llDialog notifications from other objects. All objects owned by UserA share the same throttle for sending llDialog() messages to UserB, but objects owned by anybody else would have a separate throttle pool.

This should hopefully reduce the incidences of iiDialog being used in spamming attacks which can result in the viewer either being severely slowed down or crashing altogether.

SL Viewer

The beta viewer gained a further release (3.5.1.274558) which reached public availability on April 24th, containing further CHUI and SSB/A dixes and updates, as detailed in the release notes. The development viewer also received a further release (3.5.2.27469) which also gained public availability on April 24th.

Group Bans

Baker Linden: Group Ban work coming, just not quite yet
Baker Linden: Group Ban work coming, just not quite yet

Baker Linden has started working on an update to the code for managing groups which will allow group owners / moderators to ban users who create problems (e.g. those who spam groups, people who are persistently abusive in group chat, etc.). This work is in response to JIRA VWR-29337. In my last report on this, Baker has written-up the documentation for the work and was having some other Lindens cast an eye over it.

Attending the Server Beta meeting on Thursday April 25th, Baker provided an update on his activities. “I’m still working on group bans, but I decided to fix a couple small bugs first. They both relate to searching people using the choose resident floater. They’re in the system where I’ll be adding group ban stuff, and now that I can test the changes, I can get them pushed to an RC. However, he did go on to say, “It’s going to be a while before Group ban stuff is ready.”

Second Life and Oculus Rift

There has been considerable interest in the Oculus Rift headset and its potential for use within Second Life, as reported back in week 14 and more recently. Jon Brouchoud in particular blogged on why SL would be a “killer app” for the headset, and a video I featured back in week 16 has also appeared on numerous SL blogs (hardly surprising, given it has pretty much gone viral where the Oculus Rift is concerned 🙂 ).

On Wednesday April 24th, Hamlet Au covered the fact that the Lab is already looking to integrate the headset into Second Life, and have given official confirmation, with company spokesman Peter Gray (Pete Linden) quoted as saying, “We plan to strongly support Oculus Rift. That means code, client, and server-side, to make the Oculus Rift experience excellent in Second Life.”

Continue reading “SL projects report week 17 (3): server, group bans and Oculus Rift” →