Dz Delicioso

The new AO functions only seem to give you the option to set a default animation that will be used for each of the animation states... This IS NOT a functional AO replacement.. There is no way to specify a sequence of stands. Some posters have claimed that it will also solve the problem of animation stutters ( as the wrong animation starts and THEN the one you want). Being able to set a new default stand will not solve this problem.. Everytime you want to change stands you will need to set a new default, and without the ability to "force" the new stand animation into cache before it is started, the stutters will continue. This new solution will also NOT provide the ability to combine animations that has been a standard feature in AOs since ZHAO-II. An additional script will still be required to start the second animation over the base.

The followup posts and images do point to the interest list problems recently introduced. The code in the OP & JIRA certainly didnt indicate the objects were mesh, or that TP's or re-logging would resolve the issue. I still take exception to scripting examples that decrease the efficiency of the simple solution. Proposing to ADD state changes to a script that is struggling to perform its current workload is a poor design choice that impacts everyone. Certainly it is more efficient to change the timer value than to ADD approximately 24 state changes AND 24 llSetTimerEvent calls to each second of script processing time. 'nuff said.

Here is an example of a script that might work for you. It is a brute force method to force a non-looped animation (like the example animation.. aim_r_handgun) to play when you are walking, running or crouch-walking. Instructions for modifying are in the comments.. Test it by creating a prim, adding this script, take the prim into inventory, and attach it to one of your hands. Touch the prim to make it turn green and then see what happens when you walk or run. Touch it again to turn it off. Modify it by dropping it on the ground, adding your animation to the contents of the prim and change this line to match the name of the animation you added.. string ForceAnimation = "YourAnimationNameHERE(in quotes)"; //Change this to your animation name Save the script, take the object back into inventory and wear it again. Usual Creative Commons license restrictions and disclaimers apply, feel free to use and change to suit your needs. // Simple Animation Override for WALKING animations// Once attached touch to toggle ON/OFF// Dz 2013//=========================================================================// ---LICENSE START---// http://creativecommons.org/licenses/by-sa/3.0/// ie: Attribution licence:// Give me credit by leaving it in the script I created. // Set the value of ForceAnimation to the name of an animation you want to play when the avatar walks// Your animation needs to be of equal or higher priority than the walk for this to work.// Place this script and the animation in an object that will be attached , wear the object// Grant permissions and touch the object to toggle the override on and off.// There is an old bug report that the llGetAgentInfo may not report correctly immediately after a sim border crossingkey owner = NULL_KEY ; string ForceAnimation = "aim_r_handgun"; //Change this to your animation nameinteger PermsList = 0;default // this is where the script starts... and waits until the object is touched to start running{ state_entry() { owner = llGetOwner(); // Find out who I'm attached to llSetColor(<1.0, 0.0, 0.0>, ALL_SIDES ); //change this to prevent your object from turning red when it is off PermsList = llGetPermissions(); // If we dont have permissions to start animations, ASK if (!(PermsList & PERMISSION_TRIGGER_ANIMATION)) { llRequestPermissions(owner, PERMISSION_TRIGGER_ANIMATION); //Trigger the pop-up } } run_time_permissions(integer p) //Even though attached objects dont have to ask, we play nice { if(p & PERMISSION_TRIGGER_ANIMATION) { llOwnerSay( "Override Functional, touch to turn on/off"); // Notify owner script is ready for activation PermsList = p; // Save new permissions list } } touch_end(integer total_number) // NEVER change state in touch_start { if (PermsList & PERMISSION_TRIGGER_ANIMATION) state Running; // Once we have permission, start the RUNNING part of the script } attach(key id) // Reset the script every time the object is worn { if (id) // is a valid key and not NULL_KEY llResetScript(); } }state Running // This part of the script handles events when the override is active{ state_entry() { llSetTimerEvent(0.5); // This is how often (in seconds) the script will check to see if you are walking // The higher the number, the less impact the script has on the sim. // The lower the number, the faster the animation will start. Adjust to your situation. llSetColor(<0.0, 1.0, 0.0>, ALL_SIDES ); //change this to prevent your object from turning green when it is active } timer() { if(llGetAgentInfo(owner) & AGENT_WALKING) //AGENT_WALKING covers walking, running, and crouch walking modes llStartAnimation(ForceAnimation); // When TRUE Start the animation else llStopAnimation(ForceAnimation); // When NOT walking stop the animation } touch_end(integer total_number) // After a touch, toggel to waiting, again NEVER change state in touch_start. { llStopAnimation(ForceAnimation); // Stop the animation and return to the default (waiting) state llSetTimerEvent(0); // turn off the timer..we dont need to check any more state default; } } I hope that sheds some light on the "insides" of animation scripts.

