AO

[Elspethian Kalinakov]

I know this has been talked about before and apologize for starting it again: I'm back on SL after a number of years. 

I haven't figured out AO, I think it's called, and instead just stand there. Is it something I need to buy, turn on, spin around three times and wish on a star?  Sorry for being specious: socially it's been a very disconcerting night. It would be nice to get something simple working and need help.

Kali

 

[Marianne Little]

1 hour ago, Elspethian Kalinakov said:

I know this has been talked about before and apologize for starting it again: I'm back on SL after a number of years. 

I haven't figured out AO, I think it's called, and instead just stand there. Is it something I need to buy, turn on, spin around three times and wish on a star?  Sorry for being specious: socially it's been a very disconcerting night. It would be nice to get something simple working and need help.

Kali

 

Yes, you buy it. Prices vary from very cheap to expensive. You will see that many AO's are marked "Bento". Unless you buy a mesh avatar, you do not need Bento.

The Marketplace is where you find many AO's or Animation Overrides.

If you are on a budget, I link you to a lovely blogpost that explain step for step how to make your AO for 2 L. https://ryanschultz.com/2020/04/12/second-life-steals-deals-and-freebies-how-to-make-your-own-bento-animation-override-for-only-l2-step-by-step/

This title says "Bento Animation Override" but Bento does not do anything for a default avatar. Nothing with "Bento" in the name does anything for default avatars. "Bento" is a new set of bones that, among other things, can animate every finger separate. Bento animations animates your fingers. For an avatar that is not set up for Bento, the animations work on rest of the avatar, but not with the finger part.

So you can use the tutorial over, and it works just fine on you.

If you are in the market to spend money, come back and ask for more expensive options.

 

[Anna Nova]

An AO is basically a set of animations and poses that are set off by a script when your avatar changes state: Standing, Walking, Running, Turning, Sitting, and many others.  SL provides a default set, but most people think they are 'wooden', so there is an aftermarket.

Firestorm viewer provides a built-in script, but you need to supply the animations.

@Pussycat Catnapoffers a free, full perm AO script.  All you need are some animations and a bit of editing.

But guessing from your question, these are not your skills right now.

[Nalates Urriah]

Marianne and Anna have it right. But, since you seem a little unfamiliar with SL Jargon I'll repeat what they have said with different words and add a bunch.

AO = Animation Override. There are default animations for the avatar. This is what you see if you have no AO. It is a very stiff walk, a dumb run, and stands with very little movement. It is these default animations that most of us override as a first change to our avatars.

AOs are usually a HUD, control interface that attaches to our screen. There are old ones and new ones. There is a point when the tech of SL changed and how AOs work changed. All the new AO's, post tech change - that I have seen. are script heavy. So, I still use an old ZHAO II (free if you look around) when I am not using Firestorm's Viewer. It is debatable which places the least load on the system.

Firestorm built an AO  into the viewer. So, there is no HUD to clutter the screen or scripts the SL System has to run. Plus it uses the new tech which puts way less load on the SL servers. Additionally it uses LINKS to load the animations into the AO. So, No-Copy animations are not a problem. There is no note card setup or AO HUD to rez out and setup. I am saying it is one of the easiest to setup AOs in SL.

Most AO's come with a set of animations. You can buy and add more. They are provided as individual animations and single animations by most animators. Some animators make them in sizes. Usually; small, medium, large. Plus Tiny and Giant for special avatars. Those animators usually tell you what size avatar each size is for using avatar height. A few put a millimetre number in the animation's name. I hope this idea gives you a sense that it is important your avatar needs to proportionally correct for a human.

How animations are added to an AO varies. I think one can wing their way through setting up the Firestorm AO. But, with most of the others you WILL need to read the directions.

Lots of furniture and other things in SL have animations built into them. Those are triggered when you sit on the item.

Then there are POSES... these are animations that hold the avatar in a static position. Many of the images of things in SL you see around are a picture taken where the avatar is posed with a POSE Animation. There are even HUDs just for poses.

I think it ideal that I can separate my poses and movements into separate HUDs and I need to do different things them. My movement animations are mostly automated. I have several Stand Animations in each of my AOs. The AO automatically plays the animations in a sequence, which breaks up the monotonous movement using just one stand animation creates.

There are categories of animations. I am not aware of any formal designations. The ones you asked about are considered basic movement. There are Dance, Modeling (poses), Hugs, and sex animations to suggest a few. Some AOs make sections for basic movement and dance. I find separate dance HUDs work better as I usually want more manual control of my dancing than most combined HUDs offer.

There are huge animation stores in SL. You can get on a 'pose stand' to test the animations in these shops. I find shopping for animations REALLY tedious.

I hope this gets you up to speed. Welcome back.

[Pussycat Catnap]

9 hours ago, Anna Nova said:

Firestorm viewer provides a built-in script, but you need to supply the animations.

@Pussycat Catnapoffers a free, full perm AO script.  All you need are some animations and a bit of editing.

But guessing from your question, these are not your skills right now.

https://marketplace.secondlife.com/p/Cycling-Animation-Override-Script-Modern-ZHAO-Replacement-w-llSetAnimationOverride/19961890

This is free, fullperms, you even get the code for the script. It's done to replace the old ZHAO AO and the Firestorm AO. Both of which rely on playing an animation - which means they break when there lag or some transition delay from something happening too fast or some data failing when changing regions

(In Firestorm, I used to get this all the time as my AO getting stuck playing the falling animation until I relogged)

In OLD ZHAO... your animations just flat out turn off when you enter a no-script area.

Linden Lab fixed that...

in 2013...

And yet almost every AO out there hasn't been updated since about 2005 or so...

The 2013 method doesn't play animations, it sets your defaults to something different - so it keeps working when scripts are not available.

 

So I just took the 2013 fix Linden Lab made, and put it in a a free fullperms script that I made to be controllable through chat commands. Nothing needed on your screen, no button to click... and when you log in, it gives you a help message. If you chat to it but give it a bad command, it says the help... (basically if you just type /3, this AO assumes you wanted to know how to use it).

There's also this one from @NiranV Dean of Dragon Viewer:

