Tag: SL Viewer

SL projects update 19 (3): server, pathfinding, materials & more

Posted on by Inara Pey

Server Deployments – Week 19

The week 19 server deployments went ahead as scheduled and as outlined in an earlier part of this report, to wit:

SLS (Main) Channel

On Tuesday May 7th, the Main channel received the maintenance package which has been running on Magnum. This project brings some new minor features to LSL, and fixes some crash modes and well as additional LSL HTTP support, as well as the previously rolled-back new AO capabilities.

In addition, this package included an additional update which was not documented in the release notes until after the deployment had been made: “Fixed a bug: ‘Orientation data for landing point is disregarded during teleport’.

This fix means that when teleporting to a place which has a defined landing point, you will arrive facing the direct determined by that landing point, rather than arbitrarily facing east. To complement this fix, there is an upcoming viewer update which will show the heading of a parcel’s landing point on the map – but no details on when that update is liable to appear.

Pointing out the fix at the Server Beta meeting, Maestro Linden added, “There’s an exception for cases in which if you have a beacon set, where you’ll face the beacon position instead. I think this is a bug.”

This lead to a discussion on the exception, in which the wider consensus appeared to be that having an avatar facing the beacon (when set) on arrival might be the preferable to automatically having the avatar facing the direction imposed by the landing point. However, this would mean people using a beacon would arrive at the landing point facing a direction other than the land owner intended, prompting Voidpointer Linden to comment, “Yeah, seems like we would only want to have you face the beacon when going to a landing point if it’s in the same region, maybe?”

It’s currently unclear as to whether the feedback from the meeting will mean this exception is allowed to continue, or whether there will be further tweaking with the landing point code in the future,

Release Candidate Channels

On Wednesday May 8th, all three Release Candidate channels (BlueSteel, LeTigre and Magnum) received server-side support for experience permissions which was running on BlueSteel in week 18. The update, as usual, will also include the changes which are going to the Main channel on May 7th, which included the new AO capabilities – release notes (BlueSteel).

SL Viewer Updates

Beta Viewer

The beta viewer as we currently know it received what might by its final update prior to the new viewer release processing coming into effect. Version 3.5.2.275565 was released on May 9th, and the release notes provide details on changes.

Materials Processing Project Viewer

A new version of the Materials Processing viewer – 3.5.2.275470 – was released on May 8th, based on the 3.5.2 viewer code. The release also appears to include a fix for MATBUG-38 (“Material with normal map but no specular map is always specular with no adjustment possible”), and which I’d described in week 18.

MATBUG-38. appears to have been fixed in Material Processing project viewer 3.5.2
MATBUG-38. appears to have been fixed in Material Processing project viewer 3.5.2.275470, May 8th 2013.

The release may also include a fix for MATBUG-16 (Changing one material, or setting causes another material texture to be lost), which I’d previously noted in week 16.

Whether this latter issue is fixed is hard to judge, as it was somewhat intermittent to start with. and there have been reports that it was already less noticeable with the previous release of the viewer. However, at the time of writing, the bugs remain marked as Unresolved / Incomplete in the public JIRA (but could have been updated in LL’s internal JIRA).

I can say that I’ve so far been unable to reproduce either bug using the new release, having carried out a number of individual tests.

Continue reading “SL projects update 19 (3): server, pathfinding, materials & more” →

SL projects update week 19 (1): server releases, SSB/A, materials

Posted on by Inara Pey

Server Deployments Week 19

Second Life Server (Main) Channel

On Tuesday May 7th, the Main channel should receive the maintenance package which has been running on Magnum. This project brings some new minor features to LSL, and fixes some crash modes and well as additional LSL HTTP support – release notes.

 Release Candidate Channels

On Wednesday May 8th, all three Release Candidate channels (BlueSteel, LeTigre and Magnum) should receive server-side support for experience permissions which was running on BlueSteel in week 18. The update, as usual, will also include the changes which are going to the Main channel on May 7th – release notes (BlueSteel).

I was somewhat confused by the release notes for 13.05.04.275247 package, as on the one hand they suggested the new LSL AO capabilities would be absent from Agni following the RC deployments (“Changes since 13.04.19.274370 … Removed changes introduced by Second Life Server 13.04.12.273874”), while on the other, the line originally following this comment suggested otherwise.

I contacted Maestro for clarification, and he confirmed that the AO capabilities will be present on the RC channels following the deployment, and that the release notes have been revised to prevent any further confusion.

As always, there is a discussion thread in the forums for the deployments.

Server-Side Baking / Appearance

SSB/A - further viewer-side updates expected. No published timeline on testing as yet
SSB/A – further viewer-side updates expected. No published timeline on testing as yet

