Currently, all Animation Overriders ever written in the past 20 years (aye, 20) rely on scripts that require accurate information about what exactly the avatar is doing (i.e., moving, walking, idly standing around...), polled several times per second, in order to swiftly override a standard/default animation with a new one. This is a major source of lag, especially considering that current-generation AO HUDs additionally suffer from texture bloat, increasing the wearer's ARC, and so forth. Certain third-party viewers, which shall remain unnamed, have 'fixed' this issue by embedding the AO in the viewer itself — running fully client-side and not relying on any in-world scripts to do so. They don't have a HUD, so they're not sexy and flashy and cool-looking, but they can read from the same notecard format as LSL-based HUD AOs, and, strictly speaking, they're a great way of reducing lag. So long, of course, that people are aware that such an option exists and are familiar enough with how AOs are configured. Please consider overhauling the whole concept on the viewer side only, so that LSL-based HUD AOs become completely irrelevant. Think of an interface like you have for the Gestures — some kind of viewer-side pop-up window which can load the "standard" animation overrider notecard, and, well, do its magic. Exactly like certain TPVs already do. In fact, as you're considering to introduce RLV to the official SL Viewer... why not AOs as well? Note: There is not even the argument of what happens if an animation hasn't loaded — what will other users see? The answer is trivial: everybody already has the standard animations from 2002 pre-loaded. If someone's AO animations are slow in loading for some reason, your viewer will default to displaying that avatar using the default animations instead. In fact, that's exactly what happens today, when someone else's viewer, though that resident's AO, instructs our viewer to load animation X for avatar Y. If X is already in our cache, good, it will be shown. If not, it falls back to the default animation. There is absolutely nothing that you need to change on the overall code logic! And, of course, you don't even need to reinvent the wheel — just grab the code from the TPVs and use it. It's been there for eons — well before smilies! — and for eons we have had to struggle with LSL AOs and spread lag all over the place. Then: Promote it . It's useless to have a wonderful new technology which reduces animation overriding effectively to zero lag if no one knows about it. Grab the main suppliers of AOs in SL and announce the 'new' system, so that they also spread the news among their customers. They will only need to provide the notecard with the configuration and the animations inside. Note that the TPVs even allow multiple sets of AOs to be configured, and people can freely switch across them (it's even easier than locating that specific AO in your inventory... what was it called again?). This issue has just one drawback I can find: some AOs are rather sophisticated and go beyond what is usually offered on the 'standard' AO configuration notecard; their HUDs are especially designed to allow access to those nifty extras, and have great visual impact. So be it — soon (or so we hope) we'll have the Lua-scripted viewer, and such special effects are perfect for content creators to deploy their ultra-laggy HUDs. But to do that, there needs to be an embedded AO in the viewer itself first. And then, of course, the first thing to do is to get rid of those AOs on the 'free' avatars that come as standard when a new user registers... they should be the very first to use the 'new' system. Well, new for the SL Viewer, that is. Some other feedback/suggestions which are vaguely related to this one: * https://feedback.secondlife.com/feature-requests/p/animation-system-overhaul P.S.: The attachment is just a note on the history behind the Animation Overrider. It might be useful, amusing, or totally irrelevant, so feel free to ignore it 😅