Tag: LSL Updates

SL projects update week 20 (1): server, JSON, viewer release process

Posted on by Inara Pey

Server Deployments – Week 20

As always, please refer to the release forum  thread on the weekly deployments for the latest updates and discussions.

Second Life Server (Main channel)

On Tuesday May 14th, the Main channel received the Experience Keys project which is widely regarded (and referred to by LL staff) as the “experience permissions”. This means the project is now available across the grid, although there are no visible changes to be seen at this point. Release notes.

Speculation is still running high on exactly what the new project is – and whether it is “just” the experience permissions to partner the existing advanced creation tools ot something more – as well as whether the capabilities will be available for use across the grid (i.e. on Mainland as well as private estates). Details will be forthcoming from the Lab in time; for the moment, they’re holding their cards close to their collective chest.

Release Candidate (RC) Channels – JSON Capabilities

On Wednesday May 15th, all three RC channels should receive a new server maintenance project (release notes (Bluesteel)).  The project is designed to fix two crash modes and two bugs, namely:

  • A fix for ‘Overriding “Sitting on Ground” animation while sitting on the ground makes “stand up” button disappear’ (BUG-2424)
  • A fix for ‘ApplyImpulse now works only in the root prim’ (SVC-8227)

In addition, this project introduces new LSL support creating and parsing for JSON-formatted strings. The new LSL functions comprise: 

  • list llJson2List(string json) – converts the top level of the json string to a list.
  • string llList2Json(string type, list values) – 
    • Type is JSON_ARRAY or JSON_OBJECT
    • Converts either a strided list of key:value pairs to a JSON_OBJECT or a list of values to a JSON_ARRAY
  • string llJsonGetValue(string json, list specifiers) – gets the value indicated by spcifiers from the json string.
  • string llJsonSetValue(string json, list specifiers, string value) – returns a new json string that is the json given with the value indicated by specifiers set to value
  • string llJsonValueType(string json, list specifiers) – returns the type constant for the value in json indicated by specifiers.

At the time of writing, the RC deployments still had a question mark over them as testing was, according to Simon Linden when speaking at the Simulator User Group, “down to the wire, although it all looks good.”

Further information on the new LSL support for JSON can be found on the LSL JSON wiki page.

The project is being lead by Kelly Linden who described the reason for implementing them as being because he’s “keen on improving the ability to interface LSL with the larger web. The previous maintenance version expanded the content-type support of http-in and http-out which ties in with this.”

It is likely that further LSL support for JSON will be added in the future.

SL Viewer

Beta Viewer and the Viewer Release Process

A further beta viewer release was made on May 11th (3.5.2.275565) – see the release notes for details – in preparation for the deployment of the new viewer release process. The beta 3.5.2 viewer incorporates changes required by the new service.

While at the Open-source Dev meeting on Monday May 13th, I asked Oz Linden on the status of the new process. “Internally, we’re essentially already using it in that all projects are based on viewer-release,” he replied. “We’re starting system test of the server-side infrastructure changes this week… once those are tested, it’s just a matter of deploying them and we can fully switch over to the new process. ‘just deploying’ on our scale is always an understatement, incidentally.”

This does not mean the release process is about to be deployed, however. The server-side infrastructure testing is liable to be on-going for a while. One aspect which the Lab will be checking carefully is the changes made to the log-in process.

When a user logs-in to Second Life using an official viewer, a check is carried out to see if a mandatory upgrade is required. To prepare for the new release process, is check has been updated. “that’s not something one deploys without having taken every step one can think of to quadruple-check just a bit,” Oz explained.

How long the tests will take to complete is unclear, but it is unlikely the new release process will be deployed in week 20.

Materials Processing

May 8th saw the The materials project viewer updated with the release of version 3.5.2.275470, with the release notes available here.

Detail on the hint of a Katana created entirely using the new materials capability. The sword is made by June Dion and has an LI of 7
Detail on the hilt of a Katana created entirely using the new materials capability. The sword is made by June Dion and has an LI of 7

Work is continuing with the viewer, focusing on the UI issues which need to be resolved in order for the code to progress towards mainstream  release.

Continue reading “SL projects update week 20 (1): server, JSON, viewer release process” →

SL projects update week 17 (1): Server releases, SSB/A, particles

Posted on by Inara Pey

Server Deployments – Week 17

SLS Main Channel

On Tuesday 23rd April, the SLS Main channel received the update package deployed to the three Release Candidate channels in week 16, primarily comprising the new server-side LSL Animation Override capabilities, complete with a fix for BUG 2164, wherein the new capabilities could conflict with built-in animation poses in chairs, etc., as discussed in my week 15 updates.  This deployment additionally includes the slight region performance improvement when there are no pathfinding characters present. Release notes are available.

Release Candidate Channels

