Animation Override 2.0

AO's, absolutely hate em, have to have em!! Who wants to stand around or walk like a dork? But each AO runs a poll at least every second (some .01 seconds) to check what you are doing. They do this even if you have been sitting or standing or cuddling or tied to a rack for hours. Every second of every hour you are logged into SL X 15,000 users!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

AO's are brilliant pieces of scripting BUT have remained unchanged for a long time. Time for a next generation AO; AO 2.0. How can we cut the polling???? Ah just thought of it last night, use movement_start, movement_end and change = CHANGED_LINK. You would still need a timer if you wanted to change stands. Will also need to poll BUT then it would only have to poll after one of the 3 triggers. I will start making one sometimes this weekend and welcome input or your versions posted here. Between us all we should be able to cut the polling down dramatically and spread the word and the final version. I want to make it also so it is touch on and off, no more typing /ao off every time you want to sit on a poseball.

The final version would be available for free. Hopefully people would get the word and use them.

Hopefully some day LL will give us some sort of handler named avatar_change() handler.

There is the nice bit that these rapid polling scripts should only affect the sim they exist in... they don't need to burden the asset server or inventory database... or send updates over the network to our clients unless the animation chagnes. So the check itself *should* be reasonably light-weight.

But I totally agree... fast loop polling is just ugly as sin.

I haven't tested it but does start_movement trigger when someone starts typing?

My ZHAO does that, since it's a HUD attachment. Along with on/off, there's a "sit on/off" button, so you don't have to manually turn it off when you sit and on again after you stand up, the AO just does not play an sit override. It was meant for what you're talking about - poseballs, furniture, vehicles. The core mechanics though, are mostly unchanged from Francis Chung's Franimation script. So, yes, there is a lot of polling. There's also a lot of "SL is buggy if you stand up while the typing animation is playing, and you'll get stuck in this animation forever, so the workaround is this" kind of code in there. I left all that alone, because I figured Francis had done her testing and found those bugs, and I wasn't going to second-guess that

Feel free to pick up a ZHAO and look through it (my profile picks has LMs). Also, you could talk to Dragon Eccleston, he's been looking at the ZHAO recently, with the aim of reducing the script impact. He might have some interesting ideas.

Good luck with your endeavour. If you make a lighter AO, all of SL will thank you

Can also pick up the ZHAO at YadNi's, its where I got mine from.
Count me in Jesse, should be fun

Not entirely sure if it's the pooling that need focus on if you are after reduction of AO impact.

taking ZHAO as example, estate tools report the attachment on the whole takes 0.06 ms on average. BUT take note, it has 6 extra buttons each loaded with 2 scripts, each script taking 0.003 ms simply because it exists. That's 0.036 ms i.e. more than half of overall attachment impact ... and all of it could likely be removed with simple HUD re-design.

For that matter, i killed the extra hud buttons entirely as a test, which reduced the load to 0.015-0.020 ms i.e 1/3rd or less of original value... which is hardly a value that raises concern -- 50 AVs in the sim would use ~1 ms of the sim time for their overriders total, which is ~7% of total script time available... and with 50 AVs in one spot you have way more pressing issues to deal with, there o.o;;

The 2 scripts per button could very easily be combined into 1. When I wrote that, I didn't know that idle scripts consumed scheduler time And I haven't gone back and updated it.

