Tag: HTTP updates

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

Posted on by Inara Pey

Deployments for Week 14

SLS Main Channel

On Tuesday April 2nd, the Second Life Server (SLS or Main) channel received the interest list update which has been running on the Magnum RC channel for weeks 12-13. This includes:

  • More correct sorting when streaming objects to viewer
  • More objects are categorised as cacheable by the server (improves scene loading speed when revisiting regions)
  • Packed full ObjectUpdate data recycled for multiple viewers (optimisation of how UDP packets are built)

Additionally, the package includes fixes for the following issues:

  • BUG-1779 – Updates for objects that are out of view are delayed for a maximum of 5 seconds, at which point they will be sent
  • BUG-1795 – “Agent appears in incorrect position to other agents after being moved by a sim teleporter”
  • BUG-1814 – “No object updates from vehicles after some region crossings” – yes, the vehicle region crossing bug fix reaches the Main channel (and should be on BlueSteel and LeTigre following the RC deployments on Wednesday 3rd April).

As always, there are release notes for the deployment.

Following deployment, there have been assorted reports that:

  • Region crossings in vehicles are generally a lot better – although the BUG-1814 fix will not reach the entire grid until after the RC deployments for Wednesday 3rd April (see below). However, feedback is pretty much in line with my own Magnum tests in my Mark XI Spitfire
  • There are reports that the fix for BUG-1779 is not working in all cases – Whirly Fizzle reports that her Meeroos are still suffering the same update issue as prior to the roll-out
  • There are also reports of increased issues with prims / parts of linksets failing to rez until right-clicked upon – although there is some speculation that this might be worse for some TPVs as they may not have recent code updates from the Lab.
Prims failing to rez until right-clicked: issue more prevalent?
Prims failing to rez until right-clicked: issue more prevalent?

Release Candidate Channels

On Wednesday April 3rd, the Release Candidate (RC) channels should receive the following updates:

  • BlueSteel and LeTigre should receive the same package as week 13, which includes the new Animation Override LSL capabilities. In addition they also should receive:
    • The changes deployed to the Main channel on Tuesday April 2nd
    • A fix for BUG-2134 – “Avatar pre-jump is sporadic”
    • Release notes are available (BlueSteel link)
  • Magnum should receive Monty Linden’s new server-side HTTP updates (see below) – release notes.

SL Viewer

The Mesh Deformer project viewer was finally updated on Tuesday March 2nd with the release of version 3.5.1.273384. There are no changes to the deformer with the release – which does see the deformer code now merged with the CHUI codebase.

HTTP Updates

Monty Linden's HTTP updates should arrive on the Magnum RC on Wednesday 3rd April, assuming no last-minute hitches
Monty Linden’s HTTP updates should arrive on the Magnum RC on Wednesday 3rd April, assuming no last-minute hitches

The next stage in Monty Linden’s HTTP project should reach the Magnum RC channel on Wednesday April 2nd. these updates can be briefly summarised as:

  • More complete and more correct headers on texture and mesh fetches – these should ensure the viewer is better able to handle objects as they are downloaded to it
  • Keepalive connections for some HTTP-based services

Notes on the latter point explain that:

The behavioral change for HTTP connections marks the beginning of support for persistent (keepalive) connections. Services transiting the capabilities router, at ports 12043 and 12046, may honour a request for keepalives and keep a connection open after request completion. These services may include such activities as texture and mesh fetching, event delivery to viewer, HTTP-In for LSL scripts, asset uploads and inventory operations. Benefits from keepalives include immediate and future throughput increases and less TCP connection churn (which often disrupts consumer-grade networking equipment). The exact set of services that will see this is expected to change over time.

In other words, connectivity between the viewer and the server should be somewhat more robust and, in the case of older router models, less taxing.

Server-side Baking Avatar Z-offset

I missed the Monday Content Creation meeting on April 1st due to family commitments. However, I understand from information received that the question of avatar height offsets. The solution, as currently offered by LL, is considered to be less than optimal for all situations. In replying to the question, Nyx Linden apparently indicated that the Lab do not consider the matter fix in light of further examples having been given, and that further work in correcting matters is in-hand. Whether these further fixes address all concerns remains to be seen.

