AOs – Animation Overriders – have been part and parcel of Second Life since not long after the dawn of time (or at least not long after someone figured out how to lose the duckwalk by one means or another).
Today, AOs are a fact of life in SL and come in many forms: some just handle the “basics” – walks, sits, stands; others combine functions, providing a one-stop solution for walks, sits, stands, dances, poofers and other little toys. Most run through scripted HUDs, some run via the client itself. Some handle just one set of animations, some can be configured with multiple sets of animations, driven by notecards; some even allow drag-and-drop. Beyond this there is a whole range of scripted attachments which may also contain a wide variety of animations, often for specialised use, but which also might contain walks, sits, and the like. Finally, and most recently, we have the rise of client-side AO systems, some of which have differing capabilities to one another.
It’s a bewildering plethora of approaches – although in the case of HUD systems and client-side AOs, most use the same core system of animation interpretation, the famous ZHAO (2) format.
As to advantages and disadvantages, all systems suffer from them to one degree or another. Client-side AOs for example, can override scripted animations, resulting in an avatar appearing to jerk around or behave strangely as the two animation clash. Some AOs can be script-heavy – at least in terms of the number of scripts they contain; this can lead to finger-pointing by those with an eye on public or client-side script counters, regardless of how efficient the scripts may actually be in terms of resource use. Recent developments in Client-side AOs mean that drag-and-drop is fully supported – no need to send time and effort configuring notecards; the downside is, each TPV supporting the system tends to require a dedicated set of links within your inventory – so if you do swap between Viewers (using one for RP, another for photography, for example), then this can become a source of annoyance.
Now it appears that Linden Lab are considering the question of AOs, and whether to develop an approach of their own. This has been hinted at in the number of user group meetings, and is now the subject of debate over on the SLU forums.
Some have taken LL’s interest – expressed through Oz, as a sign that the Lab are looking towards a client-side implementation of some form of AO (perhaps animation controller might be a better description) with the Viewer. However, as Adeon Writer notes in opening the discussion, LL have both the client and the server at their disposal, so are relatively free to approach the issue from any number of angles without being exclusively tied to a client-side solution.
A variety of ideas have been suggested in the SLU thread – some of which run very close to capabilities found in the latest client-side AO system; whether this is because people are happy with that system and wish to see it replicated, or whether it is because some are unaware of the client AO capabilities, is unclear. One idea that has gained support is for having a “wearable” attachment that allows animations to be associated with specific avatars have also been put forward (so you have one associated with your “normal” avatar, another if you have a “pixie” avatar, another for your “tiger” avatar, and so on), with an edit capability similar to any other wearable editor.
The problem here, of course, is that not only are there many potential routes towards a solutions – there is also the veritable minefield LL must tread simply due to the widespread use of scripted AOs and HUDS. If they are seen to be doing anything that is perceived to be about to “break” or “compete” with existing content, regardless of how wrong such perceptions might be, they are liable to find themselves being chased up a tree faster than a cat with an oversized dog on its tail…
Those at the Lab are obviously aware of this and it’s liable to be a reason why the matter hasn’t been dealt with before; despite claims to the contrary, the Lab is actually loathe to knowingly break content. It’s also most likely why Oz is taking time to understand the flavours of client-side AO used by TPVs in order to find out what works, what doesn’t, and how LL can work alongside existing HUD systems.
However you look at it, it is fair to say that something needs to be done to improve the current means by which AOs – client-based or HUD-based work. Neither is, from the perspective of the new user, a particularly elegant solution and requires something of a learning-curve in order to understand. Developing an alternative that is both easy to grasp, and which offers a high level of functionality for the sophisticated user, however, isn’t going to be a simple matter – if only because we all have differing needs from an AO, and the needs of the novice user don’t always sit well with the needs of the seasoned user.
For my part, I long ago gave up the use of an AO HUD in favour of a client-side solution, as the latest AO found in most v3.2-based TPVs offers me the greatest flexibility, occasional clashes with scripted animations notwithstanding. However, I do have the advantage in having several pre-prepared ZHAO-2 notecards, so switching over to (and switching between) client-side AOs is relatively simple. Given that the AO also supports multiple configuration cards, switching between sets is also easy. Which is not to say this approach is perfect; two of my irritations with it remain:
- There’s the aforementioned inventory bloat when dozens of duplicate links are added to my inventory each time I opt to use an AO notecard with a Viewer equipped with a client-side AO
- There is no persistence between relogs when running multiple AOs – the client will default to the first AO notecard / set in the list, regardless as to whether I’ve set a default or not.
Personally, I’d like to see a well-implemented animation control system from LL; they have the resources at their disposal to develop something that works fast and well and can meet the widest range of requirements from ease-of-use through to minimal resource demands. Perhaps even one that is extensible and takes into account purpose-based uses such as within combat environments (although that might well tread on a lot of toes). It’s not going to be an overnight thing – again, full kudos to Oz for feeling matters out on the technical side. It’ll be interesting to discover what – if anything – does develop down the road, and whether we will see anything emerge from LL in terms of AO system development / implementation.
Inara Pey: Living in a Modemworld 
Reblogged this on Becca's Blog and commented:
Really interesting article. This is the kind of thing that I’d like to write, but I don’t have the ‘inside info’ to do so.
LikeLike
Becca,
TY!
It’s not so much “inside info” as having a lot of time on my hands! The best way to find out things is – and I say this not a little sadly – not so much to look to LL for information, but to keep an eye on other blog and places like the SL Universe forums and the more arcane SL forums (such as the Merchant’s forum). You’ll find more information about what is happening wrt SL actually outside of SL (with the possible exception of the Merchant’s forum) than you’ll get via any “inside” info.
LikeLike
Aww, I think you do yourself a disservice; I find your blog a great source of info!
I usually confine myself to writing little tips and hints articles. I would write more but, to be honest, it’s a little disheartening when nobody reads it. LOL.
But with so many people blogging that isn’t hugely surprising – it is so hard to get heard.
LikeLike
It does take time to build a voice – are you active on Twitter, Reddit/secondlife, Plurk? They are good ways of getting your voice heard.
LikeLike
No, not on any of those. Well, apart from in SL itself of course. LOL. But thank you! I know it is hard to get yourself heard.
It would be nice if some people found my posts useful and it enriched their SL a tiny bit – I’d be more than happy with that.
LikeLike
‘ they have the resources at their disposal to develop something that works fast and well and can meet the widest range of requirements from ease-of-use through to minimal resource demands.’ 🙂 You are an optimist … good for you
LikeLike
I do try to be a “glass half full” person, even when I’m poking LL in the ribs…!
LikeLike
LOL
LikeLike
I use the Sinful Needs A4 HUD as my AO primarily because it automatically turns off my AO when dancing and back on when I stop dancing. The somewhat unpredictable way in which animation priorities have been assigned over the years can mean that separate AO and dance animations may conflict with one over-riding the other unexpectadly. The A4 HUD solves this problem by combining the dance and AO HUDs into a single all-in-one HUD. It also supports a lot of other features I do not use much like control of wings and all kinds of demon stuff.
But, my point is not to promote a particular product. Rather, I would encourage AO developers to address the issue of dance/ao animation conflicting priority. Maybe that’s already been done – I haven’t really played around with the client-side AO feature in Firestorm or other relatively new AO implementations.
LikeLike
HUDdles does (or did) the same. But you raise an interesting point on priorities – when the scaling was introduced (1-4), it was to give flexibility to animations and prioritisation. This appears to have been lost, inasmuch as every nowadays appears to be set to priority 4, so “stacking” animations, so to speak, isn’t really possible.
LikeLike
It’s great to see that LL is finally addressing this ancient issue 🙂 The first commercially available AO was developed in the late summer of 2004, thanks to a “trick” that was found in the LSL library of functions; user-generated animations were a novelty introduced in June 2004. This “trick” was kept secret for some months until it was independently discovered by a resident who will remain anonymous 😉 which was then incorporated in the first open source AO, the Franimation Overrider developed by Francis Chung in the autumn of 2004, which in turn was modified later by Ziggy when HUDs became a novelty, and turned into the ZHAO, for years the base of all other AOs. As early as late 2004, people had been demanding that LL produced a far more easy way to “switch animations” since the standard ones, well, to be blunt, suck, and always sucked.
For almost eight years we’ve been waiting for the ‘Lab to address this issue — not necessarily because the current AOs are “bad”, but mostly because, well, they generate unnecessary script lag. My personal issue with all AOs (HUD-based or client-based) are not in the technology by itself, but in the complex priority schemes that LL has developed for the animations. I wish I had more time to participate in the current discussions with Oz, but let me just briefly explain what my issue is.
When animations were launched in June 2004, the idea is that they wouldn’t override everything in your avatar’s body. As you can see, for example, the standard “clapping” animation will only override the arms and hands; the “winking” animation will only override the head, etc. This was something actually very cleverly done by LL: it would allow, if animation creators did things properly, that animations could be used cumulatively and not interfere with each other, and give us a far wider range of “body language”. Properly done, you could be dancing and blowing someone a kiss: the way animations work, these can work independently of each other.
But this requires setting animation priorities properly, and making sure that only certain skeleton elements are actually animated. What the vast majority of animation creators do is to take full control of the whole skeleton, and fix the priority as the highest possible. That’s one reason why I hate chairs and sofas in SL — they will “lock” your avatar into a specific, priority-4 animation, and the careful collection of sitting animations that I have collected over the years will be simply ignored. Put into other words: chair and sofa designers think that they are entitled to choose the way people sit of them and restrict our right to express ourselves freely, by setting the animations and not giving us an option to choose the animation we have, but just pick one from a list they feel to be appropriate (this is one reason why I tend to stand up on most meetings or sit on the floor, refusing to be “controlled” by whomever designed the chairs in an audience).
Why is this related to AOs? It’s very, very hard to find AOs where animations “play nicely” with the priority model, and that only address the skeleton points that they’re supposed to be manipulating. The earliest versions of the Franimation Overrider and the ZHAO already allowed animations to be “played together” and allowed some cute effects, if the animations were properly configured by their creators. You could, for instance, be standing up in a nice pose, but brush your hair occasionally (a separate animation), pick your nose, etc. — these would not be “full animations” but just manipulations upon a “base” animation. When changing AOs, if the new AO respects this model, your “partial animations” would still continue to work with the new AO; this allows for a lot more personalisation by adding your own set of very personal gestures on top of what others have created. So two people using exactly the same AO and the same “base animations” would still exhibit different body language.
Of course this is just important for “personalisation freaks” like myself 🙂 I have perhaps some 50 or so animations (many developed by myself) for those special gestures now and then; they will only work with some AOs (and their animations) but not others. I’m currently using several different AOs from Oracul, because I think their base anims are cute, but all the sitting animations have the wrong priority and my own personalised gestures will not work when sitting down. I’m lazy and haven’t looked for alternatives; but I’m aware that most animators and AO sellers simply don’t care. They just upload everything at priority 4 and “lock” all skeleton animation points.
Nevertheless, if LL is willing to take a look at how AOs work, I think that they should really give us a way to change the priorities the animations work with. Currently, the priority is set when uploading the animation, and is part of the asset. But it could be decoupled from the asset and be a client-side setting. The skeleton animation points are harder to change, since they’re defined by the difference between the first and the second frame of the animation, so clearly this is harder to do; but, in most cases, switching an animation from priority 4 to 3 or 2 is enough to make all other independent gestures work fine in any situation. And this might be doable if LL changes the way animation work. For backwards compatibility, the original priority can be used as a “default setting” — thus avoiding to break content for old viewers.
I don’t know what might be the “best” way to implement client-side AOs. I’ve toyed with them, mostly on OpenSim, and I like the “backwards compatibility” model using a “standard” ZHAO notecard. However, notecard-based configuration is easily prone to errors. It would be so much easier to have a completely new drag-and-drop interface to replace the anims at will, but of course this would mean it would be harder to switch AOs easily when we change avatars. I agree that a better solution would be to make the AO settings a wearable item, just like alpha layers or the physical layer, and allow that to be configured with a drag-and-drop interface at will, but perhaps this is simply too hard for LL to implement — I have no idea. It’s certainly possible to develop a HUD with a drag-and-drop interface that avoids notecards, but I have not seen yet anyone doing something like that, because programming such a complex LSL-based interface would not only be very laggy, but not easy to accomplish; on the other hand, it would be much easier to do it client-side.
As someone who has patiently waited almost eight years for LL to tackle AOs, I’m naturally very eager to see what they come up with 🙂
LikeLike
Ta for the background – I admit, AO history is something I’ve not deeply delved into. I would say that I’m not entirely sure that AO HUD are quite as heavy resource-wise (script lag) as perhaps they once were – or at least, the more recently-coded systems may not be. Nalates Urriah did some testing to show that resource-wise, her AO HUD has little overall impact. We’ve also seen changes to the way in which scripts are handled server-side which may also help ease things.
The priority issue is one I didn’t address in the article – and it’s a pertinent point; as designed, the system did allow for animation “stacking”, but somewhere along the line the idea was lost. I can actually remember reading the Help notecard for a collar which actually recommended setting all additional animation placed in the collar to priority 4, regardless of original settings. Hence, priority setting became something of a vicious circle: wearable attachments being set to upper priorities to overcome AOs or sits, AOs and sits being set to higher priorities to prevent wearables overriding. I’d certainly like to see some form of system developed that places control – as simply as possible – in the hands of the user. But again, achieving that with a relatively simple and non-intrusive interface isn’t going to be the easiest thing in the world.
Like you, I’m eager to see what emerges.
LikeLike
I have to be honest.
I still think the best Ao is the free Sub ao from open collar! Not only you can add multiple notecards and animatons, has have much more useful functions, as the couples menus, but i also love Rlv and the way it allows Me to place my beloved ones on poses that they can’t see yet due to more rezzing time on their side.
And is completly free!
Still as i go most of times on places where a simple rule is sused, no Scripts at all, I have and got used to any Client side Ao, from the phoenix 1 to (for me the best, Firestorm one and recently Imprudence as on Open sims, even if there is Hud ao’s there, client side are a must as most places just don’t allow any scripts at all!
Still would love to see a reply from Henrry Beauchamps, the creator of Cool viewer, that i belive has a strong negative openion about client side Ao’s use!
But be Sub Ao or client one, is really time for the Lab to aproach this matter, cause their animations are simply out of date to say the least and i can figure a newcomer arriving, watching some avatar wlking amzingly well, realizing that it does ot have anything to do with his/her walk, and quiting Sl for good thinking its to hard!
And i have a full perm sub ao, a full perm Zhao and a full perm clinte side (folder with animations and notecard) that i can offer to any that wishes to use, on Sl and many more on OSgrid, so any can Im me and ask for one or how to set a clint side ao for the 1st time as i made a Notecard explaining step by step how to set up one!
You can’t imagine how many old residents still don’y know how to get ride of all scripts, even the simple detach of firestorm bridge can be a nightmare for same and how to use a client side Ao!
LikeLike