Resident Resource: "Lag! Your Animation Overrider"
This class was written in September 2011. Since then, viewers like Emergence and Phoenix succumbed, so the bits referring to them can be safely skipped. I've kept them for the sake of completion, since this was the original material I used to teach. The text hasn't been updated, but hopefully some ideas will still remain interesting to know about. Please forgive my 2011-English (Of course, suggestions to correct it are more than welcome.)
Also, I've decided to set out the original supplies for this class in a box at the store, within the books section, for free. Head over here and get the class supplies if you wish to follow the practice. The items are inside a Black Tulip textured box.
Lag! Your Animation Overrider
Welcome everybody. I am Auryn Beorn and I'll be your instructor for this class.
It's a while since we're discussing in some classes about the sources of lag, and what we can do to avoid it the most possible (as much as us, as residents, can do about). It all began as an unique class that was intended for 90 minutes. It went for three hours and the AO topic had no time for being discussed, so I've finally found the moment to do it separately.
As you sure know, "lag" is the common word used to name a slow reaction time when we're using an online application, like Second Life, World of Warcraft... anything like this that you can think of.
The fact of existing a slow reaction time means that "something's happening", either at client side, or at server side. The reasons and main culprits are discussed in detail in the class "LAG! Every script counts" and will not be the focus for this class.
In other classes we see why the scripts are such a big deal, as well as which effects and properties assure us that we can remove scripts from the objects if necessary. Also, we all know about resizers being the evil, etc, etc, regarding the avatar appearance, more specifically.
This class is to study what an animation overrider is, and what we can do to create a low scripted animation override, as well as be conscious of why we're asked to take it off when in crowded places, among other details.
What is an Animation Overrider?
When we all get to SL, we're gifted with walking like ducks and standing like robots.
We, as avatars, have a predefined set of states that can be animated: Walking, standing, sitting, jumping, turning to left, turning to right, crouching, hovering, etc.
But the default animations are not... How to say... Specially glamorous.
Not even human (I know nobody walking like ducks.)
So, since scripts allow to animate avatars, and scripts allow to control your avatar keys, people smarter than the designer of the default animations decided to script what is called an "animation overrider" (and better animators, to create decent animations.)
So there we have them again: if we want to walk like humans, we need to wear scripts attached.
Why are they always a target of the requests for detaching scripts?
We know that an important problem we have with scripts is... If there are many, they fill quick the memory. That's why it's so important to proceed deleting as soon as we can the resizers, specially the older ones, with one script per child prim.
But sometimes, just reducing the script count is not enough. We may have an animation overrider that only needs from two scripts (and we're preparing such an AO here, at class), and still, 40 avatars wearing the AO is an issue.
What does the AO have that makes it being so painful?
A 0.25 seconds timer (or even more frequent!)
That means: Per avatar, the server needs to pay attention each 0.25 seconds to all of our animation overriders.
Why such a small time?
Because that's a reasonable time for the script detecting a change in our state, so it can stop the previous animation and run the appropriated one.
An example for what I mean with this: When we are walking, it doesn't make sense to play other than a walking animation. But as soon as we stop walking to, say, sit, the walking animation should be stopped, then the sitting one animation initiated. Those state changes happen quick, that's why the script needs to be asking for our current state so often. That's why nobody would program an AO script and give the timer 5 seconds, to reduce lag... The requirements for an AO mean a timer that runs quick.
So yes, we can cut down the total of scripts that our AO's have, and that will of course improve the memory usage for the server, but we still have the problem of the timer.
Still, to focus all what we're discussing here, let me try to advance the "sections."
On one hand, yes, because reducing the script count is important, we're seeing how to make a "script cut" version of our AO's, and we'll do it here.
But also... We've said that the AO is requesting each 0.25 seconds our state.
If we detach the AO, yes, problem solved.
But AO's can be deactivated, not needing to be detached.
If we get an AO that needs only two scripts (which is a good thing!), we could simply deactivate it when not needed, and that way, the timer, which is the biggest load for the server this time, won't be active also, right?
So one may wonder, when could we just deactivate a two-scripts-AO, to help with lag?
Like... Right now. We're all sitting, right?
So if we're all the time sitting, why make the server check each 0.25 seconds if we're sitting or not?
I mean, at class, to say an example, we're pretty much aware of when we're sitting (and for a long time! At least at my classes :P )
We could make an habit of this:
- Sit
- Deactivate AO
- Stand up
- Activate AO
(I know I have an animation active, but I'll say why in a moment)
There are many situations where we spend our SL's sitting on something:
- A chair
- A couch
- A poseball dancing
Among others :P
Why not deactivate the AO in those situations?
Just by doing that, we'll help a lot the server.
For each state, there are default animations. When we sit on a prim, by default, there's a sitting animation that will be activated on us. This can be changed by a script that starts a different animation than the default one.
So having the AO overriding poseballs scripts is not a good idea, since the poseballs themselves have a script to animate our avatar.
We're now completely aware that by creating a script-cut version of our AO plus getting the habit of deactivating the AO each time we *sit* (which is often), we're helping a lot reducing lag.
Also... Some viewers have a client side AO. That's even better!
Emergence, Phoenix, Firestorm and Singularity have client side AO.
That is what I'm using: the client side AO... So that's why I have my sitting animation on... :o)
Not because I was setting a bad example, but because I have the client AO on!
The client side AO relies on the bridge script, which all the users of those viewers always have on. So, since the viewer can take care of the keys we press and that script already can communicate with the server to be aware of state changes/notify of the new animation to play, why use an inworld AO?
Ok, so we've identified a problem: script count + timer.
We've thought about a possible solution: script cut + deactivate when not necessary/client side AO when possible.
Creating a low-scripted version of our Animation Overrider
Usually, we don't need more functions from our animation overrider than actually... let it override the animations. Dances, facial gestures and other extras are not much needed at a class, shopping or maybe even roleplaying. Even the dances may be an option... as all the dance places already have danceballs... why overload the place with more scripts for that?
So we can create a low-scripted version for our animation overrider, that will cut the script count for it from the usual 20 scripts the AO's have, to only TWO. Now think on a crowded club, and think what if all the avatars use a cut-script version of their AO. We're talking about a serious reduction of the number of scripts. Not as spectacular as when we remove the resizer scripts, but yet, important.
And the best of all! We don't need to renounce to our animations. We don't need to walk like a duck in a club. So let's do *here* the work of creating this low-scripted version of our animation overrider. Once we're finished, you all will have an AO to choose, depending on how crowded do you expect to be the place.
I've chosen creating a couple of prims to hold within the open source animation overrider ZHAO-II, that you can find as the object "AO base (ZHAO interface)" included in the class supplies. All the animation overriders need from a notecard that tells which animations we're using for each state, and the ZHAO notecard type is, by far, the most widely used.
So... Let's begin with how to create a script-cut version of our AO. This work will be useful EVEN if we have a client side AO, since the notecard that we are going to create now has THE SAME FORMAT than the one the client AO requires.
If any of you has, by chance, a no copy AO attached, the following links contain two really basic AO from Vista that can purchase, so we can do the practice here, not risking your own AO at class!
For the girls: https://marketplace.secondlife.com/p/VA-VISTA-BASIC-FEMALE-AO-V08-basic-line/298453
For the guys: https://marketplace.secondlife.com/p/VISTA-MALE-BASIC-AO-V08-basic-line/298450
2014 NOTE: If you have a no copy AO, do not try to do this with it unless you're sure that there's no maintenance going on. One way to know if there's any kind of maintenance going on is by checking the SL status page. Keep in mind this: If there's any issue in the grid, it takes some time until LL are notified and they update the status page. If you notice any kind of inventory issues, or that you cannot attach/detach items... DO NOT REZ no copy items! Wait until you see an update announcement in the status page, and then refresh the page until making sure the issue is resolved.
What should we do, then?
Try not going ahead! We'll follow each step slowly.
Rez a copy of your own AO on the ground: It will be a small thing, so don't lose it from sight :-)
Not the AO from supplies: Your own AO.
Right click on your AO, and select "Open". It will take a moment to load everything.
Do we all have open a window that is loading a (most likely, long) list of animations, some scripts and notecards?
When you have that list loaded, click "Copy to Inventory".
That will make a whole copy in your inventory: once the copy is all done, you can take your AO back.
REZ the object "AO base (ZHAO interface)" from the class supplies and edit it.
Drop all the *animations* from your AO within the same prim that has the two scripts "ZHAO-II-core 7/29.1" and "ZHAO-II-interface 7/21.1".
Just the animations that we've copied in our inventory, at the moment. Let's wait a moment for the notecard.
Now we need to set the notecard.
Since this notecard we're setting is going to be full perms, we can do this step now in our inventory (we can drop FULL PERMISSIONS items within an attached HUD: it's only when the items are NOT full perms when we have to rez it to add contents.)
Before taking the AO back into your inventory, rename it to something that makes sense for you. For example, you can rename your HUD My Script-Cut AO before taking it into your inventory. This is just so you know this will be your script-cut AO with your animations.
Once renamed, take it.
The last step is editing a Default notecard, for it to be contained in the AO, so we can load it once finished, following a specific format.
Create a notecard in your supplies folder named Default.
You can choose other name if you wish, but keep in mind that this notecard name will appear as a button option in a dialog window, so DON'T USE more than 24 characters for the name of the notecard!
I've included several sample notecards in the supplies to show different formats that our AO's may be using: we'll refer to them later.
I've also included a notecard named Default - Sample from supplies: This one has the exact format that ZHAO-II expects from it. So let's study first the format of this notecard, and then we'll study how to "translate" our own AO notecard to this format.
Please, open the Default - Sample from supplies notecard.
After opening it, you all see that it has several lines, and all those lines have the same structure.
That is:
First, between [ and ], it has a word, a very specific word that has to be written as you see there, with the spaces around, exactly as there.
Those special words, like Standing, Walking, Falling... correspond with the states that our avatars allow to have animated, and we have to write that exactly as we see there:
[ Standing ] [ Falling ]
etc.
Then, after the closing ], we specify which animation corresponds to that state. That animation has to be in the inventory of our AO prim: In the same prim where the scripts are, and we have to use the same exact name that the animation has.
Many states only allow one animation, and ZHAO-II will complain if it finds one of these states having specified for it MORE than one animation. Fix the notecard is simple here: make that state have just an animation, as ZHAO-II indicates in its error message.
But a few allow several animations. When a state allows several animations, what the AO does is, usually, to cycle between them.
Which states have multiple animations allowed? Stands, walks, sits and ground-sits.
How do we assign more than one animation to the states that allow so?
As we can see in the notecard, simply separating each one of the animations we want for the stand, by the | (pipe) character, like the sample from the supplies that you have now open:
[ Walking ]08WALKSEP4|08WALKELEGANT|08WALKSEP2HIPS|08WALKSEPBACK|08WALKHAPPY&SEXY|08WALKH&SHIP|08WALKH&Spocket|08WALKhead|sexywalk
This means that, for the Walking state, ZHAO-II will cycle among the animations:
08WALKSEP4 08WALKELEGANT 08WALKSEP2HIPS 08WALKSEPBACK 08WALKHAPPY&SEXY 08WALKH&SHIP 08WALKH&Spocket 08WALKhead sexywalk
And that means also, that we should have those animations in the AO prim, OR THERE WILL BE RUN-TIME ERRORS (that are visible, AND VERY ANNOYING, for many users, in their local chat!)
Also important: the animation names can't have spaces between them and the | to join all of them in the same line.
Another note: the Standing state admits more than 12 animations (walks, sits and ground sits are limited to 12), but we have to add up to 12 per notecard line, as we can see in the example notecard open (to overcome a LSL limit about reading notecards):
[ Standing ]VACOOL1.1xF|VACOOL1.2xF|VACOOL1.2bisxx|VACOOL1.3xF|VACOOL1.4xFx|cool27|VACOOL2.2F|VACOOL2.3xF2|VACOOL2.3x2F|VACOOL2.4FX|VACOOL30 [ Standing ]cool6Fbis|VACOOL9b|VACOOL9|cool4.2F1|cool4.2F|VACOOL4.4|cool7|cool6F08|VACOOL2.4Fxxx|VACOOL2.4Fxx2|VACOOL4.4FAUG2|VACOOL1
NOTE: Where the pipe | character is located depends on our keyboard. Some keyboards have it pressing ALT GR + 1, others have it pressing SHIFT + BACKLASH. Check your keyboard configuration for this matter. As a last solution, you can always copy/paste it from this notecard: |
Ok up to here? Clear the format of the notecard, as a start?
Following is the complete list of states that can be animated for our avatar, updated to 2011-08-15, according to the wiki (source, here: http://wiki.secondlife.com/wiki/LlGetAnimation )
Crouching Hovering Hovering Down Hovering Up Jumping PreJumping Running Sitting Sitting on Ground Standing Striding Standing Up Flying FlyingSlow Falling Down Landing Soft Landing CrouchWalking Turning Left Turning Right Walking
2014 note: This list remains valid nowadays.
Striding is when the avatar is stuck on the edge of an object or on top of another avatar. About Standing: After falling a long distance, the Landing animation state is skipped and the Standing Up state is used.
IMPORTANT: This means that additions from specific AO's, like turning when swimming or diving, are not a state controlled by a "normal AO script" (like ZHAO-II), but a specific extension of such an AO that also checks the water level in the timer (by using the llWater function: http://wiki.secondlife.com/wiki/LlWater )
Now... How do we "translate" our own AO notecard to this format?
Some AO's will make this task easy. Others will require more work from us. I've prepared several sample notecards that show different formats, and then included how the "translation" should be done.
The notecards (no modify/no transfer so you don't confuse them with the one you have to use in your AO) are:
ORIGINAL AO NOTECARD "TRANSLATED" AO NOTECARD -------------------------------------------------------------------- VISTA AO - Example VISTA AO - For ZHAO-II VISTA - Old Format Example VISTA Old Format - For ZHAO-II GuyMocaps - Example GuyMocaps - For ZHAO-II MyAO Default - Example MyAO Default - For ZHAO-II
The easiest case comes from AO's like Vista which, from the 2.0 version, use the same format that ZHAO-II expects, with a single exception: the [ Typing ] state, which is NOT acknowledged by this ZHAO version.
Open the Vista AO - Example and VISTA AO - For ZHAO-II notecards to see that the differences are minimal. Easy peasy, this case. But sometimes we'll have to do more work.
Close those notecards, and let's open now, to compare, the VISTA - Old Format Example and VISTA Old Format - For ZHAO-II notecards.
To mention an example, notice how the following block in the Vista - Old Format Example notecard:
:: [ Standing 1 ] :: casual stand 1 :: [ Standing 2 ] :: casual stand 2 :: [ Standing 3 ] :: casual stand 3 :: [ Standing 4 ] :: casual stand 1 :: [ Standing 5 ] :: casual stand 2
has been translated to the following in a ZHAO-II notecard (Vista Old Format - For ZHAO II in your supplies, removing duplicate animations):
[ Standing ]casual stand 1|casual stand 2|casual stand 3
Similarly, we'd translate the rest. More work to do, but still, easy.
NOTE: When translating an AO notecard to ZHAO-II format, don't forget that only standing, walking, sitting and ground sitting are the states that allow us more than one animation, but none of the rest!
Some AO's may have a notecard format that differs a lot from the standard ZHAO-II format.
To illustrate this, we can check, for example, how the My AO Default - Example notecard refers to the normal and ground sits:
[Sit.N]D1479-Sit.N,D1480-Sit.N,D1481-Sit.N,D1482-Sit.N,D1483-Sit.N,D1184-Sit.N [Sit.G]D1485-Sit.G (185cm),D1486-Sit.G (185cm),D1487-Sit.G (185cm),D1488-Sit.G (185cm),D1489-Sit.G (185cm),D1490-Sit.G (185cm)
and how this should be written in our ZHAO-II notecard, as the MyAO Default - For ZHAO-II notecard shows:
[ Sitting ]D1479-Sit.N|D1480-Sit.N|D1481-Sit.N|D1482-Sit.N|D1483-Sit.N|D1184-Sit.N [ Sitting On Ground ]D1485-Sit.G (185cm)|D1486-Sit.G (185cm)|D1487-Sit.G (185cm)|D1488-Sit.G (185cm)|D1489-Sit.G (185cm)|D1490-Sit.G (185cm)
There's another example in the supplies, GuyMocaps - Example which, as an example, has the walking animations as follows:
a,cartwheel,drunkwalk2,fliprun,handstdwalk,MDHUskip,morpheuswalk,mwalk2MC,mwalking1,mwalking3,mwalking4,mwalking2
and this should be written this way in our ZHAO-II notecard, as the GuyMocaps - For ZHAO-II notecard shows:
[ Walking ]cartwheel|drunkwalk2|fliprun|handstdwalk|MDHUskip|morpheuswalk|mwalk2MC|mwalking1|mwalking3|mwalking4|mwalking2
Check these examples on your own in case you need it.
Once we're done getting ready our ZHAO-II notecard, wear the AO we've got ready with your animations.
Edit it, click the "Content" tab.
Rename the empty Default notecard from the AO included in the supplies to Empty (it's always a good idea to have a clean reference of the notecard format.) Supplies have also a copy of this empty notecard, Empty - Keep it as base to start with!
Drop this Default notecard we've created from our AO's configuration after translating to what ZHAO-II expects.
Close the "Edit" window.
Click the white "page" button from the AO. Select "Load" from the menu it shows, then select to load the Default notecard.
Ready to go.
Client Side Animation Overrider
Now, why have I insisted this much in having clear the format for the ZHAO notecard?
Because if we're using Emergence, Phoenix, Firestorm, Singularity... We may use a client side AO, and this client side AO requires a notecard with the SAME FORMAT that we've now studied, so all the work made before can be used for this too.
How do we make it work?
IMPORTANT 2014 NOTE: As time went by, each viewer has developed/polished their way of setting up a client side AO, and so the following information might be obsolete/inaccurate. Please DO REFER to the documentation of each viewer for the most current information, if what's explained below doesn't correspond to what your viewer shows. The text below is kept because that's how things worked back in 2011, for the sake of completion with class text, as explained in the opening.
First, we have to copy the ANIMATIONS AND THE ZHAO-II NOTECARD WE'VE CREATED in a special folder. The scripts are not to be copied there.
This folder depends on the viewer we use. So far, I've compiled this list:
Emergence #emergence Phoenix #Phoenix Singularity #Phoenix FireStorm #FireStorm/#AO
Now, either click CTRL SHIFT O (letter o), or select Phoenix: AO / Emergence/AO / Singularity/Animation Override... from your menu.
That brings up a window.
Do you see a zone of that window saying Drop a ZHAO II Notecard here?
That's it: drag the notecard directly into that zone of the window. We're not done yet! But almost.
Now we have to click "Reload" to make sure the notecard is loaded (still, one more step to follow!)
There it is a "Override Anims" check box below the Reload button. We have to click it!
If we get warnings, that might mean that some animations we've said in the notecard are not in the viewer folder.
Once the notecard is loaded, then we can check clicking "More" for the default animation we want for each state, and if we want to randomly cycle among them. That's it all what we need to have the client side AO working.
And this is all!
You don't need to be ashamed of having an AO and walk like a duck anymore: Now you know how to be as glamorous as animations allow us, at low-lag cost!
-- Auryn Beorn