Other Items

Griefing

Griefing was once again a subject of discussion at the Simulator User Group meeting on the 2nd April. As with the last time the recent increase in mainland griefing was raised, LL are not willing to discuss specifics in terms of what they’re aiming to do. However, Simon Linden did provide more general feedback in response to questions.

Nothing new to report about griefing tools … but it is on our radar and definitely a concern … When looking at griefing problems the most serious issues and the ones that get the fastest attention is anything that can crash a region or viewer. After that there’s a broad spectrum mostly based on the level of pain and if there are things that can or can’t be done about it already. The fight has been going on since long before I joined the Lab.

During the discussion, Simon was at pains to again point out that those Lindens attending the User Group meetings are not responsible for dealing directly with griefing accounts – that is the role of the Governance team. However, he also made it clear that there are internal LL meetings where griefing is discussed, saying:

The Lindens that come here like Andrew, Kelly and myself are server developers, so we focus on features there that can help. Dealing with accounts is outside our area and the Governance people handle that … We do regularly meet and discuss what’s going on … everyone is aware of the recent increase in griefing … It’s gotten a lot worse recently. Not due to technical failures and it becoming easier, but from more griefers.

Simon also indicated that the bug which allowed objects to get stuck in limbo at the edge of a region, where they could be exploited by griefers, now has a fix in the BlueSteel and LeTigre RC channels, and that measures to help combat particle spamming are “in the pipeline”, with the hope that a project viewer will be featuring these will be available soon.

SCR-19 – Script function to return objects remains a popular choice of handling griefing objects, and Simon – purely as a brainstorming exercise asked for feedback on region controls which could be turned off / options which could help make land more “griefer-proof”. Some of the responses included:

  • Having particles require group permissions
  • Banning individuals based on their group membership. This raised questions over privacy and usefulness / effectiveness. The former as it would require a means to discover someone’s groups, even if hidden; the latter points because it would only otherwise work on a person’s active group, it would be relatively easy to circumvent (by leaving the group, if necessary)
  • Blocking object rezzing based on the creator’s name
  • Turning off public script operation over explicit banned/no access parcels, making the return time for public rezzed objects over explicit banned/no access parcels 1 minute.

Again, none of this should be taken as an indication that any of the above will be explicitly developed by LL; rather they are likely to be added to the melting-pot at the Lab and help LL better understand where user concerns lay and what directions they should consider for further technical responses to griefing issues.

Mesh Object Physics Shape

There has been a (possibly long-standing) problem with the physics shape for some mesh objects being changed unexpectedly. Lares Carter, speaking at the Simulator User Group, described it thus:

The physics shape type for mesh objects gets changed from Prim to Convex and doesn’t change back until the object is right-clicked. This only happens for linksets that contain a prim with a target omega property. Things that can trigger the change: movement changes and rezzing the object. There also seem to be other factors as it can happen for static objects too.

The issue has been reported in BUG-2147, and differs from the problem wherein some objects / parts of builds (such as floors, walls, etc.) fail to rez until clicked upon (but can be walked on, etc.), in that the mesh object can be seen and can collided with – but the physics shape is incorrect. There are reports that analysing the physics model in the mesh uploader can be used by content creators to mitigate the issue. However, this issue is now on the Lab’s radar in terms of further investigation.

 

SL projects update week 13 (2): server releases, HTTP, and viewer notes

Posted on by Inara Pey

Server Deployments Update

On Tuesday March 26th, the SLS (Main) channel received the maintenance package previously deployed to BlueSteel and LeTigre in week 12, which includes a fix for a crash mode  – release notes.

On Wednesday March 27th, the RC channels received the following packages:

  • BlueSteel and LeTigre: a new maintenance package, which includes:
  • Magnum: should receive the same update as the Main channel (i.e. the package deployed in week 12 to BlueSteeel and LeTigre), otherwise retaining the updates and fixes deployed to it in week 12 – release notes.

