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.