Tag: Server Updates

SL projects update week 15 (1): Server and viewer; materials and land impact

Posted on by Inara Pey

Upate April 10th: The BlueSteel / LeTigre package did not deploy as planned due to problems getting the updates completed in time. The Magnum package therefore deployed to all three RC channels.

Server Deployments Week 15

Second Life Server (Main) Channel

There was no planned deployment to the Main channel on Tuesday April 9th. The next scheduled deployment will be in week 16 (week commencing Monday April 15th). This was because there were bugs found in both of the RC releases from week 14 which the Lab wanted to resolve rather than having them propagate across the grid.

Release Candidate Channels

All three Release Candidate channels remain on the same releases as week 14, the only updates to be deployed on Wednesday April 10th being:

  • BlueSteel and LeTigre (currently running the new server-side AO capabilities) – should receive  a design change to improve compatibility between the new animation override system and other scripted objects that animate avatars (such as poseballs). This may be in response to a JIRA – BUG-2164 – being raised in relation to conflicts between the new AO capabilities and poseball systems
  • Magnum (currently running Monty Linden’s HTTP updates) – should receive a fix to correct a crash mode.

As always, there is a forum discussion thread for the week’s deployments.

SL Viewer Updates

CHUI – Communications Hub User Interface – Flickering Issue

The CHUI merge with the SL release viewer has brought with it an increase in the ATI/AMD issue of clickable links in the viewer’s UI flickering when anti-aliasing is enabled (BUG-1560, relating specifically to cards running the 12.10 (or later) Catalyst). This tends to happen with links in the chat window, but may also affect the selection box surrounding items in the inventory floater.

Those encountering the problem should consider raising a bug report.

Materials Processing – Land Impact

The most notable update to the SL viewer has been the release of a project viewer for materials processing. The viewer is available on the SL wiki Alternate Viewer page, and the code is available on Bitbucket. However, due to the work still going into the project, both come with caveats:

  • It is still very fragile
  • It is still subject to change in various ways
  • It should not be used on content you care about – particularly if said content is MODIFY / NO COPY
  • It is not recommended that TPVs integrate the code into their release viewer at the moment due to the fact the code will be changing (and there is not SSB merge as yet).

The release of the viewer has also brought with it something of a concern.

Qie Niangao has been carrying out further tests with the Materials Processing project viewer, and has come up with evidence that aspects of the material system can result in objects experiencing sudden (and potentially large) Land Impact value changes. Specifically use of the Alpha Masking and Emissive Mask options when working with alphas can have unexpected results – which is not to say that the result are not unexpected behaviour from LL’s perspective.

Qie describes his discovery in MATBUG-13, is which he offers the following exercise:

  1. Create a sphere. Hollow it 95%. Add a simple rotation script.
  2. Set the Alpha Mode to Alpha masking. Note that the land impact is now 43. “More info” shows the extra weight attributed to Physics.
Using the Alpha Masking and Emissive Mask Alpha Mode options with tortured prims (in this case a hollow sphere) into the "new" LI accounting system
Using the Alpha Masking and Emissive Mask Alpha Mode options with tortured prims (in this case a hollow sphere) can lead to a inflation of LI for an object

Qie goes on to note that cutting or squashing such an object can have an even more dramatic impact (path cutting the sphere in half, for example, can push LI to 1348, while squashing it almost flat can lead to an LI of 154).

Commenting on the JIRA, Maestro Linden notes:

This is expected behavior. When a material is added to an object, it is enrolled in new prim accounting. A 50cm, 95% hollow sphere has 43.5 physics cost when using a ‘prim’ physics representation. This high cost is caused by the high complexity physics shape. See https://wiki.secondlife.com/wiki/Physics_Optimization for a guide about how to reduce physics cost.

It is interesting to note, however that the same prim using Alpha Blending retains the same physic cost, but only generates a LI of 1. As Alpha Blending is essentially the way alpha layers are currently handled by the system at the moment, Qie’s theory – which I agree with – is that the existing system as been somehow “grandfathered-in” to the LI accounting system.

Continue reading “SL projects update week 15 (1): Server and viewer; materials and land impact” →

SL projects update week 14 (3): Viewer releases, server-side AO

Posted on by Inara Pey

Server Deployments – week 14

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, together with 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).

Deployment release notes.

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

  • BlueSteel and LeTigre received the same package as week 13, which includes the new Animation Override LSL capabilities together with the following:
    • 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 received Monty Linden’s new server-side HTTP updates – release notes.

SL Viewer

There has been some activity within the various viewer channels, and the promise of more to come.

The Communications Hub User Interface (CHUI)

CHUI has now reached the  viewer release channel with LL issuing viewer 3.5.0.273444. This release includes both the new CHUI UI for conversations, etc., as well as a lot of additional refactoring of code. A blog post has accompanied the launch, complete with Torley’s original video on the interface.

Server-side Baking Viewer Code

The viewer-side code for Server-side Baking / Appearance (SSB) reached the SL development viewer with the release of version 3.5.1.273529. With CHUI now in the release viewer, SSB should also be appearing in the SL beta viewer view shortly.

Materials Processing

“Materials is actually making great progress,” Oz Linden reported at the Open-source Dev meeting on Wednesday April 3rd. He went on to say the latest work on the code is showing promise and was due to go to LL’s QA department. If things go well with QA, it is possible that a project viewer could finally be emerging from the darkness. However, as Oz again warned this will only happen when, “We’re confident that 1) it won’t do any serious harm, and 2) it’s not so terrible that it’ll give the project a black eye.”

Nevertheless, things are moving.

Server-side Animation Override Capabilities

New server-side AO capabilities coming soon
New server-side AO capabilities: LSL functions now being deployed to main grid

While the new Animation Override LSL capabilities have only just rolled-out BlueSteel and LeTigre, the server has actually supported overriding animations for over a year; it has just lacked the required LSL functions and some bug fixes. This means that if you use the new capabilities on either BlueSteel or LeTigre, any animations you set will continue to work across the entire grid until you log out.

In noting this at the Server Beta user group meeting on Thursday April 4th, Kelly Linden went on to say:

The new override functions do not allow setting by UUID. My original version (well over a year old) set by integer constants. However there was some desire internally to make the system more flexible, to allow for different states or modifying the state machine diagram, and for that string constants were used. Right now those string constants are converted to integer constants for use in the existing internal state machine.

In other words, the system allows animations to be specified by name (string constant), making the capability somewhat more user-friendly than might have been the case has UUIDs for animations been required. The the string constants are converted to integers for handling by the server’s state machine (the “engine” for animations on the server-side) means that it should be possible for the state machine to be updated in the future without potentially breaking content using the capabilities.

In answering a question on the lack of support for animations such as idling and typing, Kelly again explained that some animation types are not supported by the state engine. These are either handled within the viewer (idling) or elsewhere in server (typing), as such they fall outside the new AO capabilities. Swimming is also excluded, although Kelly couldn’t remember if that is handled viewer-side or elsewhere in the server.

HTTP Updates

Monty Linden’s ongoing HTTP work reached the Magnum RC channel. For those interested in monitoring SL’s port usage, Monty provided a quick summary in response to a question on texture fetches posted to the deployment thread:

The Texture Console speaks truth for texture fetches, either http or udp.  If that is quiet while this transport is going on, it’s something else …. and here are some rules that will determine the traffic:

  • Port 12046 but textures are quiet => mesh fetches
  • Port 12043 (corrected, was 12042) => other HTTP services (“Capabilities”)
  • UDP port 12035, 13000-130XX => simulator communications

Related Links

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

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.