I dont think the click and drag is possibleby script. There are plenty of HUDs that reposition themselves, either sliding off the visible screen to hide, or rotating to show a smaller face. I dont know of any that are opensource off-hand. This resource should be useful to you HUDS (wiki)

Your problem is that animations with the same priority are handled with a LAST Started = Highest priority algorithm. If your walk animation is a priority 4 and includes motions for your upper body parts, those motions are overriding your object animations. The simplest (scripting) fix is to reverse the order the animations are started. If you restart your object animation AFTER you start the walk, your upper body animation will override the same level walk. Most AO scripts are open source so someone should be able to modify it to communicate to your object when it has started the walk animation. Use the notication to restart your object animation. A brute force option would be to have your object check to see if your animation state CHANGED to walking and force restart your animation when it does. A "non-scripting" alternative is to reload the walk animation as a lower priority. A second "non-scripting" option is to make a new priority 4 walk animation that does NOT move any of the body joints involved in your object animation. You can then play both in any order and they they should not interfere with each other.

The problem has already been identified experimentally as an event buffer overflow caused by a timer value that is too small. Why would you solve that by ADDING a State change ( which FLUSHes the event buffer) to the mix? LSL State info sez... On state change: All listens are released. The event queue is cleared. (see Notes for a partial workaround) Adding a state change in the manner you have suggested might seem to keep the object flickering, but at the cost of (probably) dumping other events awaiting processing. The O.P. suggested the object also did pathfinding. This suggestion most likely would result in pathfinding events getting tossed and break that functionality in obscure ways. You do NOT need to make the script as complicated as these last 2 examples... The solution is making display processing as fast as possible and increase the time between events.. Change your timer value from 0.08 to 0.2 and see if the problem remains. Reduce the timer value in increments until the problem returns, and then bump it back up to give yourself some headroom when the object is in a sim that might be a little slow. // fast face flipping for a cube.. Experiment with values for the timer to find a minimum working valuefloat delay = 0.2;integer count=0;integer oldside=0;default { state_entry() { llSetTimerEvent(delay); llSetAlpha(0, ALL_SIDES); }timer() { ++count; if (count == 7) count = 0; llSetAlpha(0, oldside); llSetAlpha(1,count); oldside = count; }}

You will need to drop the animations in and set the locations on your own using tyhe adjust pos option.... There are 2 notecards you will need to change.. .MENUITEMS notecard is used to configure the menus and link the poses to a menu button.. the .POSITIONS notecard will be what you need to change to store the default position for each of the poses. You will have to either guess at a position, or adjust each of the positions for each of the avatars in each of the poses, and then save them to complete your setup. Animations with no entry in the .POSITIONS notecard will be placed in the DEFAULT position. The sequence is well described in the MLP documentation.

Inworldz has not implemented the turn animation states. They have implemented the CHANGED ANIMATION event however, so using timer based AO's is a poor design choice. I have repeatedly brought this to the attention of guides and whatever devs willing to listen. My conversion kit and non-polling AO have been removed from the freebie area despite the impact the polling based ones are having on performance. You can convert a ZHAO CORE script to utilize the new event by adding the following 2 lines in the existing change event handler... if (change & CHANGED_ANIMATION) checkAndOverride(); You can then disable the timer by changing 1 other line of code.. *************************** code ************ // How fast we should poll for changed anims (as fast as possible) // In practice, you will not poll more than 8 times a second. float timerEventLength = 0.25; *************************************** end of code REPLACE WHATEVER NUMBER IS AFTER THE = with 0.0..... so the line looks like this.... float timerEventLength = 0.0; This will force the same override check every time the animation state changes. Unfortunately, the Inworldz devs branched before the addition of the left and right turn patches.