On Wednesday 24th April, the RC channels should receive the following updates:

  • BlueSteel and LeTigre: should gain a new project which brings preliminary server-side support for experience permissions – release notes
  • Magnum: should gain a new server maintenance project.  This update brings some new minor features to LSL, and fixes some crash modes – release notes

So the long-awaited experience tools / advanced content creation tools permissioning system looks to be finally on its way, a little under a year since an exploit caused them to be withdrawn after their initial deployment.

Viewer Updates

Development Viewer Updates

The SL development viewer has been through a rapid series of updates over the last few days of week 16 and the start of week 17, with version 3.5.2.2744 released on Monday April 22nd. While release notes are not available, it is thought it includes (among other things), the fix for music stuttering every few seconds when using FMOD EX, as submitted to LL by Latif Khalifa  (see OPEN-173).

Particle Project Viewer Soon (?)

It appears a new particle project viewer may be on the horizon in the near future. If it does appear, it is likely to be primarily aimed at testing a new capability to help deal with griefing attacks which use particle emitters. Speaking at the Simulator User Group meeting, Simon Linden said:

We’re doing some testing and may get a project viewer out, which would allow you to test it and (I believe) let other viewers check out the source code. This is right-click on a particle, and it kills the generator … We’ve tossed around a few ideas about blocking particles in other ways but definitely want to get these first steps out the door.

This sparked further discussion on ways and means to help stop particle griefing, which has been on the increase across the Mainland of late. However, given that particles are a viewer-side effect, “stopping” them is actually easier said than done from a server-side perspective. One idea which gained some interest, if it is feasible, would be a block of any particle emitters belonging to an avatar banned from a region / parcel.

In the meantime there are means of stopping the viewer from rendering all particles – such as CTRL – Alt – Shift – +, or going to Preferences > Graphics > and dropping the Particle Count slider to zero. These again only work in your own world view, and while not always ideal, do present an option.

Asked if such a particle project viewer might include the new LSL particle capabilities already deployed server-side, Simon could only say, “Hopefully yes … I’ve been working on getting that chunk of code solid for the last few days. Unfortunately it’s pretty easy to crash at this point and so it’s not ready for consumption.”

The particle ribbon effect  is a particle which repeats the texture horizontally, and can follow the object creating them, which offers a lot of potential uses, as which forms a part of the new particle capabilities – soon to be seen within a project viewer? – Time will tell.

Server-side Baking / Appearance

The viewer-side code for SSB/A is starting to appear in more TPVs:

  • Cool Viewer has had SSB/A support in the “Experimental” branch for a while, and this moved to the “Stable” and “Legacy” versions on April 20th – see the Cool VL website and release notes
  • Singularity released version 1.8.0 with SSB/A support on April 21st, which I’ve reviewed
  • Firestorm released version 4.4.0 with SSB/A support on April 22nd, which I’ve reviewed
  • Kukua has had an experimental / development version since the start of April (version 3.5.1) which also incorporates SSB/A.

The status of the SL beta viewer with the SSB/A code will take place around the middle of week 17, when a decision taken as to whether to incorporate the code into the SL release viewer or run a further beta release. The expectation is that the code will move to the release channel unless a last-minute significant issue is found within the code which prompts a further run in beta.

Assuming the code does make it to the release channel, it is likely that a release viewer will appear early in week 18 rather than late week 17, due to the time required to test and QA a build.

SUN-72 – Fix Submitted

One issue which is known to exist within the current beta release of the SSB/A viewer code and which has caused considerable problems is SUN-72 – if you have inventory items with special characters (including the likes of asterisks) in their names, they will fail to load. Similarly the use of accented characters (e.g. such as René) in things like chat log path names, the logs are not saved.

Nicky Dasmijn of the Firestorm team developed a patch for this specific problem which is already incorporated into the recent Firestorm 4.4.0 release, and which has been contributed to, and accepted by, the Lab for integration into the SSB viewer code. Hopefully, it should be appearing in the next SSB viewer release, whether beta of SL release viewer.

Sun-38 – Avatar / z-offset

As noted in my last major update on SSB/A, the ability to offset an avatar’s height on-the-fly to accommodate various animations (e.g. kneeling), or to adjust an avatar’s height when sitting / walking of floors, etc., and which will effectively be “broken” as reported in  SUN-38, remains an issue for many.

While the Lab have produced an alternative approach which addresses some issues around avatar height offset using new appearance sliders, and which Nyx Linden and others have been continuing to tweak, there is no solution on the horizon for maintaining any form of on-the-fly adjustment; nor does the proposed solution work with no-mod shapes, as noted when I first  reported on the “fix”.

During the Content Creation User Group meeting on Monday, April 22nd, a request was made for the Lab to not shut-down the existing baking service until such time as  SUN-28 is “solved”, which prompted Nyx to comment:

SUN-38 is not currently considered a blocking issue for our initial release. It’s on our list to investigate, but we don’t have a patch or update immediately. There is a new hover parameter, which should work for attachments that affect your avatar, but the bug reported is also discussing the need to adjust the offset on the fly without changing wearables. Having both the new and the old system enabled is not an option … We are investigating options, but it is not a hard requirement for the initial release.

Continue reading “SL projects update week 17 (1): Server releases, SSB/A, particles” →

SL project updates week 15 (2): Materials, AO capabilities and group bans

Posted on by Inara Pey

Server Deployments Week 15

  • As reported in the first part of this week’s update, there was no Main channel deployment on Tuesday April 9th, the result of issues arising with the previous week’s RC deployments, which LL wanted to fix rather than having them propagate across the grid
  • Magnum retained the same package as week 14 (Monty Linden’s next batch of HTTP updates) and a fix for a crash mode
  • Continuing issues in getting the anticipated updates for the BlueSteel and LeTigre deployment packages ready meant that on Wednesdays April 10th meant that these two channels received the same package as the Magnum RC channel.

The switch-out with the Magnum code being deployed to BlueSteel and LeTigre meant that those regions “lost” the new LSL Animation Override capabilities – existing scripts using the capabilities will still run, but new scripts using the functions cannot be compiled.

Materials Processing

Viewer Update and Documentation

Discussing the materials project at the Open-source Development meeting on Wednesday, April 10th, Oz Linden indicated that an updated version of the project viewer should be available shortly – possibly by the end of the week, as  “lots of fixes are accumulating”. In the meantime, a mixture of Linden Moles and volunteer users are working on materials-focused updates to go into the Good Building Practices guide to help other users get to grips with materials processing and optimising things for SL use. In the meantime, the Materials Data information on the SL wiki continues to be updated.

As pointed out by Mona Eberhardt in the comments relating to materials in this blog, Laverne Donat has produced a very tidy and short demonstration of materials in SL, which I’m including here.

Alphas, Transparency and Costs

Laverne also asked, via Plurk, if and how a specular map can have transparency with the materials processing, before going on to comment (via my blog) that, “After some testing, it seems that you can get specularity with diffuse maps with alpha masking, but not with diffuse maps with alpha blending. I don’t know what the intended behaviour is, but that’s how it works at present.”

This prompted Geenz Spad to reply, “The intended behavior (eventually) is that alpha blended objects will be able to support both normal mapping and specular mapping. Currently this is a work in progress, and due to its current state, it hasn’t been added to the viewer just yet.”

As Alpha Blending is currently the Alpha Mode which is unaffected by the materials / LI accounting situation which has been reported by Qie Niangao, I asked Geenz if Alpha Blending was liable to “trip over” into the LI accounting system, rather than being “grandfathered” (as currently appears to be the case). He further clarified the situation by replying, “Only if you use other material parameters (such as specular mapping, normal mapping, etc.). The only reason why we didn’t add support for shiny on all semi-transparent surfaces, is because it would break content.”

Future Development

In terms of future development, it is unlikely that anything will be happening soon, other than enhancements / fixes for what is currently in the project viewer. While there is a roadmap for future features and additions to the materials system, the Lab is wisely not commenting on plans and direction at this time. Rather, they prefer to see what the overall take-up with the new system is over time and how people start using it (which may in turn affect how and what the Lab decides to do with regards to a “materials round 2”). However, one thing which does appear to be clear is that there are no plans within the current roadmap to extend materials processing to include avatar skins and clothing layers.

AO Capabilities Update

New server-side AO capabilities: udpates delayed until week 16
New server-side AO capabilities: updates delayed until week 16

Although it did not get deployed in week 15 (but should see the light of day in week 16, commencing Monday, April 15th), the update to the new AO capabilities which should have reached BlueSteel and LeTigre is intended improve compatibility between the new animation override system and other scripted objects that animate avatars (such as poseballs). The update was developed as a result of Code Violet raising a JIRA (BUG-2164) pointing out that the new capabilities did not “play nicely” with things like sit animations in poseballs / furniture.

Maestro Linden, speaking at the Best Server meeting on Thursday, April 11th, described the situation thus:

If a user had a custom ‘sit’ animation set, the seat wouldn’t be able to stop the animation properly because if the seat called llGetAnimationOverride(“Sitting”), it would get an empty string unless the exact animation also happened to be in the seat’s inventory. Kelly has a nice solution to this problem, which is to make ‘llStopAnimation(“sit”)’ stop your custom animation, if you had overridden your sit animation. Conveniently, this change means that existing poseballs won’t need any updates to play nicely with the new AO system.

The Beta Server meeting saw some discussion on the new AO capabilities, which enabled Maestro and Kelly Linden to offer further clarifications.

Continue reading “SL project updates week 15 (2): Materials, AO capabilities and group bans” →

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 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.