Second Life Scripting Changes

We don’t hear much about changes to the Linden Scripting Language (LSL) these days. But, today is different. We got a bunch of stuff. Exciting stuff!

Server Beta Meeting 2013-12

Server Beta Meeting 2013-12

At the Server Beta meeting Kelly and Maestro Linden were announcing several new changes.


There are changes coming to the Particle System in Second Life™.  Maestro Linden said, “Alright, so there’s an upcoming server maintenance project, which will probably go to RC next week it has your usual bug fixes, but it also includes goodies for new LSL features.”

The gottcha is that while this will likely hit the RC channel next week, the render features are not in the beta viewer yet. That means CHUI is ahead of these features. Once CHUI makes it to the main version the pipeline will be available for these features. But, we have no information on when it will actually make it into the Dev Viewer and then the Beta.

There are new particle system options; glow (start glow and end glow), ‘ribbon’ particles, and more blending options.

Particle Glow

Did you catch that GLOW in the new options?

Ribbon Particle

A new type of particle has been added: Ribbon.

New Ribbon Particle

New Ribbon Particle

A ribbon particle repeats the texture horizontally. Maestro says the ribbon particle does NOT always face your camera.  Also they move with the object. Some were thinking skid marks for tires.

If I understood, ribbons will have most of the same limits and options as current particles plus the new ones.


Kelly Linden cautions, “One very important thing to realize about these particle changes is that this is the server side support for them, there is also a required viewer update of course which I don’t have an ETA on. As a side effect of this any particle system that uses glow or the blend functions will not render at all on older viewers.

So, that means 3.5 viewers and older will be particle lame.


Several of the events we use are detected by Event: changed( integer change ). In the new server package the changed() event now triggers in child prims for CHANGED_REGION and CHANGED_TELEPORT. The changed() event will trigger in the child prim, letting it know that it was teleported or moved to a new region. Previously the events would not trigger in child prims.

Animation Override

I broke this story earlier and promised more, so here is more. Maestro Linden says this change is available immediately, because no viewer change is needed. Kelly Linden elaborates, “’immediately’ == w/ this upcoming server version.” That version on ADITI is DRTSIM-201. These ADITI regions are running the code: CCMTEST17, CCMTEST22, CCMTEST23, CCMTEST26, and CCMTEST29.

There is one viewer change coming. In some future version the Stop Animating Me control will reset the animations to the SL default.

llSetAnimationOverride (string anim_state, string anim) – where the first argument is a default animation state and the second is the name of an animation to use for that state. Once set, the animation is used until changed or the session ends. Since this is a server side change, it cannot carry over to the next session.

  • Set the animation that will play for state.
  • Requires new runtime permissions PERMISSION_OVERRIDE_ANIMATIONS

You can reset these animation states:

  • “Standing”,
  • “Sitting”,
  • “Sitting on Ground”,
  • “Jumping”,
  • “Hovering”,
  • “Taking Off”,
  • “CrouchWalking”,
  • “Walking”,
  • “Running”,
  • “Hovering Up”,
  • “PreJumping”,
  • “Hovering Down”,
  • “FlyingSlow”,
  • “Flying”,
  • “Falling Down”,
  • “Striding”,
  • “Landing”,
  • “Soft Landing”,
  • “Crouching”,
  • “Standing Up”,
  • “Turning Left”,
  • “Turning Right”

llResetAnimationOverride(string anim_state);

  • Resets the animation for the given state to the default.
  • Special state of “ALL” will reset all animation overrides to their defaults.
  • Requires new runtime permissions PERMISSION_OVERRIDE_ANIMATIONS

Once the script is run, the attachment that sets the animations can be detached. As best I can tell at this point it does not HAVE TO be attached. It could be run from any prim that has your permission.

I suspect Third Party Viewer Developers will find a way to retain the information from session to session.

Starting out an AO using this function will have to set animations when it rezzes.

We will have to wait to see how scripters use this function to redo existing AO’s.

An Advantage is this type of AO will not have to wait for a script to detect a state change and update the server each time a state changes. As it is now they sort of fight. The viewer signals a state change, the server runs the default animation or at least starts to and starts sending that data to all the other viewers in range of your avatar, then the AO realizes state changed and sends the server new animation information which it then starts relaying to all those other viewers. There is some often visible delay in the process.

With this new feature the server can just send the animation information when it detects a state change in the avatar. Way less communication is needed.

llGetAnimationOverride(string anim_state) – Get the name of the animation currently set for state.


Kelly says, “This keys directly into the server’s animation states. There are some things the viewer handles separately that are not covered, like idle animations and swimming.

These calls are all compatible with existing AOs, assuming appropriate priorities are used. The priorities are part of the animations, not the states.

This is not a complete AO replacement, it won’t make AOs obsolete but it should help them do a significant portion of their work easier and smoother.”

Maestro points out, “Poseball type objects should use llStopAnimation(llGetAnimationOverride(“Sitting”)) instead of llStopAnimation(“sit”) in order to play nicely.” And Kelly adds, “Seats and poseballs should probably continue to use trigger animations.”


If you are not into scripting, these may not seem like important changes. I think they are and find them very exciting. I expect many things to change and animations to be much smoother. But, while the Lindens say the new feature is compatible with existing content, I would not be surprised if things are not as compatibile as they think… BUT… may be.

7 thoughts on “Second Life Scripting Changes

  1. It will be a shame if the new AO scripts break older poseballs, beds, dance machines, etc. Many of us have treasured antiques we still use, the original creator may not still be around to fix the script though.
    The price of progress I guess. Reverse compatibility will someday be the death of Second Life.

    • You could be right about the ‘reverse compatibility’ thing. I think massive amounts of SL code are being re-written. So, I think you mean the ‘reverse compatibility’ with legacy content.

      If one does not use the new AO features, nothing ‘should’ break… Animation priorities are going to become much more import. I also think the .anim file format for importing animation to SL is going to become more important because of its additional control.

      • > Animation priorities are going to become much more import.

        It’s also a shame that these are broken too. Pretty much every anim I’ve bought, and about 90% of those I’ve made use priority 4.

        I forget what the exact reason was, but it was something to do with a default LL chucked out which was set to 4 – meaning that anything content makers made… got under-prioritised. It was a few years ago I simply stopped caring and making everything 4.

        Anim priorities need a new scale. Naturally, that will break everything out there that’s by default coded for 4.


  2. Pingback: August Rush |

  3. Pingback: Cajsa Fast Five: March 22nd | Its Only Fashion

  4. 5 months later, still no ribbon particles. 🙁

    This is one I was really looking forward to.

    • The server side is done. The viewer is lagging. We did get particle selection in one of the viewer RC’s.

Leave a Reply

Your email address will not be published. Required fields are marked *