As usual, there is a forum discussion thread for comments / feedback on the deployments.

Some issues have been reported following the Main channel deployment, but nothing which warranted any major action on LL’s part. Some reported noticeable improvements as a result of the pathfinding update.

Week 14 Deployments

While a final decisions has yet to be made on deployments for the week commencing Monday April 1st, Maestro Linden, hosting the  Server Beta group meeting on Thursday March 28th, indicated that the Magnum updates (which are all interest list related and include the vehicle region crossing fix for BUG-1814) is currently his personal favourite to be promoted to the Main channel and BlueSteel / LeTigre in week 14. If this proves to be the case, then he’s liable to have a lot of SL vehicle users very happy with him – myself included!

SL Viewer – CHUI, SSB and More

The SL development viewer moved to release 3.5.1.272979 on Thursday March 28th. As there are no release notes associated with development viewer releases, it is not always easy to determine what a new release contains; however, from tests, it would not appear that the release contains the viewer-side Server-side Baking (SSB) code.

The next major update to the release viewer is slated to be the Communications Hub User Interface (CHUI), which should be arriving “any time now” according the last-known plans from LL.

As previously noted, once CHUI reaches the release viewer, SSB will move to the beta viewer and make an appearance in week 14 – possibly (and coincidentally) on April 1st. Once in the beta viewer, it will remain there for up to four weeks (unless significant bugs are found), and no less than two weeks, prior to it moving to the SL release viewer. It is unlikely that any SSB server-side deployment will commence on the Main grid until after SSB has reached the release viewer – however, this is subject to final planning, and there may be a limited release of the server code while SSB is still in the beta viewer.

Work is still progressing on the materials code, and there is still no date for the release of a project viewer.

HTTP Project

On Wednesday 27th March, Monty Linden sent out an e-mail indicating the current beta testing on Aditi for his new HTTP capabilities will be drawing to a close “shortly”, and that anyone interested in carrying out tests in the three channels should do so sooner rather than later. Precisely when the beta test will close is unclear, but from Monty’s e-mail it would not be unreasonable to assume it will be within a week.

The next stage for this work is for it to progress to a Release Candidate channel – which will seem the “normal” configuration for HTTP services currently on channel DRTSIM-203 on Aditi carried forward to the selected RC channel(s). While there is no date as to when the HTTP work will reach a RC channel, Monty will be looking at the deployment as a more in-depth load test opportunity and seeing how well the new services might scale.

Other Items

Advanced Creation Tools Permissions

July saw the launch of the first phase of the Advanced Creation Tools, also referred to as experience tools. Following problems with an initial deployment of the tools in June, which resulted them being exploited as a means of griefing, the “first phase” of the release saw the tools implemented with existing permissions system in place, with the intention of updating the permissions system to allow the tools to be more fully used “in the future”.

After hearing that the work on the permissions system was again getting attention having been “stalled” for a time, there has been something of a further absence of news on progress. However, speaking at the Server Beta meeting on Thursday March 28th, Maestro was able to confirm the permissions system is currently on internal testing at LL – so it might be showing-up on Aditi (or in an RC deployment) in the not-so-distant future.

Scripted Avatar Rotation

The subject of scripted avatar rotation has come up for discussion at the last couple of server-related meetings. The idea is to use a scripted object to force the avatar to face a specific direction. It is not a new request, having been the subject of several JIRA in the past, most notably SVC-56, which also provides some suggestions as to how it might be achieved. Being able to turn the avatar to face a specific direction has a number of potential benefits – it could, for example, be used to have an avatar face a rock face which could then be “climbed”, or it could make avatar alignment for hugs / kisses a lot more accurate.

RLV already allows such rotation, although it may not be as accurate as required in some of the potential uses. Some objections to the capability have been put forward in the past – such as the potential for “griefing” others; although “griefing” of the kind envisaged perhaps shouldn’t necessarily prevent the development of such a capability, which would preferably be achieved by means of an attached scripted object, which wshould help minimise the risk of malicious use of the capability.

Andrew Linden, in discussing the idea at the Simulator User Group on March 26th commented:

