ClientAO

Finally decided to try it today and it's great, I'm ready to start a lag reduction revolution!

An AO, or Animation Overrider, as we have come to know it, is a ridiculous beast of a script that rapidly checks to find out what animations your client (viewer) plays, stops them, and plays your preferred animations instead. It's not pretty because your viewer is choosing the animations, they get rebroadcasted to everyone in range, the script is rapidly polling to see what your animation state is, the message to stop the first animation gets broadcasted to everyone in range, then the message to start the desired animation is broadcasted to everyone in range. I think we're all in agreement it's a hack, and needlessly wastes script time and net time!

Needless, because clients should just play the animations they want instead!

ClientAO is a plugin for SLProxy that replaces your animations client-side, eliminating the problems associated with a scripted AO.

* It's smooth
* I don't have problems with sitting animations being overriden when they're not supposed to be
* No bugs with animations not stopping when they're supposed to

I'm going to explain how to use ClientAO for Windows users, but I understand it's not precisely the solution everyone wants. To support configurable animation in the Second Life viewer, vote for this JIRA issue: https://jira.secondlife.com/browse/VWR-386

If you'd like to compile SLProxy and ClientAO yourself, checkout libsecondlife trunk here: svn://openmv.org/libsl/trunk/ (you may find the ClientAO source is a little corrupted at the moment, see http://jira.openmv.org/browse/LIBOMV-252 )
To learn what slproxy is, check this: http://www.libsecondlife.org/wiki/SLProxy

Or if you're ready to try ClientAO without having to compile stuff, I've compiled it along with slproxy and uploaded here:
---> http://tooskilled.com/bin/SLProxy-ClientAO.zip <---