It is also possible that the poses are at fault. MLP reference sez.... Though all animations will work with MLPv2, not every single one you come across will work reliably. Some animations, if they happen to have been made by the creator in a certain way, will work as expected after certain other animations, but not after others. You'll get different results depending on which pose you ran last. The problem is animations that have their hip position the same in their T frame and first animation frame. They just won't work with MLP.

I think part of your problem might be the timer value.. it is extremely small. While it may have worked when the object was not processing any other events, adding pathfinding to the object might be enought to cause your timer events to back up and overflow the event queue. It is NOT an infinite queue, and it has to handle all of the events sent. Using the fast version of SetPrimPrams might help reduce the processing time for event handling and suck them out faster, prolonging the time until it overflows, but I would also suggest testing with high timer values to see if reducing the flip rate helps too.

I'm much less excited about the new AO functions, and have to disagree with the assertions she makes in the blog post. While I agree that it is critical to remove AO polling for animation state changes, I think the lindens have gone down the wrong path to implement a solution. The new functions may allow me to set my default stand animation and then let my AO script go idle, but no one seriously uses an AO like that. In order to properly implement a cycle of stand poses, the AO script will still require a timer and that will force it to remain active. In order to prevent the "false starting" of the wrong animation, the new design will force the AO scripter to call the llSetAnimationOverride function to preset the default to the "next stand" animation before changing it, effectivly doubling the number of function calls using during the "normal" operating state of an AO. It also fails to support the use of "combo animations", a feature which has been available since the second geneneration of Zhao AO's. It would have been simpler all around to just expand the list of changed triggers available to include an animation changed event. Combine this with a single new function to allow scripters to force load animation files to cache ( good ones are pretty small compare to all the other stuff sent back and forth ) and you have solved the "false start" problem for everyone working for smooth animation transitions. Even without the "force to cache" function, the worst case impact of just implementing the event flag would be "possible" stutters the first time through your AO animation cycles. So we added 3 new functions to LSL, and all the code that required, instead of adding a flag to an already exiting bit of tested code AND we haven't really addressed the false start problem for anyone other than folks happy to use a single default stand. Im sorry, but that doesnt sound like the best plan.

Over the past 2 weeks my full sim .. normally functioning smoothly for 20-30 avatars at regular events... has required several extra reboots ( sometimes per day) to remedy some unknown problems. The symptoms of the problem are that the sim time dialation goes from 95-100 to 2-5 for a brief period as NET time goes off the charts. While this would not normally be a major concern, this event seems to be the begining of a cycle that soon degrades sim performance to the point it becomes impossible to reboot without submitting a support ticket. This occurs with 1 or 2 avatars on sim and NO ONE entering or leaving. Usually, within minutes of the original spike,, it will begin to repeat... and each time the period of dergraded performance increases. With 10-15 minutes... I am seeing 10-15 seconds of time when scripts run/avatars can move, and 30-90 seconds where the sim is "toast"... Eventually , the periods of 0-5% time dilation just continue and the sim must be rebooted to be used. As this sequence has repeated itself over and over, I have had tme to use the estate diagnostic tools on the sim during its ride over the cliff... Top scripts reports NOTHING out of the ordinary...The same scripted objects are in place from BEFORE these events started. Top scripts report 8ms of script time for 900 active scripts, even when measured across 2 spikes. Physics collisions are not a factor... we have a single pinball machine on sim and Pathfinding is OFF. In the Advanaced>performance tools> Statistics window there are a number of oddities... the most regular /consistant event is that net time goes HUGE...changing from a stable .15-.30 ms to numbers that go as high as 1040ms. This number usually starts smaller. in the 30-50ms range (NOT .3-.5, but 30-50), and then gets progressively larger. Once that event happens, the scripts run % goes from 97-99 down to the 20-30% range, and sometimes i see a large spike in physics activity. (( ???? no avatars entering/leaving...no changes to sim...no one operating the physics objects))). Eventually the network time spike number starts to get larger... 200-300 ms and the script run % goes below 10% This will usually be the prelude to HUGE script time and Physiscs times as the sim degrades into uselessness. Ive reported this info each of the times ive had to request a sim restart, but Im not getting any responses , nor has the situation changed. Im in my 3rd reboot of the day, I've only been online for 2 hours. and this is getting old. Since i cant look to see if this is already JIRA'd i thought id share it here..

