Practical Limits on timer() Event Rates

[Kayaker Magic]

I used to think that you could not set the timer interval less than 0.2 seconds in llSetTimerEvent. But it turns out I was calling llSetPos or something in the timer() event that had a 0.2 second delay. I get the impression that the theoretical minimum delay should be around 1/45 but the Wiki has hints that you will actually get intervals that are twice as long as that. Which is still 4 or 5 times better than I used to expect.

HOWEVER, when I try setting timer intervals this small, I don't seem to get things to move more often than I get with a 0.2 second interval. (Even using llSetLinkPrimParamFast to avoid the 0.2 second delay). What are the practical limits on timer() event rates?

I haven't done the experiment yet to MEASURE the maximum rate (minimum interval). Has anyone else already done this experiment?

 

[Void Singer]

IIRC the theoretical lower bound should be 0.05sec, but considering amount of code, anything better than 0.2seec is a laudable miracle, and also probably entirely to often.

[Kayaker Magic]

Well, I'm competing against the guy who has something like this in his code somewhere:

for (EVER){  vector pos=//some calculation  llSetLinkPrimitiveParamsFast(1,[PRIM_POSITION,pos]);  //there are 2 or more prims in the build  sleep(0.02);}

and MY customers are asking me "Why do YOUR critters move in such a jerky way? Cant you make them move smoother?"

I'm trying to be a good netizen about it and find some way to increase my step rate while still using good event driven programming.

I've gotten smother motion with physics, but it has its own problems. The physics engine is not lag free either. It runs away from me all the time. llMoveToTarget can't really do constant velocities and won't move larger builds. I've had to resort to using vehicle physics. Meanwhile, the guy with the ugly loop above is getting beautiful results. What is a scripter supposed to do?

 

 

[Miranda Umino]

I have tried with this piece of code to test the limit

 

list listTimeStamp;integer numberIterations;integer Millisec(string Stamp) {    return (integer)llGetSubString(Stamp, 8, 9) * 86400000 + // Days        (integer)llGetSubString(Stamp, 11, 12) * 3600000 + // Hours        (integer)llGetSubString(Stamp, 14, 15) * 60000 + // Minutes        llRound(((float)llGetSubString(Stamp, 17, -2) * 1000.0)) // Seconds.Milliseconds        - 617316353; // Offset to fit between [-617316353,2147483547]}default{    touch_start(integer total_number)    {        numberIterations = 50;        listTimeStamp = [];        llSetTimerEvent(0.001);    }    timer()    {        if ( --numberIterations > 0 )        {            listTimeStamp += [ llGetTimestamp() ];            llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_POSITION,llGetPos()+<0,0,0.01>]);      }        else        {            llSetTimerEvent(.0);            integer i = llGetListLength(listTimeStamp) -1;            integer pred = Millisec(llList2String(listTimeStamp, -1));            integer next;            list result ;            while ( i-- > 0)            {                next = pred;                pred = Millisec(llList2String(listTimeStamp, i));                result += [next -pred];            }            llOwnerSay(llList2CSV(result));        }    }}

 

 

The results are very different between the sims even if they have got many free spare time .

In some sims , (not only the magnum and blusteel tests sims ) i have an average of 44 ms ( maybe 2 Frames ?? maybe one frame to enter in the timer event and one frame to call the library function llGetTimestamp ? )

[22:19]  Object: 44, 45, 43, 44, 44, 45, 45, 45, 45, 44, 34, 92, 45, 46, 44, 44, 44, 45, 42, 123, 46, 43, 45, 43, 45, 44, 46, 45, 44, 45, 44, 43, 46, 44, 45, 44, 44, 45, 44, 45, 44, 43, 45, 45, 45, 43, 46, 45

 

On other sims ( with no lag and more of 15 ms spare time ) it s more between 60 and 120 ms

[22:18]  Object: 110, 68, 90, 111, 139, 408, 121, 87, 88, 70, 87, 98, 113, 113, 110, 91, 90, 178, 116, 110, 154, 114, 90, 108, 71, 86, 88, 70, 87, 69, 88, 67, 93, 86, 70, 87, 112, 68, 68, 86, 71, 67, 66, 91, 69, 87, 89, 91

 

[Qie Niangao]

I suspect something else is slowing things down.  As Void says, the theoretical minimum timer event interval is 0.05 secs (as documented, anyway). There are a couple of things that might be useful in besting the competition, at least until they catch up with recent additions to LSL.  llSetKeyframedMotion() may help with moving the whole linked assembly around smoothly. That won't help with moving child prims; for that, you may get some utility from PRIM_LINK_TARGET if you're not already using it.

[Void Singer]

speed may not be the problem with your items seeming "jerky" compared to theirs... scale may be. if yours are larger (turns become more noticeable at the same speed) or move in larger increments (tweening has to make up for more spae) or rideable as opposed to not (vid card doesn't tween whole scenes well) it magnifies the transition.

there are other things that can minimize visual transition as well, such as bunching (moving the back prims closer to the front and then moving the front prims forward, mimic animal surging motion) and wobbling (slight motion to each side on successive moves, mimic gait/rocking), even intentional ghosting (leaving something akin to a blur trail which covers tweening).

some factors also depend on the end  users settings (ling interpolation type) frame rate, and even screen type and size.

[Lear Cale]

---

Kayaker Magic wrote:

Well, I'm competing against the guy who has something like this in his code somewhere:

for (EVER){  vector pos=//some calculation  llSetLinkPrimitiveParamsFast(1,[PRIM_POSITION,pos]);  //there are 2 or more prims in the build  sleep(0.02);}

and MY customers are asking me "Why do YOUR critters move in such a jerky way? Cant you make them move smoother?"

I'm trying to be a good netizen about it and find some way to increase my step rate while still using good event driven programming.

I've gotten smother motion with physics, but it has its own problems. The physics engine is not lag free either. It runs away from me all the time. llMoveToTarget can't really do constant velocities and won't move larger builds. I've had to resort to using vehicle physics. Meanwhile, the guy with the ugly loop above is getting beautiful results. What is a scripter supposed to do? 

---

Note the sleep(0.02);  According to the documentation, this will actually be more like a sleep(0.05).  I doubt there's a significant difference between using a timer and a sleep, other than the obvious: your event-driven code will be able to respond to an event, whereas this one can't (without odd gyrations like checking a prim parameter for a passed value from another script).

Without the sleep, the code would be criminal.  ;-)

BTW, this is why we hate pets.  Any script that does something EVERY FRAME is ... well ... a bit rude to those sharing the sim.  Admittedly, overuse of physics isn't a good solution.