https://marketplace.secondlife.com/p/NirAO-Server-Side-Animation-Overrider/6310433

He does the same thing. Just uses LL's 2013 code to give us an AO that finally does it right. The difference between him and me is he had a HUD with a button.

- You can read his code also. Like me he was hoping AO makers would throw their old crap ZHAO script out of the window of a skybox at 4096m up... ;)... and use something that actually works right...

 

1 hour ago, Nalates Urriah said:

Plus it uses the new tech which puts way less load on the SL servers.

Unfortunately this is actually most likely not the case.

Firestorm's AO is playing animations, using some kind of ancient hack that itself isn't even as good as straight out calling the script to play an animation... It doesn't set your animation state - which is why it can often glitch out. A LOT of people notice that between Firestorm and almost any other viewer, your FPS goes down 10-50% when using Firestorm. This is not the only reason, maybe not even a big reason; but it's yet one more contributing factor.

The only benefit Firestorm's AO is offering you is that it's not a button on your screen... it's instead a button on the edge of your screen.

 

Edited July 25, 2020 by Pussycat Catnap

[Marianne Little]

1 hour ago, Pussycat Catnap said:

------------------------------------------------------------------- snip

Firestorm's AO is playing animations, using some kind of ancient hack that itself isn't even as good as straight out calling the script to play an animation... It doesn't set your animation state - which is why it can often glitch out. A LOT of people notice that between Firestorm and almost any other viewer, your FPS goes down 10-50% when using Firestorm. This is not the only reason, maybe not even a big reason; but it's yet one more contributing factor.

The only benefit Firestorm's AO is offering you is that it's not a button on your screen... it's instead a button on the edge of your screen.

 

Wait. Are you saying that FPS can go down if I use Firestorm's AO? 😲

[Pussycat Catnap]

11 minutes ago, Marianne Little said:

Wait. Are you saying that FPS can go down if I use Firestorm's AO? 😲

You're loading that code even if you don't use it. Your FPS goes down just using Firestorm itself. Not the AO specifically - I'd wager it's just one of many reasons why Firestorm is slower.

It is not just 'doing a whole lot' (because Dragon Viewer is ALSO doing a whole lot and yet competes with 'Alchemy' for 'best FPS out there'), it's doing it with a lot of different code written by different people and coded inconsistently...

And the Firestorm AO, is not made elegantly. I can see that from a user POV in how it glitches - which is enough to tell me it has some flaws. Others who have looked at it code wise have relayed even deeper concerns to me. Am told it's code is some of Firestorm's oldest code. Perhaps dating to the Emerald Viewer era or the Phoenix Era, based on a hack, when if totally rewritten it might be doable without such.

Turning it off won't help your FPS... it's there whether you use it or not. Turning it off and using an AO that uses the 2013 llSetAnimationOverride WILL improve your animation responsiveness: http://wiki.secondlife.com/wiki/LlSetAnimationOverride

 

If @NiranV Dean shows up in this thread... he'll probably correct me 😮 , but also expand on the point of why the Firestorm AO is not a good choice to go with. 😉

 

Edited July 25, 2020 by Pussycat Catnap

[NiranV Dean]

I haven't looked at Firestorm's AO, i generally don't look into their code unless it comes through official implementation, so how exactly the AO works is not known to me but i would have expected them to rework it after all this time, given that the old way is highly inefficient if its true that its based on a hack rather than simply sending a play request like animation previews do. Even sending an animation request is still slow and prone to lag. After hitting a key the Viewer has to process is which is usually pretty fast and what we perceive as instant (although it is not, there is input lag but that's a whole different beast), ontop of that comes that the Viewer has decide which animation to use then prepare and send an animation request, all of which should be once again basically instantaneous (for us), however... before the server can process said animation request it first has to go to the server, which is where your ping comes into play (thats usually 200ms for me) in this time your basic non-AO animation might start playing (if the Viewer purely bases everything on what the server does) before its replaced with the desired animation upon receiving the go from the server. Normally you wouldn't see this as the Viewer plays the animation locally while sending said request, basically predicting that the server is going to agree on playing the animation and doing it right away. Now depending on how the AO is doing it delays might come into play everywhere making the whole AO seem very laggy and unresponsive (which is also an issue of normal AO's). The server side AO functionality that my AO uses circumvents all of this by replacing the baseline animations directly on the server, which means instead of playing the default animations, we play the replaced animations. This eliminates the back and forth between viewer and server as the server only tells your viewer to immediately play the right animation rather than the default ones. Not only does this eliminate a lot of the communication between server and client, it also saves scanning or otherwise watching your avatar status, this frees the entire AO up making it basically useless after you've pressed the "on" button and replaced all animations. This is why server side AO's have a super low script time footprint (at least mine does) since the AO doesn't do anything other than reacting to your inputs on the HUD. My AO however does scan for strafing movement while jumping (to allow strafe-jumping) and whether you are in water or not to replace your flying animations with swimming ones. Typing is also scanned for because it cannot be replaced either. All of this however is done at low intervals and is done as fast as possible to keep the cpu time as low as possible.

To the topic of framerate. Again i dont know what the FS AO does but virtually anything can reduce framerate if done wrong. Technically speaking, the Viewer watching the avatar animation states shouldn't even be noticeable but again i have no idea what the AO really does. I try to keep newly added features either completely separate from the main viewer cycle or to an absolute minimum if they have to actively run. Technically speaking nothing impacts your framerate as long as it doesn't run at the time of testing. Code in windows only ever runs whenever said window is open, so does most of the rest of the code. Most of whats actively eating your framerate is rendering or display related stuff, like rendering UI widgets, rendering text, world, world updates etc.

[Nalates Urriah]

@Pussycat Catnap and @Marianne Little - If I remember correctly the Firestorm's AO was built (rebuilt?) to use the new tech, replacing the default animations server side and doing no polling. So, I doubt you get any hit in performance viewer-side. This done about 2012... may be rebuilt in 2015...