I think Dragon was working on some clever tricks to hide the buttons, by rotating the whole thing out of the screen area, and rotating the main button back, or something like that. That would get rid of the scripts in the button prims. If we had an llSetLinkPos function (we don't, right?) all those scripts could be avoided.

Yup, that'd be one way ^^ i was also thinking of somethiing like hud shape redesign so all the less used buttons can be toggled on/off with setlinkalpha and read with detectedlink etc, but don't take much of screen estate while hidden so hardly ever get in way of mouse pointer. Yet another option could be to put the options which are at the moment in folding menu into llDialog box instead that opens when the user holds down mouse on the main on/off button for more than a second, or something similar...

I'm pretty new to SL, but it doesnt take long to see the power and nessesity of an AO. I know this thread is mainly about polling, but if a base AO script redesign is underway, I thought I'd throw in a feature request.

Why do I have to have three AOs on me? One main AO, and another for typing override and maybe an afk override too. If a new AO script was able to give the user the ability to override every animation; hard landing, typing, away (afk), swiming, etc, what would simplify things.

I guess this would have a positive performance impact too. Most people would only need the one AO, instead of serveral products.

I came up with this for showing /hiding buttons. You have to follow the bouncing ball but you can see that if the buttons are hidden then one script is turned off and the rest of the touchs won't work in the main script.

pass_touchs(){
    integer button = llDetectedLinkNumber(0);
	vector color = llGetColor(0);
	if(button == 1){
		if(on_main ==1){
			on_main = 0;
			do_something;
		}
		else{
			on_main = 1;
			do_something_dif;
		}
	}
    if(button == 2){//MORE BUTTONS
        if(on_show == 1){//SHOW
            on_show = 0;
            link = 2;
			llSetColor(<1.0,0.0,0.0>, 0);
			llSetScriptState("button_5", TRUE);
            while(link < 6){
                link++;
                llSetLinkAlpha(link, 1.0, ALL_SIDES);
            }
       }
        else{//HIDE
			on_show = 1;
            link = 2;
			llSetColor(<0.0,0.0,0.0>, 0);
			llSetScriptState("button_5", FALSE);
            while(link < 6){
                link++;
                llSetLinkAlpha(link, 0.0, ALL_SIDES);
            }
       }
    }
	if(color.x > 0.5){///This keeps these touchs from working
                          // if the color is not right
		if(button == 3){
			llResetOtherScript("main script");
		}
		if(button == 4){//
			 do_something;
		}
		if(button == 5){//
			 do_something;
		}
		if(button == 6){//
			 do_something;
		}
	}
}

Yeah, that would work. The whole idea with moving the buttons was to prevent them from picking up a touch, or a right click, so you can interact with whatever is in that area of the screen. Even if the script ignores the touch, I'm not sure if it will be passed on to a touch-enabled object on the ground that happens to be 'under' the HUD prim on-screen.

Joannah: I don't remember if I used the link number/name thing for the buttons in the ZHAO, I have on my other HUDs. The buttons still need scripts if they are to be moved. So yeah, if you decide it doesn't take up too much screen real-estate, then you could just have them go alpha, that's a design choice I like your idea of a long touch to bring up a dialog box. But that could confuse people, since that's not a type of interaction people are used to. Though the hidden menu shows up when someone clicks the Menu button, so that could bring up a dialog box instead, where the first level shows what's on the buttons now, and a next level shows the stuff when you press any of the buttons. That would work.

And I should warn you guys - be prepared to take on supporting this product for free if you release it. And be prepared for people who say "I read your notecard but I still have a question", and ask you something that's completely covered in your notecard Or "I bought your XXX HUD (insert name of animation vendor who will use your HUD to sell their animations) and I don't like YYY (insert name of pose they want changed), and you'll have to explain to them that you don't make the actual animations. Even though that is mentioned in your notecard too.

Yes, this is a bit of a pet peeve, in case you can't tell And this is also why I fully encourage you guys to do this

While you're at it, Jesse, consider using llTakeControls to monitor control events. That'll give you a big clue on when important animations like walking and jumping need to be started, which will allow you to lower your timer event.

I wrote a mini-ao for myself (I can't distribute it because it's very much me-specific and not generalized), that uses control events. I'm able to keep my polling rate to 0.5, and just test things like sitting, landing, etc... just a ton of annoying corner cases (you wouldn't believe how many). While something important is happening, eg the user has the forward key held down or is mid-jump, I lower the timer interval to 0.1 seconds just to make sure I catch the end quickly.

So why do we have to have an AO anyway? Why doesn't Linden Labs just make that a configuration option in the client? Sort of like Gestures, let you set what animations you want for each state. Seems like a no-brainer to me, and would eliminate this AO mess.

You'll want to take controls from the user either way, if you want the script to run in no-script zones.

Gods only know but yes, it'd be most welcome... and if the animations are originally triggered by client rather than server then it'd be what, some couple hours work to add one preferences dialog to replace current hard-coded values o.O;

That's the million byte question. It has been asked before and it is feature suggested. IF default animations are set in the client computer, ie; "I am flying now and I use this animation.", then it shouldn't be a problem. But if everyone's state is monitored in the server and it is more a case of; "Jesse Barnett is flying now, apply default flying animation". Then it would be rough setting it up to track everyones individual preferences. I don't know which way it is being done now. Since the server whould have to know when we are flying anyway because of the Havok engine, then it is probably the latter.