Avatar rotation by script is actually hard to do. The reason it is so hard is a legacy thing… the protocol is basically set up such that the viewer tells the server where the avatar should be facing, and the server tries very hard to get it there. So in order for the server to turn the avatar, it would have to know when to listen to the viewer and when not; remembering such a state isn’t hard, but figuring out when to transition is hard … what would happen if a “turn the avatar” event was triggered and you started mashing on the keyboard to move the avatar elsewhere… what system should win?

Without committing to anything, Andrew concluded the discussion by saying, “I’ll think more about it. Maybe it’s possible. There must be a clever way. I don’t see it yet.”

SL projects update week 13 (1): server, AO capabilities, HTTP, group ban list

Posted on by Inara Pey

Server Deployments – week 13

On Tuesday March 26th, the SLS (Main) channel received the maintenance package previously deployed to BlueSteel and LeTigre in week 12, which includes a fix for a crash mode  – release notes.

Some issues have been reported on following the Main channel deployment. Regions have been slow to come back up, and several which have had issues with groups and display names failing to show, teleport errors, etc. However, at the current moment in time, these issues do not appear to be widespread.

On Wednesday March 27th, the RC channels should receive the following deployment packages:

  • BlueSteel and LeTigre: a new maintenance package, which includes:
  • Magnum: should receive the same update as the Main channel (i.e. the package deployed in week 12 to BlueSteeel and LeTigre), otherwise retaining the updates and fixes deployed to it in week 12 – release notes.

As usual, there is a forum discussion thread for comments / feedback on the deployments.

That the region crossing fix for BUG-1814 is not been deployed to the rest of the grid in week 13 is liable to cause some consternation.

New AO Capabilities

The new AO capabilities, due for deployment on BlueSteel and Magnum. I provided an overview for the new capabilities in week 12, and the Lab have now provided a set of wiki pages on the calls and permissions:

Ban List – and More

As recently reported, 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.).

The work is being undertaken in response to JIRA VWR-29337, and is likely to prove very popular once available.Currently, Baker is working on the development documentation and plan for the work, and has been giving further thought on what the capability will be able to do. Speaking at the TPV Developer meeting on March 22nd, he gave a little more insight into how the capability might progress:

  • A possible format for how the Group Ban option might appear in the viewer, as visualised by Alyssalillian McMinnar
    A possible format for how the Group Ban option might appear in the viewer, as visualised by Alyssalillian McMinnar. LL have an internal design for the UI elements, but this is not something Baker is currently focused on

    The initial release will at least allow group owners and moderators to ban people, a will display the names of banned individuals and the date on which they were banned (presumably to owners / moderators only)

  • It may include a capability to specify why a person has been banned, even if this is initially a case of selecting from a pre-defined list of reasons
  • A future option may be to include a time ban option (although this is potentially more useful in banning people from accessing a region / parcel)
  • An initial design for the viewer-side Group floater has been developed internally by LL, but Baker isn’t so concerned with how the options will be presented through the viewer until after he had defined how the code will work
  • Baker is not planning on adding any on the ban capabilities for group to the existing ban capabilities for regions / parcels, nor will any of the new group ban capabilities be shared with region / parcel ban capabilities, due to the complexities involved.

At the same time as working on the group ban list, Baker has also opted to correct other long-standing issues:

  • The ability to search for people using their user name properly (i.e. no period in between first and last names)
  • A fix for the disallowing of leading spaces on display names.

These fixes will also likely roll-out the same time as the first phase of the group ban list function, once Baker is able to start coding and testing the latter.

HTTP Project

On Friday March 22nd, Monty reported that the Aditi testing had been subject to a couple of non-related hiccups (due to inventory issues), but otherwise the regions were stable and whole one significant bug within the code had been found – severe enough to take down some Apache web servers when HTTP-In was being tested, and which has now hopefully been fixed.

Load testing on Aditi has been a little light, but obviously, more practical load testing will occur when the capabilities reach a Release Candidate channel and things start to get fine-tuned.

Mainland Griefing