As noted in the last part of my week 18 report, there will be at least update to the viewer-side SSB/A code, which Nyx referred to at the Content Creation meeting on Monday May 6th as being, “Mostly reliability and some related polishing”. From the TPV Developer meeting on Friday May 3rd, the release will be addressing some additional ways in which baking can fail as well as addressing stability in general, although as Nyx noted at the TPV Developer meeting, “Nothing that we know of right now that would be mandatory for the system to work.”

The question of when constrained testing would commence again came up at the Content Creation meeting. This will see a number of regions across the main grid have the server code for SSB/A enabled in order for LL to carry out further load tests on the system ahead of the “switch being thrown” and SSB/A enabled across the entire grid. All Nyx would say on the matter is, “We don’t have a timeline to announce today.”

Whether this means there will be a formal announcement when testing does commence, remains to be seen. However, the Lab is still intending to make a formal announcement on SSB/A, mostly likely via a blog post, ahead of the service being enabled across the grid in the hope of further communicating the change, and the need to upgrade to an SSB/A-capable viewer to as many users as possible.

Outfit Changes

During her tests with SSB/A on Aditi, Kitty Barnett noted that when changing a wearable or reordering the layers of an outfit, the updated bakes could take a while to come through. Concern that this might be the case when SSB/A is enabled on the main grid prompted her to ask:

For server-side baking, would there be any issue with turning on local baking to make getting dressed more pleasant? it could be Aditi, but [when] wearing something it takes a very long time before the server bake comes through, particularly reordering clothing or taking something off … I actually just turn local baking on as soon as there’s a wearable change and it seems to be working nicely and turns itself off when the server bake comes through… but I was wondering if that would cause any undesirable issues [if the same was done on Agni]?

Local bakes already occur when using the Editing Appearance options, so Kitty’s question appears to be more broadly aimed at general outfit changes (people simply swapping individual clothing layers directly from inventory, and (possibly) using the capability in some TPVs to re-order clothing layers directly from inventory, rather than going via the appearance editor).

Responding to the question, Nyx said:

I’m not certain how you’re turning on local baking, and can’t really speak to whether there are undesirable behaviors as a result. The code to switch between the different types of bakes is rather complex and sometimes fragile, and bugs in that area can be subtle … Proceed with caution and best of luck :). Report back if it works well (or if you find interesting bugs!)

Whether such a delay will be noticeable enough to be an irritant on Agni is hard to say as we’ve yet to see the server code up and running on the main grid, so it’ll be interesting to see what further tests on Kitty’s part reveal as testing commences.

Continue reading “SL projects update week 19 (1): server releases, SSB/A, materials” →

SL projects update 18 (4): servers, viewer release process, group bans and bits

Posted on by Inara Pey

Server Deployments – Week 18

As reported in the first part of this update, the SLS Main channel was rolled back to release 13.04.05.273580, as a result of a widespread performance issue.  This unfortunately saw the removal of the new LSL animation capabilities from the channel.

The issue itself is related to problems with regions locating their neighbours. “The sim were hitting the [region presence lookup] service too hard, causing stability problems.” Maestro Linden said at the Server Beta meeting on Thursday May 2nd. Release notes.

In the original notes for this week’s deployments, BlueSteel and LeTigre were scheduled to receive the same deployment package. However, this was subsequently changed so that:

  • BlueSteel received the same reversions as the Main channel due to the performance issue between neighbouring regions, but also received updates for the Experience Keys project as originally planned. Release notes.
  • LeTigre received the same code that was on the main channel in week 17, the only difference being that it fixes the performance issue that caused the Main channel to be rolled back this week.  Release notes.

Maestro described the deployment of the fix for region lookup issues as the “conservative option”, rather than deploying the fix to multiple Release Channels, “In case the changes from the other two channels have their own problems.”

Magnum received the package originally scheduled for it, described as bringing some new minor features to LSL, and fixes some crash modes as well as the fix for grid performance issue, and fixing an issue in which llDialog() messages sent to the object owner could be incorrectly throttled. Release notes.

The hope is that if all is well with the Magnum update, it is liable to be deployed to the Main channel in week 19.

SL Viewer Updates

Beta Viewer Release

A new beta version of the viewer emerged on May 2nd, using the 3.5.2 code (3.5.2.275087). This release includes the update from FMOD to FMOD Ex, and well as a number of other maintenance and other fixes as specified in the release notes.  However, it does not include the anticipated Vivox updates to improve SL Voice. These will be coming along at a later date.

The current plan is for this release to remain in the beta channel for at least one further update prior to it appearing in the release channel. As such, it is unlikely to be in the release viewer until late in week 19 or in week 20. Once it has appeared in the release viewer, LL will probably deploy the new viewer release process, and the beta channel will cease being used.