Since I have Firestorm and some AO loads in it, I ran off to test. I do various viewer test from time and have 3 places I use to check frame rates. The safe hub at Nelsonia, my front porch, and in a skybox. FS 6.3.9 gives me  about 34.7 fps today with the AO engaged and  the same with it disengaged. Attaching the ZHAO II, running it engaged and disengaged... no FPS changes. Doens't seem to matter where I am. Turing the AO on off makes no difference.

I see  no 10 to 50% change. 

We can ask @Whirly Fizzle or @Ansariel Hiller about what the Firestorm AO does and how.  

I recall my 2015 article on Akeyo's new AO. 

[Pussycat Catnap]

@Nalates Urriah You'll see that 10-50% switching viewers. Firestorm, Alchemy, Dragon, Catznip, etc...

Not AOs.

Firestorm is just too loaded down with features. It's better to find a viewer that has the features one wants, rather than one that does everything.

The 'new tech' came out in 2013, so if they rebuilt in 2012 their AO is still playing animations and not using llSetAnimationOverride.

Niran notes the 'delay' between client and server and so on... that happens when you tell it to play an animation the old way, and not use llSetAnimationOverride . Firestorm has that delay. It's actually more noteable with the built in AO of Firestorm than it is with the old ZHAO scripted 'playanimation' AO - suggesting there's an added step in there somewhere.

Firestorm's AO does have a sticky animation glitch. On Teleporting you can get stuck in the falling animation. I've sometimes been stuck in other animations too, but most often the falling one. Across multiple installs, different computers, different alts. It's an intermittent issue that occurs. A built in AO is just a bad idea... this issue will happen in any of the other viewers that copies this concept as well - not just Firestorm.

 

Edited July 26, 2020 by Pussycat Catnap

[Chaser Zaks]

DISCLAIMER: I am part of the FS team(Specifically on the bug squishing team), while I will attempt to be non-biased, these have always been my views even before being part of the FS team.

Firestorm's AO is actually quite efficient, as it off loads the AO state checks to the viewer it's self(not that the code is CPU heavy). It can be used without the bridge even, so there is zero scripts involved. I have no idea where the claims that it is using scripts to do AO stuff is from.

Theoretically, the FS AO is actually faster than script based AOs as there is no LSL VM(either LSO or Mono). LSL has clock speed limits to prevent it from killing the simulator. Although I am unsure if it really matters that much, because we are talking nanoseconds in difference.

If you'd like to review the code yourself, here are the relevant files:

XUI Code:

• https://vcs.firestormviewer.org/phoenix-firestorm/files/tip/indra/newview/ao.cpp
• https://vcs.firestormviewer.org/phoenix-firestorm/files/tip/indra/newview/ao.h

Engine code(Where the magic happens):

• https://vcs.firestormviewer.org/phoenix-firestorm/files/tip/indra/newview/aoengine.cpp
• https://vcs.firestormviewer.org/phoenix-firestorm/files/tip/indra/newview/aoengine.h

I believe this code is relevant to setting up AO templates?:

• https://vcs.firestormviewer.org/phoenix-firestorm/files/tip/indra/newview/aoset.cpp
• https://vcs.firestormviewer.org/phoenix-firestorm/files/tip/indra/newview/aoset.h

All animations are handled by the LLAgent::sendAnimationRequest which uses the AgentAnimation message. This is how the viewer plays every other animation that isn't triggered by the simulator it's self.

While true, it isn't perfect and there are some bugs here and there(such as it sometimes pausing if the viewer is minimized, however this is due to how the viewer handles being idle), I personally find it as good as any other AO. All things have bugs, it is impossible to iron them all out, especially on a code base as big as SL. You squish one bug, two more appear in it's place.

If you do see bugs related to it, please do file a Jira issue regarding it here: https://jira.firestormviewer.org/

Also I have found that crouching/uncrouching(just tapping c) will often cause the AO to wake up if it somehow went to sleep.

Edited July 26, 2020 by Chaser Zaks

[Zi Ree]

Thanks Chaser, that was a pretty good summary. The FS AO had its fair share of bugs pre 6.3.2 which mostly were fixed in 6.3.9. A few more remain and will be fixed going forward. But it surely does not use "some kind of ancient hack", it simply uses the same commands as the system animations do, just replacing the system animation UUID with the one in your AO. So it pretty much is just as fast as the system animations are. The only delay you see is the time it takes from pressing a movement key to the server sending the animation command to your viewer.

 

[FairreLilette]

22 hours ago, Elspethian Kalinakov said:

I know this has been talked about before and apologize for starting it again: I'm back on SL after a number of years. 

I haven't figured out AO, I think it's called, and instead just stand there. Is it something I need to buy, turn on, spin around three times and wish on a star?  Sorry for being specious: socially it's been a very disconcerting night. It would be nice to get something simple working and need help.

Kali

 

If you are going to stay a Classic avatar, Marianne is correct in that you don't need Bento.  Bento can be more expensive and those AO'S are for mesh avatars.

This link I am going to post here has 1 linden each AO'S you can try.  I noticed she also has some ten linden ones as well.  The name you will see on this Marketplace Store has AO'S you can test for about 200 lindens each inworld.  

This link I am providing is the main AO store I use.  Great stuff for great prices.  But try inworld for a 200 linden AO; it's a pretty unbeatable price.  She also has Bento AO'S inworld for about 300 linden.  I modify mine by taking a animation out and replacing with one of my own; but that's too advanced to get into for a beginner.  But, if you ever learn, you can customize these on the cheap as they are so cheap to begin with but they are still great on their own as is.   

Here on the MP, she has some 1 linden ones like I've already said but you can't try them before you buy them.   I have used the Lady AO and The Delicate Lady AO and been happy with the time I spent using them.  

https://marketplace.secondlife.com/stores/193066

Edited July 26, 2020 by FairreLilette

[Maitimo]

4 hours ago, FairreLilette said:

If you are going to stay a Classic avatar, Marianne is correct in that you don't need Bento.  Bento can be more expensive and those AO'S are for mesh avatars.

Just to clarify though, a Bento AO will work on a classic avatar just as well as a non-Bento one will, so there's no need to avoid an AO just because it says it's Bento. You won't see any individual finger movement or face expressions but everything else will work just fine.