The subject of Mainland griefing was discussed at the Simulator User Group meeting on the 26th March. There has been a noticeable rise in object griefing and spamming recently, particularly by the so-called “goonsquad”. Several options for better means of combating the problem were raised, including JIRA SCR-19 (“Script function to return objects”) for the return of griefer objects where users do not have access to estate / region tools for return objects, and possible throttling of llDialog (SVC-8080) to try to overcome the use of dialogue spamming prims.

The Lab will obviously not be drawn into discussions on their own plans for combating griefing, but Andrew Linden took a series of notes on problems which are being encountered, while Simon indicated that the Lab is looking at some options which may help with issues.

Related Links

HTTP updates: the what, why, who

Posted on by Inara Pey

Update March 27th: Commenting on the open-source development mailing list, Monty Linden states: “It looks like Beta (Aditi test regions) will be wrapped up shortly. If you’ve wanted to try these out but haven’t yet, now would be a good time to jump in there.” 

Linden Lab is in the process of making a number of improvements to Second Life which should benefit both the platform and users. Once deployed, some of these updates will be clearly visible as they gain widespread use in-world, such as the upcoming materials processing capabilities. Others will be perhaps more noticeable because they require a viewer update – as is the case with server-side baking, rather than being obviously visible in everyday use. Some will have more of a “background” impact, rather than anything which is clearly visible in-world (although they may make their presence felt for the more keen-eyed).

Monty Linden
Monty Linden

Among the latter category of changes are the HTTP updates currently being tested on Aditi and which will soon be popping-up on a Release Candidate channel. This work is being spearheaded by Monty Linden, and has been under development as a part of the Shining Project initiative kicked-off by Linden Lab in 2012.

Several of my SL projects update reports have covered Monty’s work, and will continue to do so in the future. The aim of this article is to bring the various threads together in a single post, in order to provide a  broad overview of what it all means without getting caught-up in the technical minutiae.

Communications between the viewer and the SL servers are subject to many vagaries. Network issues can occur locally (i.e. with a user’s own network), or at the ISP level, for example, long before they actually involve the SL servers. There is little LL – or the support team for whatever viewer is used to connection to SL  – can do in these instances.

However, network issues aside, there is much work that can be done to improve viewer / server communications and make connectivity between the two more robust – and this is the focus of Monty’s work. Some of this has to do with gradually switching aspects of the service away from the older UDP services within SL to HTTP-based services, and some of it has to do with improving the existing HTTP services employed by SL and making them both more robust and (hopefully) a little easier on older models of routers.

Initial Work

As mentioned above, Monty’s work is encapsulated within the Shining Project, and is being carried out in a number of phases. The first phase of this work was actually completed during the second half of 2012, and focused on improving the HTTP texture fetch mechanism both server-side and within the viewer by which textures are obtained for rendering. This work started to go into widespread use around  November 2012, when the viewer code was made available and Linden Lab announced the new capability thus:

A new scheme for performing HTTP operations is introduced with this release. It is intended to reduce crashes and stalls while performing HTTP operations and generally enable performance and reliability improvements in the future. In this release, it is being used by the viewer’s texture retrieval code. Our expectation is that it will provide consistent and predictable downloading of textures.

The initial HTTP updates being driven by Monty Linden started to appear in around November 2012
The initial HTTP updates being driven by Monty Linden started to appear in around November 2012, with improvements to the texture fetching code in both the viewer and on the server end of things

Following the release of the viewer code, many reported they were seeing significant improvements in texture downloads, and a resultant improvement in texture rendering.

As a part of this initial work, Monty also started examining connectivity between the server and the viewer (number of actual connections opened, etc), and found that it can cause significant hardships for older classes of router, many of which incorporate a firmware-controlled “lock-out” which can be triggered when too many connections are opened when using HTTP, and so can cause users issues (hence the recommendation which some support teams give to disable HTTP textures within the viewer if connection issues are being experienced).

Second Phase

