At the Server Beta meeting Kelly and Maestro Linden just announced the addition of two new Linden Scripting Language (LSL) functions that will allow script-less Animation Overriding (AO).
llSetAnimationOverride(“Walking”, “sassywalk”) – where Walking = default animation state and sassywalk = the animation to use for that state.
llGetAnimationOverride(string anim_state) – Get the name of the animation currently set for state.
More to come…
These will soon be running on the ADITI grid and moving to RC channels…
I don’t quite understand. If an AO is “script-less,” what have new LSL functions to do with it?
Read the next article… that should make it clearer, I hope.
Very awesome and much welcomed.
sigh,
Once again the lindens take a simple thing and make it harder.
Wouldnt the proper scripting fix be access to the animation change event?
Why shouldn’t that level be exposed to the user base for scripting?
Not once again, that is unjust and unfounded.
By having the script tell the server to change the animations used for the default states things become way simpler. Scripts now have to poll and send information to the server each time they detect a state change. Your way the script would trigger on an event, without polling, and still have to send information about which animation to use to the server each event change AFTER it has already started loading the standard default animation. This way once the animation is specified, the script can go to sleep for the rest of the session. The server and viewer handle the changes without any script and without false loading starts.
You would be able to put the script to sleep if people only used single animations in each of the available AO states. This is NOT the case. Most AO’s are configured to support cycling through a sequence of stand animations. If we exclude sitting on blue and pink balls, my guess is that 80% of AO workload is doing stand animation cycling. In order to prevent the false loading starts you describe, the AO will now have to preset the default to the next stand in the cycle, and then change the stand. There will still be a script timer to trigger this and the script has to handle the resulting timer event, so your script will NOT be cost free.
A simpler solution would be to NOT add additional commands to the scripting language specific to a subset of animation types, but to expand on the already existent change event to include an animation changed flag. If you want to really solve the false loading starts for animations, give us a way to preload the animations into cache. This also solves problems for the folks sitting on the pink and blue balls, dancers, and anyone else trying to get smooth animation transitions. It also properly supports the more complex situations where AOs are configured to play overlapping animations ( a standard capability in the ZHAO family of AO’s )