EDIT: heehee. Joannah same thing went through your mind as mine at the same time

Excellent idea, just a couple of brief thoughts to add.

- In experimenting with a mini-ao walk replacer, it was my experience that keying off moving_start events was noticebly slower and less reliable than polling client animation states. Hopefully it was just a poor implementation on my part, but I hope someone does some similar experiments before putting a whole lot of time into this.

- As a feature request along the same lines as what I think Mr Blackthorne is suggesting, I'd really like to see a standardized "listen on a particular negative channel filtered for llGetOwner for particular strings" arrangement, for purposes of integrating other tools that *need* to turn the AO on and off to work properly. I have a personal tool that integrates flight assist and huggers and AFK animations and such on a single chat listen, and while it's not a big deal to add a comm link between that and my current AO it might be nice to have a standard protocol to make it simpler and encourage people not to add additional open chat listens just for an AO. And if this thing takes off, and the protocol is available, I can picture people putting that functionality into items they make for added value to users who don't do any script editing.

Assuming you don't have show transparent turned on, setting a full alpha texture will make everything pass through the object as if isn't there but since you can't set a texture on a linked prim any more than you can move it, I guess it doesn't make much difference .

I just checked a little earlier. Set my buttons to 100% alpha. Left clicks pass through and touch objects on the ground behind the button. BUT right clicks pick the hidden buttons. I was told that this has been bug reported before but was also told that if it was fixed then it would break some existing content. So we will just have to continue using the move or rot wasy to get stuff off the screen.

Full alpha textures and llSetAlpha(0.0) have different behaviours .

But I just tested script-wise (should have done that before posting ). If you set a full alpha texture and it has a touch handler (or the main prim has one), right-click passes through, but touches don't.

Glad you guys tested it. I just remember there were some inconsistencies with how pass-through touch and right clicks worked. Also, try the left/right clicks with the edit window open, I believe that changes the behavior too.

I already have the ZHAO down to using 2 active scripts, but my method is a bit kludgish, so someone is helping me redo the textures so it will be a bit smoother. As far as the AO itself goes I'm starting that over from scratch, going to try a couple of different methods and see if we can't reduce the script load on that as well. First method is to do away with list checks and comparisons, and most string comparisons and use llGetAgentInfo to do mostly string comparisons to narrow the choice of animations down, then llList2String on shorter lists to get the actual animation list. I can examine the possibility of using CHANGED_LINK to detect sitting/unsitting to disable the timer then. It already takes controls to make changes as fast as possible that way, but seems a lot of times it loses control permissions, not sure why. I've already got the llGetAgentInfo method working in test cases, its just a matter of seeing if doing it that way is any faster than the old method...

Hi Thanks for your interest.

A few clarification points:

1) No AO polls more than once every 0.1 seconds
2) AO's automatically slow down their polling rate as the sim load increases
3) move_start/moving_end events are mostly meaningless in an attachment.
4) The AO I did is only 1 active script
5) touch on/off I'm sure can be retrofitted to most scripts in less than 5 lines of code. The AO I did is open-source - you are welcome to add those 5 lines and redistribute it under the terms of the GPL.

Also, just for fun:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!???

I use moving end in my flight assist and it works fine. Wait for moving end before kicking in a timer to check if I am flying.

Now I have to go back and rewrite conde in another script too. Got some feedback and finally got a chance to run some tests. Using moving_start & moving_end would actually INCREASE the amount of polling. They both work along the lines of llDetectedGrab, comtinously turning off and on. And as far as change & CHANGED_LINK for sits, THat does not work in attachments.

O well back to the drawing board.

I'm experimenting in monitoring the number of running animations to check to see if we should slow down polling or if the animations are recognized. Also intend to make the AO stop all animations on teleport, will fix embarrassing animation problems and keep the animation list trim. Generally speaking there should only be one animation running at a time, maybe 2 if you're using a mood attachment. Keeping un-needed animations stopped (often times the SL client runs 2 of the built in animations at the same time, they don't seem to stop one before starting another) the list checking functions can be kept nice and trim. I did some testing with Francis' current AO and the biggest "problem" with it is the hasIntersection function, which checks for animations to not override. In an empty sim with that function and a few other performance tweaks, the AO uses 3000 IPS, by commenting out that one function it drops to 1000, so I see the biggest performance gain in eliminating or determining when that function is best used. Preferably eliminating.