At the start of 2013, Monty commenced work on the second phase of the project, which is currently focused on the server-side of things (that is, there are currently no viewer-side code changes). In particular he is looking at further improving texture and mesh asset-fetching from the server and at implementing HTTP persistent / keepalive connections capabilities, which should enhance the overall robustness of such communications (some of which may hopefully see some connectivity improvements for those people using older model routers, as noted above).

Continue reading “HTTP updates: the what, why, who” →

SL projects update week 12 (3): viewer, CHUI, SSB, materials and releases

Posted on by Inara Pey

SL Viewer Updates

The SL beta and development viewers saw end-of-week updates in week 12, with the beta viewer rolling to release 3.5.0.272486 and the development viewer 3.5.1.272521, both on March 22nd.

The beta update is primarily focused on CHUI, and may be the final beta release for CHUI before the it appears in an official release version of the SL viewer (see below).

On March 20th, the Sunshine project viewer (Server-side Baking) updated to release 3.5.0.272211, which may be the last releases of the SSB code as a project viewer prior to the code arriving in the SL beta viewer – see the SSB section of this report (below).

Communications Hub User Interface (CHUI)

As indicated above, the Lab is hoping that CHUI, the Communications Hub User Interface, is now in its final beta viewer run with the release of 3.5.0.272486, and that the code should be appearing in the release version of the SL viewer, possibly later in week 13 (week commencing Monday 25th March).

CHUI: probably making a final appearance in the SL beta viewer prior to appearing in the release viewer
CHUI: probably making a final appearance in the SL beta viewer prior to appearing in the release viewer

However, TPVs are still considering how best to tackle CHUI in terms of integration and deployment in their viewers. Part of the problem here is that for some TPVs, the CHUI user interface changes conflict with changes the TPVs have themselves made, and so consideration needs to be given as to which parts of the UI updates and changes a given TPV wishes to adopt. A wider issue, however, is that CHUI also includes a large about of v3 code refactoring, all of which needs to be considered for implementation into views, particularly those which are v3-based.

Further, as most TPVs have been focused on SSB updates, it may take a while before CHUI itself appears either in whole or in part, in some third-party viewers.

The CHUI updates don’t only impact TPVs – there is a knock-on effect with some of the upcoming changes / code contributions flowing into the SL viewer code as well. For example, the viewer side of the request teleport feature (STORM-1838), which I originally commented on in week 4, has been delayed while it is re-worked in light of CHUI-generated changes.

Server-side Baking

Viewer-side SSB Code

Following-on from the recent pile-on / load tests carried out using the official viewer (Thursday March 14th) and Firestorm (Friday March 15th), the Lab believes that the viewer side of the code is doing “quite well” in testing, with both tests recording very similar results, including hitting the same problems related to inventory fetching / rezzing issues for attachments.

As a result of this, the Lab have been looking at releasing the SSB viewer code to the SL beta viewer (with CHUI integration) on or around April 1st (week 14). However, the discovery of a bug with the latest version of the SSB project viewer code ( version 3.5.0.272211), may delay matters.

SUN-57, raised by Tonya Souther, reports a fix for earlier issues (non-public JIRA SH-3941 and SH-3954), now appears to cause avatar bake fail issues when running the viewer-side SSB code on regions using the current avatar baking mechanism. Whirly Fizzle has been able to reproduce the issue when using pre-saved outfits in her My Outfits folder, and describes it thus:

Replace outfit with a ready saved Outfit A from My Outfits folder (Right click -> Replace current outfit). Relog Usually, but not always, I will see part of my baked textures as grey with this certain outfit A. This session my torso texture appears grey to me. My torso fully rezzed without needing to rebake in about a minute.

[Now] Replace outfit with Outfit B, which is a ready saved outfit from My outfits folder (Right click -> Replace current outfit).Outfit B bakes fast & looks correct to myself.

Wait 30 secs or so [and] replace outfit again with outfit A. My avatar will then show the correct head and lower baked layers from outfit A but my upper/torso layer will be that of outfit B.

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: left – Outfit A from her My Outfits folder replaces whatever she was previously wearing, and appears correct; centre – after a relog, she replaces Outfit 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

