Timer issue between SIM

[chrixbed]

I'm working on a mesh that a rescale (llScale()) to follow a beat on a timer. I use the script on a SIM where everything seem to work fine but when I change to a other SIM the timer get lost. I try to see if there is a time dilatation between the sims but nothing special. My timer speed is around 0.04958.

In the following video:  Malibu Dream's SIM follow the beat but not Black Art Sand's SIM ?!

Here is an ex of my code:

integer step = 0;
integer steps = 5;
lstSteps = [<1,9,9>,<2,9,9>,<3,9,9>,<4,9,9>,<5,9,9>,<5,9,9>,<4,9,9>,<3,9,9>,<2,9,9>,<1,9,9>]; // Scale the object
default
{
    state_entry()
    {
	BPM = 121;
		// Calculate the frequency to update the info to sync the beat
      	Beat = (60/BPM)/Steps; // value = 0.04958;
        llSetTimerEvent(Beat);
    }

    timer()
    {
	llSetScale (llList2Vector(lstSteps, step));
        if (step == (2*steps)-1) step = -1;
        step++;
    }
}

How can I handle that better and know when a SIM perform well or not ?

Thanks !

[Qie Niangao]

Well, the problem isn't time dilation, its the Scripts Run percentage. Malibu Dream is a (lightly loaded) "Full Region" whereas Black Art Sands is just a Homestead, so there's only a quarter as much time available for processing each simulation frame, which is why it only gets to process about half the scripts on the scheduler queue each timeslice. 

Regardless, that's a very tight timer for what this script is trying to do. Even if it works running on a lightly loaded sim, it's generating a huge volume of object updates for each viewer in sight of the scripted object. Also, just in passing, the simulators run at 45 frames a second, so timers tend to be most reliable when they're approximately integer multiples of 1/45th second (or 0.0222.. seconds).

(Actually, I would have expected that llSetScale would be throttled with a 0.2 second delay, as is llSetPos and etc., thus requiring use of llSetLinkPrimitiveParamsFast -- but apparently I would have been wrong, judging by the wiki.)

I guess my advice would be to settle on a different effect that can be performed purely viewer-side, instead of in the script itself.

[Wulfie Reanimator]

The biggest problem with the actual implementation is that you're seemingly doing fixed steps per timer event, instead of calculating what the scale should be whenever the timer is triggered. This causes the problem of having the effect change pace as the rate of events fluctuates.

Since you're going for a smooth in-out motion, you could give llGetTime (multiplied by BPM) to llSin or llCos, since sine/cosine are wave-functions. This would allow you to use much fewer updates while preserving that consistent rate.

Edited February 18, 2021 by Wulfie Reanimator

[chrixbed]

3 hours ago, Qie Niangao said:

Well, the problem isn't time dilation, its the Scripts Run percentage. Malibu Dream is a (lightly loaded) "Full Region" whereas Black Art Sands is just a Homestead, so there's only a quarter as much time available for processing each simulation frame, which is why it only gets to process about half the scripts on the scheduler queue each timeslice. 

Regardless, that's a very tight timer for what this script is trying to do. Even if it works running on a lightly loaded sim, it's generating a huge volume of object updates for each viewer in sight of the scripted object. Also, just in passing, the simulators run at 45 frames a second, so timers tend to be most reliable when they're approximately integer multiples of 1/45th second (or 0.0222.. seconds).

(Actually, I would have expected that llSetScale would be throttled with a 0.2 second delay, as is llSetPos and etc., thus requiring use of llSetLinkPrimitiveParamsFast -- but apparently I would have been wrong, judging by the wiki.)

I guess my advice would be to settle on a different effect that can be performed purely viewer-side, instead of in the script itself.

You are right, I notice that the timer are slower on Black Art Sand indeed:

 

[chrixbed]

2 hours ago, Wulfie Reanimator said:

The biggest problem with the actual implementation is that you're seemingly doing fixed steps per timer event, instead of calculating what the scale should be whenever the timer is triggered. This causes the problem of having the effect change pace as the rate of events fluctuates.

Since you're going for a smooth in-out motion, you could give llGetTime (multiplied by BPM) to llSin or llCos, since sine/cosine are wave-functions. This would allow you to use much fewer updates while preserving that consistent rate.

That a very good idea, actually I did calculate a list with llCos() for the sizes of the object to create a sense of oscillation but using it to spread the call to the timer is a very interesting way to do that as well. I will try to comeback with a updated code version to see if I can make it works.

[chrixbed]

Your comments make me think and I realize that I was stressing the timer to close to the edge. I when for an easy way by simply changing the numbers of update which gives more time and now it's working.

Ex for a song of 121BPM:

-Before with 10 scales updates timer = (60/121)/10 = 0.04958

-Now with only 5 scales updates, timer = (60/121)/5 = 0.09917

The new one can handle both sim. I will try to round it to 1/45th second to make it more compatible with the timer as suggested.