On Fri, 2012-04-13 at 22:10 +0200, Henri Beauchamp wrote: > As a result of trying to mitigate this issue, AOs all too often tax the > sim servers by using a very high rate timer that checks the currently > playing anim every frame (llSetTimerEvent(0.02); or less) so to detect > the start of the default animation to be overridden and to start the > corresponding overiding animation as fast as possible. >
My timer is ony 0.25, not 0.02. I get very, very little stutter and then only on sims that are too loaded for me to be in anyway. > While it is possible to script relatively "low lag" AOs, especially by > using the control() event and detecting key presses that cause the > walk/turn/run/fly anim changes and then using a lower frequency timer > to catch the rest of the animation changes (e.g. when "falling"), they > are still more laggy (seen from the server side) than a viewer-side AO. > > These flaws are due to the lack of a change() event for animation > changes (time to implement CHANGED_ANIMATION, perhaps ?...) in LSL: if > such an event existed, then the scripted AOs could become just as fast > as viewer-side AOs if not faster (see below about the "ping" problem) > and would not cause any measurable lag (since the high frequency > timer() would then become useless and would be removed). > While CHANGED_ANIMATION would be cool, I would MUCH prefer that key release events could be properly reported. My first version used no timer, but as I couldn't get key releases to trigger the control() event reliably I had to abandon that approach. For some odd reason, when I asked about it on the scripter's list, no one knew what I was talking about. CHANGED_ANIMATION would be usable in more than one case, so perhaps that indeed would be the better way. Downside, of course, is that in order to be used in no-script areas you have to both take controls and have animation permissions in order to keep running. In this case, properly reported key releases would indeed solve the timer problem too. > Viewer side AOs simply watch the animation changes as sent by the > sim server and, when a default animation (ANIM_AGENT_*) is triggered, > the viewer watches its AO table to see if a custom animation should > replace the default one, and in the affirmative, sends stop default > anim/start overriding anim orders to the server. Note that while there > is no lag involved doing so from the server side, the user may still > experience a delay (assimilated to "lag" from their point of view) > if their ping with the sim server is high (a 250ms ping will then > typically result in a half second delay before the default anim gets > overridden as seen by the user in their viewer, thus not providing a > better experience than a scripted AO). > > As mentionned in other messages in this thread, there is also the > problem that the viewer side AOs are currently poorly implemented and > lack region change/TP checks, etc, causing the animation overriding > to fail in some cases, when scripted AOs are not affected (not hard > to fix however... Just a matter or re-coding them properly). > This is true. But still, adding the myriad features used by any group is not going to be simple. from Zi: > *when I'm underwater, apply a vertical impulse of strength X to simulate > > partial buoyancy. > > *when I'm less than half my body height from the surface, attract me to > > the surface and play the treading water animation. > > *add a flight aid boost when I fly up or down so I go a little faster. > > These need external scripting support. That's why I was making the case for scripted AO rather than client-side. Client-side is NOT a bad idea, but it has quite a ways to go before it'll really be capable of taking the place of the scripted versions. The original poster has LOTS of studying and work to do if he's gonna undertake this project ;) > the flexibility of the interface and functionality, there will always be > > holes, sometimes large, that will make it less fit for entire classes of > > people. > > Depends. I am sure most of these gaps can be filled by small supporting > scripts as soon as a standard interface for the AO is in place. LSL interface to the existing (rather, updated) Firestorm LSL bridge? Most of what I mentioned would indeed be doable if the bridge could talk to the AO, and if there were LSL access to the bridge. I'm sure there's a security breach in there somewhere, though, so maybe that wouldn't be a good idea. I'm not too familiar with the bridge, I just wear it.. haha. > *every 6 seconds, play this fidgeting animation. > > *every 30 seconds (the standard) switch stands. > > So two timers instead on just one? Our Viewer side AO supports at least the > animation switch on a defined cycle time. > One timer using several tick counters. In an effort to reduce the timer load as much as I could, I used a 0.25 timer interval, which was about the largest I could get that wouldn't screw up the switching. I wanted to use a wholly event-driven approach with a timer only for sit / stand cycling but it just didn't pan out. --GC _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
