More and more Third Party Viewers (TPV) have built in Animation Overriders (AO). A huge problem for those of us that use multiple viewers is the problem of each viewer having unique AO folders. There is no standard AO folder. Milkshake names their AO folder Milkshake, Phoenix’s is named Phoenix, Firestorm’s is Firestorm…
New AO's
If you have walk’s and stand’s that are no copy, you were screwed. You were forced to have different animation sets for each viewer, which sucks. This is the main reason I still use my ZHOA-II HUD. It is available in any viewer I choose to use. Plus I only need to set it up once.
AO Animation Configuration Tool
I also avoided using built-in AO’s because I have a couple of favorite animations that are no copy. Fortunately more and more animations are provided as copy-ok. The super cheap (L$10 mostly) animations in Kuso are copy \o/. Eventually I’ll find replacements for my no-copy fav’s. (I was new when I bought them.)
AO’s Change
I haven’t been keeping up on Viewer AO’s. When they first came out I played with them, ran into problems, and stopped using the built-ins. At some point things changed. While playing with the Milkshake Viewer I decided to try the built-in AO for one of my Alt’s.
New Milkshake Logo
Milkshake has a nice AO system. I like it and was surprised several times. I’m not sure who wrote the code or which viewer had the system first, that just doesn’t matter to me. Sorry programmers, no offense or diss intended.
No Note Card
The AO in Milkshake is the ‘No Note Card’ style AO. This is a huge plus in my thinking. I do not have to write a note card copy pasting animation names into a list with complex formatting. I can drag and drop animations into the AO panel.
Named AO Setups
Also handy, I can create multiple setups. Previously this was done with multiple configuration note cards. The note cards are gone but multiple configurations are still around. It is just way easier.
Ready for Drag & Drop
You will notice there is a drop down menu that lists the various animations styles; standing, sit, landing, etc. You must select the proper category before dropping your animations in. This then places the animations in folders within the MilkShake AO Folder. Each category has a folder.
Links
Stands Added
Links, and this is a big, this AO uses LINKS. I can use no-copy animations in any built-in AO that uses links. The original animation is never moved into an AO HUD or special folder. It can stay in inventory and a link is used in the AO folders.
Inventory Shows Links in Use
If you look in the Milkshake inventory the animation appears in the AO as a link. The animation is not copied to the Milkshake folders. A link, a sort of pointer, is used. This means I can have the same animation in several different viewer’s AO’s. \o/ I may be able to give up my ZHAO.
Needed
It would be nice to have a way to play an animation from within the AO. When it is open like in image captioned ‘Stands Added, a right click on an animation to play in-world or locally would help with the set up. Or even a Show Original.
Cycling Setup
It would also be nice to get a standard AO system across all viewers. As it is now, I must set up and AO in each viewer. I suppose that could be seen as a handy thing allowing one to use a specific viewer for a specific Alt. It just doesn’t work for me.
Summing It Up
AO’s have improved since my last look. I think they are not quite there yet. But, they are way better.
Just thought it worth-while pointing out, Milkshake, Exodus, Dolphin & Firestorm all use the AO system you’ve described here.
Links also mean the set-up is largely automated: if you have (a) copiable ZHAO II notecard(s), simply drop it/them into each AO panel when open – the necessary links and folders will be created automatically. You can then swap and change by choosing the required AO from the drop-down list and clicking RELOAD.
I currently run two AO systems (Kuso and NK) with little pain or upset this way – the only niggle is that you *do* end up with multiple copies of the animation links sitting under each Viewer’s dedicated #folder structure.
So there’s a “sort-of” emerging “standard” among later Viewers – use of dedicated “#”folders in inventory notwithstanding :).
I’ve no idea if the system has been backported to any V1-based Viewers. As far as I’m aware the system hasn’t been added to Phoenix (which still has its original client-side AO), and I believe there are no plans for doing so
Singularity Viewer 1.6.0(3) have it
Thx 🙂
the Milkshake AO sounds very much the same as the Firestorm AO http://wiki.phoenixviewer.com/doku.php?id=animation_overrider which also uses links
The problem with current viewer-side AOs is that they break many scripted items (especially BDSM related ones that change your avatar anims, such as cuffs) and can’t cooperate with other, scripted AOs or devices designed to cooperate with scripted AOs (especially with the Lockmeister booton/bootoff commands).
The true, and definitive solution can only come from LL: it would be to allow, for each avatar, to let their user define their default animation (this requires a server side feature that currently doesn’t exist).
For this reason, I decided that a viewer side AO was for now not an interesting feature to add to the Cool VL Viewer.
Thanks! I did not realize the viewer AO’s created problems. I seldom wear a collar or similar toys, so I have not seen the problem.
Do you know if we have a JIRA for such a change? I’ll look through the JIRA, but if you have a preference…
@Henri, you are aware that client side AOs greatly reduce server lag over scripted prim based AOs. And that it is very simple to choose animations that can be overwritten by your ‘cuffs’ or ‘furniture’ and/or these AOs have an OFF button.
Just because the scripted in-game LAG inducing AO’s can automatically turn off in a small percentage of bondage gear, you deny everyone else access to a lag reducting quality of life increasing port of this AO code?!
Men suck.
Well, I can see that you forgot to add some cons for this feature. Basically, it is rather more likely to be affected by the lag, since the very simplified data flow is like this:
Starts Animation > Sends to server > Goes to other clients
This way, it basically also adds your lag to the animation change time. So the total animation change would take this time: YourPingToSL + SLServerProcessTime + ClientPingToSL.
Now with normal scripted AOs, your own ping to SL goes away, since the animation that is supposed to be played is processed on the servers and sent to the clients.
Rather than this, the Linden Lab should provide us with the possibility to change the default SL anims and remove the need of using AOs (unless in special objects – guns, horses..) as whole.
I talked to Kelly Linden about this problem. He hasn’t looked at the various implementations of viewer side AO’s. His… takes, I’ll call it, is that viewer side AO’s would be better in some ways, especially in regard to scripting. But, he can see pro’s and con’s. He doesn’t know which is better.
Your point is well made that there is a communication load added. But, there is a script load that is removed. Without some solid metrics I’m not sure we can know if it is a net gain or loss of performance.
Hello!
The animation overrider you see in every snowstorm based viewer comes courtesy of Zi Ree who wrote it. It was first implimented in NaCl.
In my (now private viewer) development I’m working on a way of expanding RLVa to listen for a signal from special RLV gear to switch the client-side AO on and off when the gear tells it to. If this goes well, I will opensource the code for the tpv community. 🙂
Zi originally and first implemented the AO for Firestorm: http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/76982197b786