1. Extract SLProxy-ClientAO.zip into a folder. You should have:
* SLProxy.exe
* SLProxy with ClientAO (it's a shortcut to make life easier)
* libsecondlife.dll
* ClientAO.dll

2. Double-click the shortcut named "SLProxy with ClientAO." This runs slproxy and loads the ClientAO dll. You should now see a console window saying that the proxy is ready! Leave it open.

3. Browse to the folder for the Second Life viewer you use. For me, this is C:\Program Files\SecondLifeReleaseCandidate. In that folder, find your "shortcut" to the viewer application. Most likely you want to look for a hand icon with a little arrow in the corner.

4. Right-click and "Copy" it, then right-click and "Paste" to create a new copy of that shortcut. Rename your copy to something like "Second Life SLProxy" so you'll know it's different. Right-click the copy and open its Properties.

5. Click in the field for 'Target' and add this text to the very end:

And click OK You can make a copy of this shortcut on your start menu or wherever you want.

6. Use your new shortcut to run your Second Life viewer, and log in. If you're using the latest Release Candidate version of LL's viewer, the menu bar should be red. (Don't close SLProxy until you've logged out!)

7. Once logged in you want to create a folder in your inventory, and copy the contents of your AO into it. The folder should then have your animations and configuration notecard inside. What I did, I just rezzed my AO, right-clicked it and chose Open, then clicked Copy to Inventory. This created a top-level folder with the animations and notecard in it.

8. In chat, give the command "/ao <path to notecard>"
For example, my folder is named "Shogun AO" and the notecard inside is named "ED Shogun AO"

You should see a message in chat saying the animations were loaded.

9. In chat, say


What do you think?

It looks pretty good.

Does it handle the stacked animations like ZHAO II and others? I.e. allow multiple stands/sits/walks etc, and change between them on a timer?

If above is yes, is there a way to change the timer without recompile?

Will it allow an external system to override the animations, i.e. a dance system?

I find it much easier not to use an AO at all. I know I may look like a newbie but I like the regular old fashioned LL way of walking and standing.

All I use is a freebie walk replacer. As far as I know there is no way to turn it off without detaching it...........and I never have to do that. I can dance and play other animations without it interferring at all. I happen to like the default avi stand. And I never really sit down in SL unless it's pose ball.

I think AO's are a waste of lindens and resources.

It does do multiple stands, when the viewer does. It's as if you change those default stands into something else. No way to change the timing unless there's a setting in the viewer for it

It seems to play along spectacularly with things that override animations, to me. So far I can say it works exactly how I expect it to, but I'm not very familiar with priority and stuff. I'm interested to hear others' experiences in that area

Looks like it is sniffing for animation packets from the sim and responding by starting other animations, so it's whatever the client and server decide on their own for stand changes.

Grabbing animations from the sim would mean that the double download lag isn't eliminated, but it will still save a few script cycles (makes sense to grab them from that end because not everything is initiated by the client). No walk killing pops out, so I'm guessing this AO has the backwards walking glitch (too lazy to log in and play with it right now).

It's currently using the old Franimation notecard format so only one animation can be fired at a time.



Nothing explicitly there for that, but there's no reason why something like that couldn't be added.

Freebie walk replacers are AOs, using the same looping as one populated with more animations. You do avoid the interference by not having replacements defined for anything but the walk, but you're still grinding away at the script machine like the rest of us

Hmm, I had a friend try ClientAO and his notecard format wasn't supported. It didn't occur to me that might happen. Here's a blank copy of the type of notecard it uses:

Ok, fixed the build file for mono and fired it up. The stock animations are still being run, so it really is just sniffing on the server side and playing user animations on top of the stock ones just like any other AO out there. and it is leaving the stock walks running so the backwards glitch is there (meaning, if you press the down arrow you look like you're doing some kind of Michael Jackson impersonation).

Nice proof of concept but it probably wants delegates capturing both ends of the conversation so that it could make an actual improvement for other avatars in the area.

Oooh... You're right D: I assumed it was as simple as replacing the animations in outgoing packets, now I'm really curious

I realized that i must sound like I'm pooping on this thing, that's not the intent. It looks like a great start, it's more that some nice features could be added, nothing would really need to be ripped out.

Here's a question for all the scripting geeks. As I mentioned before I only use one AO (the freebie walk replacer). You just told me that that animation is grinding away at the script machine.......and I understand that part. However, don't the default walks, stands, sits and all also grind away at that same script machine? I just cannot see a difference. A script is a script........it's running anytime the user is using it no matter if it's default or not.

A few of the basic animations (the most basic walks, main stand, etc.) are fired off by the sim when it decides that you are moving or not, but it does that inside the main server code without having to run any LSL, so it's all done in nice fast native code instead of the slower interpreted stuff we get to use for scripts.

All the little fidgets, alternative stands, and the little intermediate things we do when we land or change direction, all the things that makes the default av not look like a bot, those are fired off by a rather complicated little AO that's built into the viewer (and yes, even the official viewer uses a little bit of same packet sniffing we've been complaining about in this thread). But because the viewer starts most of those, it's our own machines instead of the sim that has to do most of the work. There are tons of animation start and stop messages flying around because of just the defaults, though.

wow this is a very interesting thread..you make it easy to understand a lot of things that have had me curious about ..
it's good to see them explained in more laymen terms or ways that make it easier to understand =) thank you

As usual your cleverness and insanity produce excellent results <3

I must say that AOs are something that certainly _should_ be handled client-side if at all possible - I cannot see any negative potential here that could not simply be replicated via LSL.

The biggest "grinding away" that happens in an AO script is constant polling of avatar animation state to see when there's something that needs overriding. There's a jira feature proposal, http://jira.secondlife.com/browse/SVC-408, that seeks to make this event-driven, rather than polled. (The win of a client- vs sim-side AO is that arrival of an animation packet at the client can be used as such a triggering event.)

Not making any sort of insinuation about the OP, or the product, or libsl... but did ANYone even bat an eyelash when someone (could've been anyone) said "here's a precompiled 3rd party file, install it on your computer so it is runs when SL runs, then enter your username and password and login to SL..." ?!?

Wow..
Obviously this one is ok, but the fact that anyone installed it at all without being involved in it's development, or being able to pick the useable package apart piece by piece and read what it does speaks tons about peoples personal security habits.

I actually read the source and compiled my own copy, and haven't seen anyone in this thread say that they ran that thing blindly, maybe missed it? But we're talking about Day Oh here, not some unknown party.

Yep, so what is the problem again? People decide who they are going to trust or not, they do that whenever they even use what LL offers for download!

And those niffty little utilities they find with a Google search too. How about me, I downloaded The GIMP..........that is an open source, precompliled program. Everyone, at one time or another hears about some online program that someone recommends and they go out and get it.......suppose that says the same thing about those people too.

I'm pretty careful about security........but, I know there ain't no guarantees.

I'm Day Oh ^^



<3, though I didn't write ClientAO

Wait, did Qie write it?

The source credits Gilbert Roulot

Sorry brain fart, but it still applies =)

Ok, some more notes after modifying that plugin to snag outgoing packets. libsl does parse these correctly, so those can be intercepted and replaced from that end.

The stand stuff in the client is enormously chatty. Since it picks stands randomly and doesn't keep track, it stops every possibility _frequently_. So, an AO might do well to discard the client stands, and do its own thing based on the server-supplied default.

Even for basic movement, though, the client's messages can't be completely ignored for substituted animations. For example, the server sends the start message for landings but the client sends the end message. That explains some weird behavior that LSL AOs have to work around, must be packet loss on the way to the sim.

I downloaded the code and compiled it, after reading through it. Also changed my password before starting it, and then again after I switched back to main viewer.

There is always an element of risk in anything you do - you have to just decide if the risk is worth the chocolate at the end

That would be why i said "unless you go through the sourse and pick it apart to see what it does". Don't assume that everyone who tries this can even READ source or even knows who Day Oh is please. In every one of those cases, a "please be careful about installing something from any 3rd party" is most definately warranted.