[Lillith Hapmouche]

While I don't experience a noticeable performance drop when using Firestorm and the AO, this glitch that Pussycat describes sounds very familiar: 

11 hours ago, Pussycat Catnap said:

Firestorm's AO does have a sticky animation glitch. On Teleporting you can get stuck in the falling animation. I've sometimes been stuck in other animations too, but most often the falling one. Across multiple installs, different computers, different alts. It's an intermittent issue that occurs. 

I've encountered this more than before in the past couple of months. Actually, I blamed it on overall server performance and animation states not properly synchronising.. 

[Gabriele Graves]

Firestorm does have the features I want though.  No other viewer I have tried comes close to offering all the little extras I use with FS and supports Linux.  Is it perfect?  No, there are definitely things that can be improved but you can say that about any viewer and what makes a good feature set is very subjective.  There may be faster viewers, there are viewers with some unique features that FS doesn't have but overall for me FS hits well in a lot of areas that make it a great choice generally.

I have used the FS AO as my sole AO for years and while the earlier versions definitely had some glitches.  Since around v6.3.2 however it improved greatly and I haven't noticed any appreciable issues since then.  There is no noticeable delay or lag that I have seen either.  Nobody is going to convince me that a script based AO is faster or better than one built into the viewer code.  This is must have killer feature for me and no other viewer I am aware of has it.

I am known for being critical when it is warranted but credit where it is due, FS does a great job.

Disclaimer:  I have no link or affiliation to the firestorm team except as a satisfied user.

Edited July 26, 2020 by Gabriele Graves
Corrected version number.

[NiranV Dean]

38 minutes ago, Gabriele Graves said:

Nobody is going to convince me that a script based AO is faster or better than one built into the viewer code.  This is must have killer feature for me and no other viewer I am aware of has it.

There is no need to convince you to that. A script-based AO that uses the Server-Side AO functions (llSetAnimationOverride) IS de-factor better, faster and infinitely more reliable than anything a Viewer could ever do because the Viewer A) cannot do the same without using scripts itself (the bridge for instance) because it relies on the only way the Viewer can tell the server to play an animation and B) the AO only does a single thing once per login and then never again needs to do anything, there is no overhead, no idle state, no polling, no nothing, the AO can be detached and continues to work unlike the Viewer AO which has to continue to run, check for animation states and has to send animation requests every time it wants to play something which is prone to delay, fail (packet drops) and uses up bandwidth (although super super tiny).

I wish LL would finally give us a new reliable message type that allows us using the server-side AO functionality within the Viewer without using external scripts. I'd be writing a Viewer AO almost instantly. That's all i'm waiting for.

Edited July 26, 2020 by NiranV Dean

[Gabriele Graves]

29 minutes ago, NiranV Dean said:

the AO only does a single thing once per login and then never again needs to do anything, there is no overhead, no idle state, no polling, no nothing, the AO can be detached and continues to work unlike the Viewer AO which has to continue to run, check for animation states and has to send animation requests every time it wants to play something which is prone to delay, fail (packet drops) and uses up bandwidth (although super super tiny).

Yes you can detach the AO completely.  If, and only if, you want to define a single animation for each AO state such as your stands and you don't intend to change anything whilst logged in so you can detach the AO and never use it again until you relog.

However, this isn't how many (can I hesitantly use "Most"?) people use AOs.  It isn't how I use my AO.  I like my stands to cycle.

Many people have, at the very least, cycling stands which will have to change the llSetAnimationOverride for stands each time the timer runs downs (incurring one of those fail-prone requests each time), oh did I mention a timer? that's needed to switch the anim for the stand in that scripted AO, so there goes that idle state and lack of polling as well.  In addition, the AO object with it's textures and scripts need to be worn to do that.  This is not even mentioning if you want to make a change to anything which will then require llSetAnimationOverride to be setup again, after the script has read it's notecards again of course.

So in practical terms, you haven't gained better performance.  You haven't ditched the scripted object at all and it isn't idle nor has it stopped making periodic requests and it will guaranteed be using textures, it will have notecard reading code for when things have changed and will be using a HUD attachment point.  This is all presuming that in your bid for efficiency you don't have any scripted UI at all and would only edit notecards to change things.

So I am at a club and I want to switch to dancing.  I like my dances to cycle.

The FS UI allows me to easily switch AO sets and it does that without needing a HUD to be responsive, without using the crappy llDialog UI with truncated text or without needing to edit my AO and wait for it to reload everything from the notecard I just changed and then reset the server-side AO with what I want.  Switching AO sets is instant and it keeps a timer going that doesn't use a script so that I can automatically change dances and because of that I don't have to wear a scripted object for that.  The FS AO UI is just that much better than fiddling around with the alternatives.

So I am not clear on what are the practical gains of using scripted AO that uses llSetAnimationOverride vs FS built-in AO unless I want a really basic AO that wouldn't work for my use cases.  It isn't even clear to me that FS couldn't or doesn't even use the same mechanism as llSetAnimationOverride to set the server-side AO.  Even if both methods used exactly the same mechanism, the FS AO still wouldn't be any worse on performance and still wins hands down for the UI and not needing to wear a scripted object running timers, wait for it to read notecards or to change the anims in any way.

However, my bad.  What I should have said is: "Nobody is going to convince me that a script based AO is any faster (when you want cycling animations) or better than one built into the viewer code (with a decent UI to make changes with)".
 

[NiranV Dean]

1 hour ago, Gabriele Graves said:

Many people have, at the very least, cycling stands which will have to change the llSetAnimationOverride for stands each time the timer runs downs (incurring one of those fail-prone requests each time), oh did I mention a timer? that's needed to switch the anim for the stand in that scripted AO, so there goes that idle state and lack of polling as well. 
 

