Best way to go about timing this?

//Precision Timer Example
//by Hank Ramos

//Variables
float timerCounter;

//Options
float timerDuration = 5.0; //Time between "firings"
float timerPrecision = 0.1; //Make this value MORE if you need LESS precision. Make it LESS if you need MORE precision.

triggerPrecisionTimer()
{
    llSay(0, "Precision Timer Has Elapsed! = " + (string)timerCounter + " second(s).");
}

default
{
    state_entry()
    {
        llSetTimerEvent(timerPrecision);
        llResetTime();
    }

    timer()
    {
        timerCounter += llGetAndResetTime();

        if (timerCounter >= timerDuration)
        {
            triggerPrecisionTimer();
            llResetTime();
            timerCounter = 0;
        }
    }
}

Best way to go about timing this?
Senuka Harbinger A-Life, one bit at a time Join date: 24 Oct 2005 Posts: 491	12-10-2005 23:53 what's the best way to have an event trigger every 5 minutes according to the SL in-game clock? right now I've been using a simple algorithm where if the time is evenly divisable by 5 the event fires, but was wondering if there's a built in function that does this for me, or perhaps just a better method of incorperating this. _____________________ My SLExchange shop Typos are forgiven; desecrating the english language with reckless abandon and necrophilic acts is not. The function is working perfectly fine. It's just not working the way you wanted it to work.
Malachi Petunia Gentle Miscreant Join date: 21 Sep 2003 Posts: 3,414	12-11-2005 02:47 llSetTimerEvent _____________________
Senuka Harbinger A-Life, one bit at a time Join date: 24 Oct 2005 Posts: 491	12-11-2005 07:51 From: Malachi Petunia llSetTimerEvent unfortunately, that's not synched up with the world clock. _____________________ My SLExchange shop Typos are forgiven; desecrating the english language with reckless abandon and necrophilic acts is not. The function is working perfectly fine. It's just not working the way you wanted it to work.
Tezkat Murakami Ebil Genius Join date: 25 Sep 2005 Posts: 12	llSetTimerEvent should still work... 12-11-2005 08:30 From: Senuka Harbinger unfortunately, that's not synched up with the world clock. How accurate does it need to be? The event runs every five minutes, so you should still be able to use llSetTimerEvent and resynch/recalculate the interval when the timer fires to take care of drift.
Malachi Petunia Gentle Miscreant Join date: 21 Sep 2003 Posts: 3,414	12-11-2005 08:51 You are right, my reply was rather terse. The thing you really don't want to do is sit in a "busy loop" querying the world time as this busy waiting will kill script performance. As timer events (or llSleep) are not all that accurate, you need to decide how far off you can afford to be and call llSetTimerEvent appropriately. Inside the timer() handler, you can llGetTimeOfDay and compare it to your criterion. You need to remeber to call llSetTimerEvent() again inside the timer() handler as the timer event happens only once. Without knowing what you are trying to do, I recommend a TimerEvent delay no more frequent than once every 10 seconds. Please note the limitations noted in llGetTimeOfDay as it does not necessarily correspond to the position of the sun. _____________________
Hank Ramos Lifetime Scripter Join date: 15 Nov 2003 Posts: 2,328	12-11-2005 09:11 CODE //Precision Timer Example //by Hank Ramos //Variables float timerCounter; //Options float timerDuration = 5.0; //Time between "firings" float timerPrecision = 0.1; //Make this value MORE if you need LESS precision. Make it LESS if you need MORE precision. triggerPrecisionTimer() { llSay(0, "Precision Timer Has Elapsed! = " + (string)timerCounter + " second(s)."); } default { state_entry() { llSetTimerEvent(timerPrecision); llResetTime(); } timer() { timerCounter += llGetAndResetTime(); if (timerCounter >= timerDuration) { triggerPrecisionTimer(); llResetTime(); timerCounter = 0; } } } L$ Donations are Appreciated!
Senuka Harbinger A-Life, one bit at a time Join date: 24 Oct 2005 Posts: 491	12-11-2005 10:09 From: Tezkat Murakami How accurate does it need to be? The event runs every five minutes, so you should still be able to use llSetTimerEvent and resynch/recalculate the interval when the timer fires to take care of drift. it's being used by a bunch of different prims that are rezzed at different times, but I want them all to ping my "server" at the exact same time (give or take a few seconds). _____________________ My SLExchange shop Typos are forgiven; desecrating the english language with reckless abandon and necrophilic acts is not. The function is working perfectly fine. It's just not working the way you wanted it to work.
Kala Bijoux Material Squirrel Join date: 16 Nov 2004 Posts: 112	12-11-2005 10:41 On rez, check the current time and find out how far away you are from the next 5 minute boundary. Set a timer for that amount. On the first timer event, ping the server and switch to a 5 minute timer. From that point on, just ping the server every time the timer fires. This is pretty simple to do (switching to a new state after the first timer is one way to do it, or a simple check to determine first timeout vs. subsequent timeouts), doesn't require busy waiting or polling the current time, and should be accurate to within a few seconds. The other way to do it would be to set a timer for the maximum error you're willing to handle (say 5 seconds), and inside the timer event, check to see if you're in a new 5-minute segment than you were the last time. I don't think that will give you any better synchronization, and your scripts will be a LOT busier handling unnecessary timer events. From: someone You need to remeber to call llSetTimerEvent() again inside the timer() handler as the timer event happens only once. Unless this has changed very recently, I don't think so. The timer event gets triggered repeatedly when you set it once. Setting it again effectively kills the previous timer and starts a new timer. So setting it again inside the timer event will have the same effect, but isn't really necessary.
Ethan Cinquetti Registered User Join date: 5 Jul 2005 Posts: 24	My shot at it 12-11-2005 12:08 CODE integer ALREADY_FIRED = FALSE; // Timer runs at SLOW_INTERVAL for minutes except the ones immediately // preceding the minute to fire. // FAST_INTERVAL is for the minutes immediately preceding the time to fire. float SLOW_INTERVAL = 45.0; float FAST_INTERVAL = 10.0; // Time check is performed by reading the 16th position // in the string returned by llGetTimestamp(). // // So, to set up your events to fire on minutes divisible by 5, // the test strings are set up this way: // // MINUTES_BEFORE_FIRING probably needs a better name...it just // means that if the a timestamp with a RH minute value of "5" or "0" // means "fire", then a timestamp with a RH value of "4" or "9" means // "the event is getting close; increase the frequency of the checks." // string MINUTES_BEFORE_FIRING = "49"; string FIRE_MINUTES = "50"; default { state_entry() { llSetTimerEvent( SLOW_INTERVAL ); } timer() { string now_minute = llGetSubString( llGetTimestamp(), 15, 15 ); if ( -1 < llSubStringIndex( FIRE_MINUTES, now_minute )) { // // Don't fire twice in the same minute. // if ( ! ALREADY_FIRED ) { // // ** Your stuff goes here // ALREADY_FIRED = TRUE; } llSetTimerEvent( SLOW_INTERVAL ); return; } ALREADY_FIRED = FALSE; if ( -1 < llSubStringIndex( MINUTES_BEFORE_FIRING, now_minute ) ) llSetTimerEvent( FAST_INTERVAL ); } }
Argent Stonecutter Emergency Mustelid Join date: 20 Sep 2005 Posts: 20,263	12-11-2005 15:09 Don't let the timer free-run, re-issue the llSetTimerEvent() for 5m every time it fires. Keep track of how far off your calculations are, and adjust the delay accordingly. If you're firing 5s before the event, reissue the llTimerEvent() for 2.5s later, and similarly if you're late set the timer to go off a little sooner. After a while you'll stay pretty close to 5m. This is basically how our OWN timers re entrained to the day-night cycle. If they were left to free-run they'd end up on a 25-28 hour cycle (if I recall correctly). The first llSetTimerEvent() from on_rez() or state_entry() will of course be calculated to go off at 5m... which will initialise the system. This is much more efficient than kicking of a bunch of 1s events every 4 minutes and 50 seconds.
Hank Ramos Lifetime Scripter Join date: 15 Nov 2003 Posts: 2,328	12-11-2005 15:14 From: Argent Stonecutter Don't let the timer free-run, re-issue the llSetTimerEvent() for 5m every time it fires. Keep track of how far off your calculations are, and adjust the delay accordingly. If you're firing 5s before the event, reissue the llTimerEvent() for 2.5s later, and similarly if you're late set the timer to go off a little sooner. After a while you'll stay pretty close to 5m. This is basically how our OWN timers re entrained to the day-night cycle. If they were left to free-run they'd end up on a 25-28 hour cycle (if I recall correctly). The first llSetTimerEvent() from on_rez() or state_entry() will of course be calculated to go off at 5m... which will initialise the system. This is much more efficient than kicking of a bunch of 1s events every 4 minutes and 50 seconds. The actual SL server code checks every timer event at every pass of the script for events, so it doesn't matter.

Welcome to the Second Life Forums Archive

Best way to go about timing this?