Category: SL User Group Meetings

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

LL announce new server-side AO capabilities

Posted on by Inara Pey

Update March 26th: This article now includes the links to the relevant wiki pages for the new capabilities, as released on March 25th. Also, permissions to animate an avatar are only auto-granted when a prim using the new capabilities is attached to the avatar (PERMISSION_OVERRIDE_ANIMATIONS), otherwise explicit permission required.

Note: article title revised to better reflect contents

At the Beta Server meeting on Thursday 21st March, the Lab informally announced the forthcoming arrival of a server-side Animation Override (AO) system utilising LSL commands.

Coded by Kelly Linden, this new capability is not seen as a replacement to existing AO systems, but rather as a means of making them, in Kelly’s words, “Do a significant portion of their work easier and smoother.”

Overview

The new system utilises a series of new LSL commands, which can be placed in a script located in a prim which has permission to animate your avatar, much like current AOs (granted automatically if the prim is attached to your avatar).  However, the advantage with the new calls is that they are keyed directly into the server’s animation states, unlike current AOs, which operate somewhat in conflict with the server’s animations states.

For example, with current AO systems, moving your avatar (i.e. walking) causes an update to be sent to the server, which initially tries to run the default animation required (i.e. the infamous “duck walk”). However, the AO script also detects the state change for your avatar, and then instructs the server to replace the default animation information with the required animation.

With the new system, rather than trying to run the default animation and then have an AO tell it what it should be doing, the server simply replaces the default animation with the required animation, thus vastly simplifying the process.

The new capability is currently available for testing on a number of regions on Aditi (CCMTEST17, CCMTEST22, CCMTEST23, CCMTEST26, and CCMTEST29, all on project channel DRTSIM-201), and it should be deployed to a Release Candidate channel during week 13 (week commencing Monday, March 25th).

Additional Notes

  • The new calls should be compatible with existing AOs, assuming appropriate priorities are used
  • Items such as idle animations and swimming animations are handled separately by the viewer, and so are not covered by the new calls
  • This capability does not require an viewer-side changes at present, although it is likely that a future update will be made to the viewer to allow the Stop Animating Me menu option to reset animation states set using the new calls
  • Seats and poseballs should continue to use trigger animations
  • Poseball type objects should use llStopAnimation(llGetAnimationOverride(“Sitting”)) instead of llStopAnimation(“sit”) in order to work smoothly with the new calls.

Animation States

New server-side AO capabilities coming soon
New server-side AO capabilities coming soon

The animation states specifically covered by the new LSL calls comprise:

  • Standing
  • Sitting
  • Ground sit
  • Standing up
  • Crouching
  • Walking
  • Crouch walking
  • Striding
  • Running
  • Turning right
  • Turning left
  • Jumping
  • Pre-jumping
  • Taking Off
  • Hovering
  • Hovering Up
  • Hovering Down
  • Flying
  • Flying Slow
  • Falling Down
  • Landing
  • Soft Landing

LSL AO Calls

The following LSL calls have been defined for use with the above animations.

llSetAnimationOverride(string anim_state, string anim);

  • Sets the animation that will play for a given AO state, where:  string anim_state is the name of the animation state being overridden (e.g. Walking), and string anim is the animation to be used
  • Requires a new runtime permission – PERMISSION_OVERRIDE_ANIMATIONS
  • Once an animation override is set for a given state, it is preserved for the rest of the session, unless reset (see below)
  • As the animation states are purely server-side, they get cleared on a relog.

llGetAnimationOverride(string anim_state)

llResetAnimationOverride(string anim_state);

  • Will reset the animation for the given state to the default
  • Includes a special “ALL” state, which will reset all animation overrides to their defaults
  • Requires new runtime permissions PERMISSION_OVERRIDE_ANIMATIONS.

[New addition, March 26th]. Note that PERMISSION_OVERRIDE_ANIMATIONS Only be auto-granted for attachments, otherwise explicit permission required.

Testing and RC Deployment