So do i, my AO has stand sets too. While yes a low-key timer has to run down, a llSetTimerEvent set to whatever time you want to pass before stands are cycled is basically non-existant in cpu usage. Besides, you didn't explain how "polling" is not saved here. There is no need to poll for any information, you set a timer to lets say 20 seconds once (or whenever you change your stand cycle times) and incur a single llSetAnimationOverride when said timer runs out. Said single llSetAnimationOverride is completely fail-safe and cannot fail regardless of your ping or your connection, the script already runs on the server, there is no need to do a costy communication attempt between your client and the server and it eliminates the potential fail of packet drops unless of course bugs (but we don't count them since bugs can be in anything, both client and server). I don't know how exactly the server works and how it handles timers but from a technical standpoint it is impossible to run down a timer without at least some minimum checking whether said timer has run out, the time it takes to do said check however is so miniscule that you wont even be able to test the time it takes to do it without incurring a massive cpu time yourself with the test to test the cpu time (funny that). So we're talking about microscopic unmeasurable impacts. This is still infinitely faster than letting the Viewer do it since the Viewer has to be specifically set up with an extra timer and AO function to do this, the server i can almost guarantee you has a timer running at all times anyway (due to other things requiring it anyway) so it would come down to a single time check against said omnipotent timer.

Aside from the fact that its a nice to have being able to take the AO off if necessary like if said AO wastes all your resources.

1 hour ago, Gabriele Graves said:

So in practical terms, you haven't gained better performance.  You haven't ditched the scripted object at all and it isn't idle nor has it stopped making periodic requests and it will guaranteed be using textures, it will have notecard reading code for when things have changed and will be using a HUD attachment point.  This is all presuming that in your bid for efficiency you don't have any scripted UI at all and would only edit notecards to change things.
 

You have gained performance since you've eliminated a whole AO system and several checks in the Viewer and replaced it with a single tiny time check on the server, this is as optimized as optimization can get apart from outright removing it. Said check if true will incur a single llSetAnimationOverride call. Said "periodic requests" are limited to whatever time your stands should cycle. Which the Viewer has to do too with the difference that the Viewer has to send an animation request which is once again prone to fail and lag, which llSetAnimationOverride isn't since its not dependent on your connection to the server. You eliminated lag and added a fail-safe while freeing the Viewer up of any additional tasks.

The notecard reading code is again only a one-time thing, that is only ever incurred whenever something changes as you say, this is done when the notecard is first loaded before the AO is even started. There is no need to constantly re-read the notecard, there is no need to even look into the notecard unless you are importing one. Everything can be saved into lists and "cached", this uses absolutely minimal script memory. My entire AO with imported notecard uses roughly 40kb. That's laughably efficient compared to literally anything in SL. Just look at all your fancy face/eye/body HUDs how much they eat and how laggy they are. Once again this memory can be cut down (my AO has several extra features for convenience and some that the Viewer simply cannot offer like strafe jumping) or completely taken out by detaching the AO if you are willing to give up stand cycling for the time being that is.

Now to the topic of texture memory usage. I don't know how much memory your AO's need but mine currently uses a single 256x256 texture, thats ~64kb texture memory. Once again laughably little and if i wanted to i could reduce this even further by cramming the states further together and eliminating unused space. 128x128 seems very possible to achieve and would only use 16kb. That's less than the AO uses script memory. That's as much as your Viewer AO will need with all the new fancy new icons for your AO buttons and less memory than the code for the AO will ultimately use when its running. It's so laughably low that its not worth mentioning but i did regardless.

Scripted UI can be extremely efficient if reusing as many parts as possible and using memory and cpu time only when necessary (like once when actually opening the menu). I suppose i COULD push this to the extreme by making the entire AO UI use touch coordinates like my main AO does. The only reason i use dialog menus is because its really efficient to do and offloads the UI bloat into a extra window that you are only going to see whenever you actually need to, this keeps the AO to an absolute minimum screen footprint. Something many other AO's seemingly can't do aside from other things... like script efficiency...

1 hour ago, Gabriele Graves said:

The FS UI allows me to easily switch AO sets and it does that without needing a HUD to be responsive, without using the crappy llDialog UI with truncated text or without needing to edit my AO and wait for it to reload everything from the notecard I just changed and then reset the server-side AO with what I want.  Switching AO sets is instant and it keeps a timer going that doesn't use a script so that I can automatically change dances and because of that I don't have to wear a scripted object for that.  The FS AO UI is just that much better than fiddling around with the alternatives.
 

While yes, a HUD needs to be responsive to react to your input (obviously), using crappy llDialog menus is not necessary and the reason they are crappy is up to each and every Viewer's implementation of said dialog. You know the devs could make them less crap right? It's not like we've had things that work better on one Viewer than on another....so what difference would there be making an AO that uses the llDialog in a way only Firestorm can see properly without truncation and so on?

Your AO does not need to reload in order to apply notecards. Neither does it need to restart. Again this is subject to implementation and if i wanted i could make the AO load a notecard dynamically starting with the most obvious (standing animations) followed by commonly used things like walking, sitting and running to make it look like the AO instantly swapped to a new set, while its still reading and applying the rest in the meantime. Actually now that i say this, i should do just that, it sounds interesting.

Once again using a script that does something really small automatically is not necessarily worse, especially not if the Viewer has to have its own implementation of everything the script does which i'd consider as bloated and unnecessary code, if we take into account that we could be using server-side functionality right inside the Viewer making it a truly efficient AO. I'd even go as far as multithreading the AO so it doesn't run in the main thread isn't subject to delays caused by code inefficiencies that might happen before the threads synchronize for a moment for relevant data when changing something.

The Viewer-AO is sadly not that much better as you make it out to be, it has so many flaws, the biggest in the past being that it could crash the Viewer (for whatever reason). It's only noticeable upside is using the Viewer UI (which itself is a downside again because it makes it dependent on your framerate and UI responsiveness, you are just swapping HUD responsiveness for UI/Viewer responsiveness here). A HUD does whatever it has to do regardless of your framerate as long as the input has been done.

The used attachment slot is something that cannot be entirely prevented, its a necessary evil but one that i'm willing to pay given that i hardly ever reach more than 15 attachments in total i'm absolutely fine with this, combined with the fact that my AO uses a mere 40kb script memory and my complete avatar less than 200kb with AO i think i'm extremely efficient. In clubs you could easily stack me more than ten times and i'd still use less server resources than one single average avatar. However if you are concerned about a single attachment slot being used by one of the most used, most important items in the history of SL then i'd say you have a big problem if you can't spare a single attachment slot for it.