Whirly further reports that the issue doesn’t resolve itself after several minutes, and rebaking using CTRL-SHIFT-R has no effect (other than reducing her to a cloud in other people’s view), while using Edit Appearance also fails to clear the problem.

Again, this issue only occurs when using viewers incorporating the latest SSB code, and only on regions which are not themselves running the server SSB code. It is of concern because the viewer code is designed to work with both the current baking mechanism and the upcoming SSB mechanism, and will be expected to do so during the SSB deployment to the main grid, when there will be a period when both the “old” and “new” baking services will for a time be running side-by-side as the latter is gradually rolled-out.

Continue reading “SL projects update week 12 (3): viewer, CHUI, SSB, materials and releases” →

SL projects update week 12 (1): server releases, SSB and more

Posted on by Inara Pey

Sever Deployments for Week 12

Second Life Server (SLS)

On Tuesday March 19th, the Main channel received the server maintenance package which had been re-deployed to Magnum in week 11. As with the Magnum re-deploy, it excludes the fix for VWR-786 while LL go “back to the drawing board” to try to correct issues. However, it does include the following two fixes:

  • BUG-1612: region Owners and estate managers finding they are unable to teleport back to their region after disabling direct teleports to the region
  • SVC-8019: region visibility delays following region restarts.

The release notes for the deployment are available on the SL wiki, as usual.

Release Candidate Channels

On Wednesday March 20th, the Release Candidate channels should receive the following updates:

  • BlueSteel and LeTigre: should receive the same updates as deployed to the SLS channel on Tuesday March 19th, but otherwise retain the same updates received in week 11 – release notes (BlueSteel)
  • Magnum: should receive further updates to Andrew Linden’s interest list work, as per the release notes.  Specific interest list bug fixes included with this update comprise:
    • Updates for objects that are out of view are delayed for a maximum of 5 seconds, at which point they will be sent (mitigates BUG-1779)
    • Fix for “No object updates from vehicles after some region crossings” (BUG-1814)
    • Fix for “Agent appears in incorrect position to other agents after being moved by a sim teleporter” (BUG-1795).

Server-side Baking

As reported in week 11, the second official Server-side Baking pile-on / load test appeared to go well on Thursday March 14th. Speaking at the Content Creator’s User Group meeting, SSB project lead Nyx Linden reported:

Looks like things are going well overall – the back-end services are performing well. There are still some inventory and attachment rezzing issues, but these are believed to not be regressions from current limits.

A few reports of issues, some of which we have fixes for, others we’re investigating, and we’re looking at what it would take to fix up the systems that were falling over … there were a couple of new bug reports we’re investigating.

A further SSB pile-on / load test conducted in Friday 15th March, but exclusively with the Firestorm viewer pre-release with SSB support. Numbers at the Firestorm test were roughly the same as those for the “official” test, and overall, the outcome was the same – much lower reported SSB issues, but similar problems with outfit attachments rezzing from inventory (or rather, failing to), which was common to both parts of the test.

The Firestorm SSB pile-on / load test, March 15th
Peoiple gather for the Firestorm SSB pile-on / load test, March 15th

The inventory issues have themselves become more of a focus of investigation outside of SSB itself (attachments aren’t affected by the SSB code changes, which  relate directly to the likes of skin, shape and clothing layer changes. While the inventory issues were thought to relate solely to Aditi, Nyx indicated that the problem is likely common to Agni as well. commenting:

We were seeing similar failures in inventory, etc on both the old pipeline and the new pipeline, and in areas that we didn’t change. So if we repeated the test on Agni we think we’d see similar failures. We’re looking at the root causes, but attachment rezzing failures won’t necessarily block our first release … We’re looking at the inventory & attachment issues and where their root causes are.

Expect further updates on the latter issue as they become known.

HTTP Testing

All of the test regions for Monty Linden’s upcoming HTTP updates are now up-and-running on Aditi, and available for public access (allowing for the caps on avatars in the primary test regions). The regions are:

As noted in previous project reports, Monty is keep to have TPVs and scripters test the capabilities in order to gather more comprehensive data on his work.

Continue reading “SL projects update week 12 (1): server releases, SSB and more” →