As mentioned above, there are a number of test regions available on Aditi where the new AO calls can be tired out by scripters and TPVs, and the new capabilities should be arriving on an RC channel in week 13. Any issues found with the capability should be reported via a JIRA, and, if deemed appropriate, raised at the Simulator User Group meeting on Tuesday, March 26th.

SL projects update week 12 (2): server, interest list, region crossings, particles

Posted on by Inara Pey

Server Deployments – Week 12

The planned server deployed went ahead as scheduled and as follows:

  • Second Life Server (Main channel): on Tuesday 19th March, the SLS 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.
  • Release Candidate channels: on Wednesday 20th March, the three RC channels received the following updates:
  • BlueSteel and LeTigre: received 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) – see below
    • Fix for “Agent appears in incorrect position to other agents after being moved by a sim teleporter” (BUG-1795).

Interest List Updates

Vehicle Crossings

The Magnum RC channel received a potential fix for the vehicle crossing issues (BUG-1814) which have been experienced by many of late, and which appears to have been a major step in the right direction, going on feedback posted to the deployment thread on the forums.

Essentially, the problem lay in the fact that the recently deployed interest list code has only been updating the viewer with information relating to objects within the camera’s field-of-view. If an object moves out of the field-of-view for more than a few seconds, then updates cease until such time as it re-enters the field-of-view.

Where this becomes a problem when crossing a region in a vehicle, is that when transferring between regions, the camera position is effectively extrapolated first, and any vehicle the avatar is attached to is created “behind” the camera by the simulator just entered. Thus, to the interest list code, the vehicle is “outside” the camera’s field-of-view, and so updates on it are no longer sent to the viewer, and problems result.

The updated interest list code deployed to Magnum ensures updates relating to any object an avatar is sitting on are always maintained (or “subscribed to”, to use the official term) by the interest list code, regardless as to where the vehicle appears to be relative to the camera position. Thus, updates continue either side of a region crossing, allowing control of the vehicle to be maintained.

I took time out to test the code fix, with the aid of Erick Gregan, on Thursday March 21st and we agreed that for aircraft at least, it looked good – neither of us encoutered problems.

Flying a Spitfire XI by Erick Gregan over the four Magnum Sandbox regions, I encountered no isues with sim crossings
Flying a Spitfire XI by Erick Gregan over the four Magnum Sandbox regions, I encountered no issues with sim crossings

Those wishing to test the updated code across region boundaries with aircraft or ground vehicles can do so by visiting the Four Magnum Sandbox regions (accessible to members of the Beta Tester SL group – which is free to join). The update itself will hopefully be deployed to the entire grid in the week 13 deployments.

Object Updates

The lack of updates being received from objects outside of the camera’s field-of-view have resulted in other issues as well, which are also fixed in the Magnum release.

For example, if you are looking at a cube which is changing colour between red and blue every few seconds, and turn your camera so that it is outside your field of view and wait for it to turn blue before camming back, the cube will briefly still appear to be red in your view before suddenly changing to blue. This is due to the fact that when the cube is outside your camera’s field of view, the updates associated with it are no longer sent to your viewer until such time as it re-enters your field of view.

With the updates deployed to Magnum, updates for objects outside your field of view are once again sent to the viewer – but at  a very low rate (around one update every 5 seconds). While this uses a little more bandwidth then sending no updates at all, it also means that objects in a state of change behave more predictably when camming away from and back to them (BUG-1779).

Cacheable Objects

The Magnum update also implements the first set of changes to the re-use of cacheable objects held by the viewer in order to speed up rezzing / rendering. These changes take two forms: a change in what can be cached in the viewer, and a change the order in which things are rendered.

Up until now, any object or item containing a script was considered non-cacheable by the viewer, whether or not the object itself has changed at all.  So if the object disappears (because you teleport away from the region, for example), then all data relating to that object is discarded by the viewer, and has to be re-obtained from the simulator on re-entering the region, which slows rendering.

Continue reading “SL projects update week 12 (2): server, interest list, region crossings, particles” →

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