Viewer Release Process

Oz Linden
Oz Linden

As previously reported, the viewer release process will be changing in the coming weeks. As a part of this, the development viewer channel has already been deprecated; however it will still be a while before the new process is put into place, as further infrastructure changes are still required on LL’s part.

Concerns have been raised by TPV developers about a side-effect of the new process potentially being that the rate at which code becomes available to them may slow down, thus causing them to “fall behind” the LL viewer in terms of new functionality or capabilities. Stressing that this is not the intent, Oz Linden described process in further detail at the TPV Developer meeting, indicating that under the new system:

  • Viewer projects will each have their own repositories, which will be made available to TPVs (and others) once it is deemed they are “safe to share” as a project or “beta” viewer
    • While it has yet to be formally decided within LL, and may take a little time to work up to, critical bug fixes are liable to have their own repositories, from where they can be merged into other viewers
  • Users will be able to pick which beta / project viewer(s) they download from the Alternate Viewer wiki page without being tied to any specific update route (so you can download and run as many project / beta viewers as you like)
  • Once a project is believed to be of release quality, it will be put into a release candidate, built on the current viewer release code and released to a target number of users (as chosen by LL), alongside other release candidates being used by other users
  • When a user receives a release candidate viewer via the download page, the updates they receive will be offered on the basis of the release candidate they are currently running (for example, if a user is running the Materials RC viewer, they won’t be offered updates from, say, the SSB/A RC viewer)
  • After some period of time, and when LL have looked at the results, one of the release candidates will be promoted to the default download (without the viewer having to be rebuilt) and will be available on the main download page
  • The remaining viewer projects (at least those at release candidate status) will then be merged with the newly-released viewer code, and re-test and issue a further release candidate, which may in turn be selected as the next candidate for promotion to the default download.

He added that in terms of TPV’s concerns over code being made available to them, the level of co-operation which has been evident in the Sunshine project (SSB/A) has “not gone unnoticed” within LL’s management, and that the team involved has received a lot of kudos for the way they have handled interaction with TPVs. As such, it is likely that the Lab will endeavour to build on this going forward.

Continue reading “SL projects update 18 (4): servers, viewer release process, group bans and bits” →

SL projects update 18 (3): more on the viewer

Posted on by Inara Pey

Viewer Release Process

Following-on from the announcement of a new process for viewer releases Oz Linden provided more information on the process as it will operate going forward during the Open-Dev meeting on Wednesday May 2nd, and gave a clarification on my original post after I’d mistakenly referred to individual viewer “release candidate channels”, rather than more correctly, “release candidates”. His comment in full reads:

Oz Linden
Oz Linden

The release candidates will be updates in the regular release channel, not separate candidate channels. The candidates will be in a named “cohort” within the channel, but the cohort name is not built into the viewer the way a channel name is, which means we will be able to move a candidate from its named cohort to the default without rebuilding it – the build we test will be exactly what we release. Candidates will be indistinguishable from the default release viewer (the one on the main download page) except for the version number and the new features.

The new process also means that officially, individual viewers will no longer be referred to by specific project channel names (such as CHUI, Materials Processing, etc.). Instead, they’ll be referred to by their full 4-part number (i.e. 3.5.1.274847 rather than the “Materials project viewer”).  This also means there is likely to be at least one update to the Bug Tracker so that the Environment box in the form will no longer allow a report to be submitted until viewer channel and version number have been recorded.

As a result of these changes, Oz indicated that the development viewer channel has already been depreciated, and that the beta channel, as mentioned in my original piece will be depreciated as the Lab switches over to the new system.  When a candidate viewer is ready for public consumption, it will appear on the  Alternate Viewers wiki page where it can be downloaded.

I’ll be making changes to my Viewer Round-up Page to match the new system as it comes into play.

Current SL Viewer Status Update

In the meantime, and in the lead-up to the new release process, there is expected to be a further beta viewer release (3.5.2 code), which will include the FMOD Ex updates in it, and for which Oz extended thanks to the Singularity team for their work.

The Mac Cocoa project is a little stalled. This is because, to quote Oz, “We’ve been stealing people [TPV devs] from Cocoa to get Materials done. The good news is that it’s working, we’re really knocking down bugs at a steady clip.”

The mesh deformer also remains stalled. This is again due to manpower issues but this time internal to LL. However, Oz again wanted to reassure people, stating of the deformer, “There are things I’ve given up on at this job, but that isn’t one of them.” Sadly, his plate is also full with the Materials project at the moment, together with things like the new viewer release process.

Related Links

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 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” →