I am cross posting this link from the land forums so the merchants are aware. In case you havent noticed... reported traffic numbers for the past 3-4 days are BOGUS! It seems the High traffic sims are reporting 30-40% of thier normal traffic, Lower traffic sims are being under reported by as much as 70%. If YOU make rental decisions based on Traffic numbers... The lindens are making it IMPOSSIBLE for you to make correct decisions on where to place your stores. I URGE EVERYONE to please visit the JIRA posting of this and vote on the topic so it will be reviewed and possibly contact support about the issue so it will get noted. https://jira.secondlife.com/browse/VWR-27621

Cerise... Please dont confuse me with the O.P. I did not quote numbers for my traffic, but it you wish... Yesterdays traffic numbers are in.. My Stable counters called for 6400-6800 ( I adjust this down for my residents who spend some time in the residential parcels.) Hence my 5% "historical difference" . The traffic reported by lindens for yesterday 1970. Thats a 60% difference between COUNTED avatar minutes and the reported traffic. In that time I held 2 events.. DJ, Hostess and 15 vistors on my dance floor and registered on my contest boards. 4 hours of events x 15 people is a minimum of 3600 traffic.. I WAS IN THE SIM TALKING to these people.. The only POSSIBLE explanation is that the lindens have decided that avatars who click on a dance ball and dance for an hour or 2 DONT COUNT as traffic... Or Maybe they dont count people who refuse to play thier facebook games. WAKE UP!!! Until someone with a LINDEN tag explains this...its gonna kill all the traffic dependant businesses left in SL.

Cerise.. I count visitors.. I count minutes... I KNOW the PEOPLE in my sim... I have been using the same scripts to count visitors for 6 months..and I am accurate to within 5% ( for the past 4 months) I do NOT have scripted agents ( if that is what you prefer to call avatars parked in a box) my reported traffic is 1/2 of my counted REAL PERSON minutes. Again.... I DONT CARE ABOUT OTHER SIMS, or what thier traffic levels have done. My vendors dont pay me for THIER traffic,,, they pay me to get bodies in front of the boards in MY sim.. Im doing MY part...Why do the LIndens think its ok to just Change the rules and NOT post anything about it?? It is affecting my ability to finance operations... What bug was fixed??? Where can I point my vendors to something from the Lindens to explain this???

Traffic numbers seem to have deviated drastically from the "normal" calculations since 11/15. I count visitors and minutes in sim, and have been doing so for almost 6 months. These numbers give me a traffic estimate that has been within 5% of the Linden reported numbers for that whole time. For the past 2 days, the linden traffic numbers have been 1/2 the value I estimate.. WHY???? Who do we go to to get this fixed???

I'm not worried about search position. I run a NO BOTS sim, competing with clubs that regularly keep 4-10 "staff members" logged in standing in a box at 3K meters... I've given up asking the Lindens to enforce thier own policies regrading the tarffic gaming nature of these sims, they are obviously happy to let them play the games as long as they pay for classifieds... Im worried because my vendors have TOLD me.. they are targeting malls with certain traffic numbers... when my traffic dipped over the summer,,, these vendors closed up shop. When my traffic returned, so did they... Thats a regular business cycle. BUT when the lindens...with no prior discussion, chop my numbers in 1/2.. the vendors leave.I dont get a chance to point them to a blog, or a forum, or show them REAL COUNTS...the vendors close up shop. Without them..so do I.

Aloha. Outside of the O.P, who seems to have mechanism in place to actually COUNT visitors and time in sim...Does anyone else have MORE than "everyones traffic numbers seem lower, but I see the same amount" ??? I have monitors in place to count vistors and minutes as well... The correlation to my counts and the posted traffic have been within 5% for almost 4 months. Now I am seeing 40 and 50% discrepancies in the past 2 days. For clubs seeing 20-40K traffic numbers, I guess it can be "ODD", but for me..the differnece in traffic means i will start losing vendors at my mall, and may be the difference between staying open or closing down my 3 year old club ;(( PLEASE PLEASE PLEASE if there is a LINDEN out there with half a brain,, figure out that YOU CANT JUST CHANGE the metrics without even a HINT of an explanation...

++100 for allowing ALL of the UI elements to scale camera movement and movement windows take HUGE chucks of screen real estate and seem to even refuse UI scaling And hasnt anyone noticed the phonix avatar list is seperate from the mini-map..