1 hour ago, Gabriele Graves said:

So I am not clear on what are the practical gains of using scripted AO that uses llSetAnimationOverride vs FS built-in AO unless I want a really basic AO that wouldn't work for my use cases.  It isn't even clear to me that FS couldn't or doesn't even use the same mechanism as llSetAnimationOverride to set the server-side AO.  Even if both methods used exactly the same mechanism, the FS AO still wouldn't be any worse on performance and still wins hands down for the UI and not needing to wear a scripted object running timers, wait for it to read notecards or to change the anims in any way.
 

The practical gains is that a scripted AO  is Viewer-independent, (with server-side AO functions) faster and more reliable nowadays than a Viewer built-in AO. It can be as feature rich and complex as you want it to be which you can do yourself (given you have access to the script which my AO for instance offers because i want to make it easier for others to start with a decent AO system rather than continuing to rely on dated scripts like the ZHAO based AO's. Since my AO was made primarily for me and later opened up for everyone else with functions to allow others to use it too it doesn't feature as many super fancy features and UI as i don't need them, this can be changed however.

The Viewer also cannot use llSetAimationOverride. The Viewer cannot use ANY script commands without helf whatsoever, that's why they are script commands, this is the sad truth. Trust me i would have added a Viewer-AO to my Viewer if we could use llSetAnimationOverride without hacks (e.g going through an attached script like the bridge). We (still) cannot for whatever reason.

The FS AO would always be worse on performance than a scripted AO unless you create a body-like HUD AO that has millions of buttons and prims and probably the entire body mesh in the HUD.... as long as even a single line of code has to run in the Viewer you will never fully eliminate the performance impact as small as it may be. This does not include the necessity to render the button, text and possibly a setup window which are all slower to render than a single-prim HUD with miniscule texture and no constant updates.

Also, the built-in AO does require you to wait for it to load either a notecard or the animation (names) out of your inventory folder, the Viewer code is just much faster because it is not limited to the server/script throttling, it will simply execute as fast as your hardware allows it to. Animations also need to be changed in the Viewer AO as well although i'm unsure what exactly you mean with "changing" them. Animations (or their names) need to be changed inside the Viewer cached lists as well and this change needs to be communicated to the server if its a currently running animation, whether you do it via notecard or directly via inventory folders.

 

I get the impression you believe a Viewer-AO is the ultimate solution, free of any downsides, inefficiencies and/or costs. It isn't. The Viewer AO was a better solution back when we didn't have server-side AO capabilities. Nowadays a Viewer AO is not nearly as fast and reliable as a server-side AO. The "ultimate" solution would still be a very efficient Viewer AO with direct server-side AO capabilities. LL what are you doing goddamnit?! Give us a llSetAnimationOverride request for the Viewer already.

Edited July 26, 2020 by NiranV Dean

[Nalates Urriah]

16 hours ago, Pussycat Catnap said:

@Nalates Urriah You'll see that 10-50% switching viewers. Firestorm, Alchemy, Dragon, Catznip, etc...

Not AOs.

I did miss that. Sorry.

On 7/25/2020 at 8:46 AM, Pussycat Catnap said:

Firestorm's AO is playing animations, using some kind of ancient hack that itself isn't even as good as straight out calling the script to play an animation... It doesn't set your animation state - which is why it can often glitch out. A LOT of people notice that between Firestorm and almost any other viewer, your FPS goes down 10-50% when using Firestorm. This is not the only reason, maybe not even a big reason; but it's yet one more contributing factor.

But, be clear. You were implying it was a factor in FS being slower and the subject was AOs. A number of your misconceptions are in that one paragraph.

17 hours ago, Pussycat Catnap said:

Firestorm is just too loaded down with features. It's better to find a viewer that has the features one wants, rather than one that does everything.

The 'new tech' came out in 2013, so if they rebuilt in 2012 their AO is still playing animations and not using llSetAnimationOverride.

You probably should have tested that idea rather then listen to whoever told you...

My 7/12/2019 Tests + 7/26/2020 Tests

5.1.7 – Porch w/Sun-Shadow-Projector @ 256m DD – 42± FPS
6.0.1 Beta – Ground level on my porch: @ 256m DD 73± FPS*
6.0.2 Main – Ground level on my porch: @ 256m DD 102± FPS
6.2.4 Main – Ground level on my porch: @ 256m DD – 45± FPS

6.3.9 Main – Ground Level on my porch: @ 256m DD – 35± FPS

5.1.7 – Neisonia Safe Hub w/25 Avatars – 19-30± FPS
6.0.1 Beta – Neisonia Safe Hub w/28 Avatars – 30-45± FPS
6.0.2 Main – Arapaima Safe Hub 2/38 avatars – 30± FPS
6.2.4 Main – Neisonia Safe Hub w/30 avatars – 35± FPS

6.3.9 Main – Neisonia Safe Hub w/14 avatars – 27± FPS

5.1.7 – Skybox Green Room 1500m Elv – 100± FPS
6.0.1 Beta – Skybox Green Room 1500m Elv – 152± FPS
6.0.2 Main – Skybox Green Room 1500m Elv – 154± FPS
6.2.4 Main – Skybox Green Room 1500m Elv – 135± FPS

6.3.9 Main – Skybox Green Room 1500m Elv – 110± FPS

Black Dragon 6.4.2.46165 (64bit)
Porch @ 256m DD: 28± FPS
Neilsonia w/15 – 29 FPS
Skybox Green Room 1500m Elv – 82± FPS

Second Life Release 6.4.4.543157 (64bit)
Porch: 32± FPS
Nielsonia w/12: 30± FPS
Skybox: 82± FPS

Catznip R12.3 - Oct 14 2019 14:36:53 (64bit)
Porch: 29 FPS
Vilania Hub w/10: 29 FPS
Skybox: 106 FPS

Singularity Viewer (64 bit) 1.8.7 (6861) Jun 16 2016 00:32:38 – Tried but it is too old had to update.
Singularity Viewer (64 bit) 1.8.9 (8382) May  4 2020 05:10:49 (Singularity Beta)
Porch: 33± FPS
Nielsonia w/10: 41 FPS
Skybox: 210± FPS

 

Chaser debunked your unsupported idea that llSetAnimationOverride isn't used. You probably should have checked my recollection that the AO was rebuilt in 2012. Did you look at the code branches Chaser linked to see when the last update was? No... that wouldn't support your viewpoint. I was going on memory and looking at my blog to see when. Apparently I didn't bother to write something on the latest AO updates at FS.

17 hours ago, Pussycat Catnap said:

Niran notes the 'delay' between client and server and so on... that happens when you tell it to play an animation the old way, and not use llSetAnimationOverride . Firestorm has that delay. It's actually more noteable with the built in AO of Firestorm than it is with the old ZHAO scripted 'playanimation' AO - suggesting there's an added step in there somewhere.

Firestorm's AO does have a sticky animation glitch. On Teleporting you can get stuck in the falling animation. I've sometimes been stuck in other animations too, but most often the falling one. Across multiple installs, different computers, different alts. It's an intermittent issue that occurs. A built in AO is just a bad idea... this issue will happen in any of the other viewers that copies this concept as well - not just Firestorm.

The delay between client and server is there for all viewers.

I can't find a noticeable in FS or other viewers when switching animations, unless I am in a laggy sim then the delay is there for all viewers I tried (BD & Cat).

Unless you go through and preload all the animations the delay from loading the animation from the asset servers is far greater than any delay from an AO sending a packet to the server to change animations. As Chaser pointed out, since most basic animations via FS AO are switched in the server changing from a walk to a sit requires nothing from the FS AO. 

The idea to build in the AO was brilliant. It reduces script weight in the servers and cuts down on the communication needed between the viewer and server for animation. Plus, code built into the viewer never needs to run unless needed. So unless a feature is doing something it isn't using CPU cycles.

FS has some glitches. So do other viewers and various AOs.

You just don't like Firestorm, THE MOST popular viewer used in SL.

You ignored the biggest problem with the FS AO... It cannot be moved viewer to viewer as a HUD type AO can.

 

[FairreLilette]

10 hours ago, Maitimo said:

Just to clarify though, a Bento AO will work on a classic avatar just as well as a non-Bento one will, so there's no need to avoid an AO just because it says it's Bento. You won't see any individual finger movement or face expressions but everything else will work just fine.

That's true, Matimo.   However, I was just pointing that out that Classics don't need a Bento one because Bento's ones can be more expensive.  I saw one in What Customer's Are Buying Now for 3000 lindens just the other day.

But, with Classic avatars there are lots of AO'S that aren't pricey and even 1 linden that are actually good as per the link I provided above.  

However, with the mesh avatars, I do notice I have certain "glitches" if I don't use a Bento AO with my mesh avatar, especially around the waist, my waist does contort funny if I'm not wearing a Bento AO with my mesh avatar.

But, yes, Classics can use either or.  With a mesh avatar, I've not found a non-Bento AO that works well with my mesh avatar.

But, price-wise, if you don't need a Bento AO, I thought I'd point that out that you don't need one if you are a Classic.

And, to the OP:  My other favorite AO places for affordability and where you can try out AO'S are Tuty's, Voir and Vista Animations inworld.   You just buy the whole AO as it's ready-made and just wear it.  You can customize ready-made AO'S later if you gain the skills to do so.  

Edited July 26, 2020 by FairreLilette

[Gabriele Graves]

Quote

Besides, you didn't explain how "polling" is not saved here.

You brought up polling without explanation in the first place.  I admit I thought you meant some internal detail associated with idle time and seeing if the script needed to wake up which would be needed if you were using scripts that were required to wake up and do things like make a call to llSetAnimationOverride.  We don't have to dwell on that point, it isn't important.  I'll concede that part.

We are beginning to get to the point where responding to each point is looking like a long prison sentence so I am not going to do that.

The stuff your wrote about llDialog UI being improved is disingenuous because it still will have to have the limitations of llDialog as documented and retain the way it works and that will always suck compared to the FS AO UI.  If you change those limitations then it is no longer portable.  Just making it pretty isn't going to improve usability it that much.

You also talk a lot of "wishes" and "what could be if" in your response but we have to deal with what is here any now and the FS AO is a great solution.

You also say first that the FS AO cannot use the llSetAnimationOverride and then say it would have to use the bridge to do it.  It must be one or the other  If it uses the bridge, then fine with me, let it use the bridge.  At worst that sounds like an improvement to make, not a reason to rip it out.  Then it will be just as good but without having to wear scripted objects all the time, which you say you are fine with for cycling and isn't a performance issue but I bet you wouldn't constantly wear a commercial one all the same, even one that used llSetAnimationOverride.

You are not a typical AO user.  Many, many people use scripted AOs that do re-read everything if there is a change to the animations or notecards and each line is a dataserver request. If they are not re-reading that when there are changes then they are holding extra script memory. They have far more textures than what yours will have, tonnes of scripted features and people populate them with gazillions of anims .  These are the people who are going to benefit mostly from have a FS AO built-in and mostly they are already using FS.  Getting them to convert isn't that hard and it is done daily by people who help on the inworld groups.  That is a good thing in my opinion.
 

Quote

I get the impression you believe a Viewer-AO is the ultimate solution, free of any downsides, inefficiencies and/or costs. It isn't.

I don't believe that and I never said that.

I have used commercial AOs, even modern recent ones, I have used FS AO.  The FS AO wins on performance and usability.  I have never experienced the FS AO fail in the way you indicate it could or crash my viewer.  FS is very stable for me.

I remain unconvinced that a inworld scripted object is a better AO that the FS AO, especially one of the many commercial ones out there that people are actually using.  YMMV.

 

[NiranV Dean]

34 minutes ago, Nalates Urriah said:

Chaser debunked your unsupported idea that llSetAnimationOverride isn't used. You probably should have checked my recollection that the AO was rebuilt in 2012. Did you look at the code branches Chaser linked to see when the last update was? No... that wouldn't support your viewpoint. I was going on memory and looking at my blog to see when. Apparently I didn't bother to write something on the latest AO updates at FS.

Chaser did in no way debunk that llSetAnimationOverride is not used. Chaser infact confirmed that the Viewer AO uses the request animation server message which is basically what clicking "play inworld" does. You are essentially doing what each and every AO pre-server-side capabilities has done. Polling for animation states and firing an animation each and every time the animation state changes. I assume previous iterations of the Viewer AO used the bridge to to llStartAnimation which would be an unnecessary additional in-between step.

34 minutes ago, Nalates Urriah said:

... It cannot be moved viewer to viewer as a HUD type AO can.

This. You make yourself reliant on a Viewer more than necessary. Oh how often have i heard the complaint that my Viewer is unusable because it has no builtin AO... as if peeps have never heard of HUDs...

34 minutes ago, Nalates Urriah said:

My 7/12/2019 Tests + 7/26/2020 Tests

6.3.9 Main – Neisonia Safe Hub w/14 avatars – 27± FPS

Black Dragon 6.4.2.46165 (64bit)
Neilsonia w/15 – 29 FPS

Second Life Release 6.4.4.543157 (64bit)
Nielsonia w/12: 30± FPS

Singularity Viewer (64 bit) 1.8.9 (8382) May  4 2020 05:10:49 (Singularity Beta)
Nielsonia w/10: 41 FPS

Can i just ask wth happened there?

14 Avatars @ 27 FPS on the latest version (coming from much more in earlier versions).

with all other Viewers performing somewhat the same.

They are not even using EEP yet (which apparently is super slow and will push down avg framerate even more) and from what i can tell they have only ever downgraded performance over several updates. Oh oh. I thought they stopped adding new features? I know SL can be random and wildly differ but thats pretty crazy.

Edited July 26, 2020 by NiranV Dean

[NiranV Dean]

10 minutes ago, Gabriele Graves said:

You also talk a lot of "wishes" and "what could be if" in your response but we have to deal with what is here any now and the FS AO is a great solution.
 

The only wish i speak out was LL to give us llSetAnimationOverride requests directly via the Viewer animation request functionality. Everything else is realistically possible in this very moment if it hasn't been done already by some hidden dude coming around the corner any moment saying he has been waiting for this all this time.

10 minutes ago, Gabriele Graves said:

You also say first that the FS AO cannot use the llSetAnimationOverride and then say it would have to use the bridge to do it.  It must be one or the other  If it uses the bridge, then fine with me, let it use the bridge.  At worst that sounds like an improvement to make, not a reason to rip it out.  Then it will be just as good but without having to wear scripted objects all the time, which you say you are fine with for cycling and isn't a performance issue but I bet you wouldn't constantly wear a commercial one all the same, even one that used llSetAnimationOverride.
 

FS doesn't use the llSetAnimationOverride and yes i said if it wanted to it would have to go through an attached script (which would bring us back to the hacky-way that the first iteration of the AO probably was based on, which would also eliminate almost all upsides the Viewer AO currently has since you are essentially just working with a scripted AO again except now you're unnecessarily controlling it with extra steps through Viewer-through-chat-to-script-channel communication. Highy highly inefficient and slow.

"At worst" it would be a fallback to the hack as mentioned above, in best case scenario it would be still much slower than a regular scripted AO, although absolutely reliable and instantaneous on animation switch as long as no new animations have to be replaced in which case viewer to script to server communication and delay would jump in again.

And yes you're right, now that i've made my own AO i wouldn't ever use a commercial AO anymore since A) i have my own. B) i can change whatever i want in it. C) i know its efficient and fast. But that's why i want to make my AO a new "generation" of commercial AO. I want everyone to drop the old stuff and use the new features and build something new from there which is why my AO is free and open source.

10 minutes ago, Gabriele Graves said:

You are not a typical AO user.  Many, many people use scripted AOs that do re-read everything if there is a change to the animations or notecards and each line is a dataserver request. If they are not re-reading that when there are changes then they are holding extra script memory. They have far more textures than what yours will have, tonnes of scripted features and people populate them with gazillions of anims .  These are the people who are going to benefit mostly from have a FS AO built-in and mostly they are already using FS.  Getting them to convert isn't that hard and it is done daily by people who help on the inworld groups.  That is a good thing in my opinion.
 

I am a typical AO user. I use all the common stuff too and used ZHAO based AO's for a long time. I just don't feel the need to have a gazillion extra features that really don't belong in an AO. An AO's only job should be replacing played animations. Although i did say i added jump strafing as it was too good to pass up especially since most of the work required to make it run was already done by the AO anyway, adding a simple extra check and applying some force to you was basically a no-brainer and would have been inefficient to do in another script or attachment for the same reason the FS AO was/is inefficient. Its duplicate work aside from another attachment slot being used. Not that i'd care but its about efficiency. Do the most with the least resources.

The converting part is concerning to me personally. As Inara already stated, the Viewer AO is not transferable. It makes you "vulnerable" to... "being incapable" of using other Viewers, to put it like some users have been explaining it. I'd rather have everyone wear a super efficient HUD AO than another user throwing bricks at my face with "the Viewer is unusable without builtin AO" notes glued to it and all i can tell them is that i'm not going to add an AO unless LL gives us an efficient way to do it.

[Gabriele Graves]

Oh please, it doesn't make people incapable of using another viewer.  People would just need guidance and assistance to move.  The same that happens every single day in the inworld groups.  Something changes, people adapt with help.  Sometimes it is hard, sometimes not so much.

Do you know what one of the big things that stop me using other viewers? (in conjunction with FS that is).  Lack of Linux support.
I didn't see a BD download for linux last time I looked for example.  Shame because the poser thingy looks interesting.

If we could have a wish, I would wish that LL realises that an built-in AO would be good as a standard feature and require all viewers to adopt something like the one in FS, internal details varied to make it super-duper efficient and low resources of course.  That would deal to that pesky non-portability and to crappy unsuitable inworld UI tools for such a job.
 

Edited July 26, 2020 by Gabriele Graves
added missing 's'