Common Pattern for 'Arguments' for timer() Event?

[GManB]

As far as I can tell there is no way to distinguish what call to llSetTimerEvent() is being handled once inside the timer() function. I find myself having to rely on global variables way too much to make things work. Seems like this could get complicated pretty easily. Is there another way to create timed events that can be handled more like, say, a dataserver event?

 

Thanks,

G

[Ruthven Ravenhurst]

If you only need 2 different timers, there is the sensor event. You can have it look for an avatar with it's own key as the name, and with a very short range. This will trigger the no_sensor event, where you can set the second timer functions.

 

Another one is to give each timed function a number

Global:

GTimer; //1 for a sound, 2 for a light, 3 for saying something. Set the numbers to match the thing you want to happen when the timer goes off

Each time you need to use llSetTimerEvent, set GTimer to the appropriate number

{

... other things in this event...;

GTimer = 1;

llSetTimerEvent (10.0)

}

timer ()

{

if(GTimer == 1)

{

llPlaySound("sound name", 0.5);

}

else if(GTimer == 2)

{

... function (s) to set lights...

}

else if(GTimer ==3)

{

llSay(0, "this is timer mode 3");

}

GTimer = 0;//reset to 0 so nothing happens if timer goes off

llSetTimerEvent (0);//turn the timer off

}

 

Hope this helps

 

[Rolig Loon]

Your suggestion of handling them the way that a dataserver event does is just a variation on the theme of assigning a global variable as a flag. That's the way most of us keep track of which actions are triggering a timer event.  You might take a look at my post in one of the sticky threads at the top of this forum.  There are several ways to handle multiple demands for a timer.  

 

[GManB]

Thanks. In going through the Best Scripter Tips and Shortcuts I realized I had fallen into a trap I had dug myself out of a few months ago. lol

In previous execution environments, with which I have been deeply involved, timers were separate objects, more than one was possible, and they each fired at their given rate independently of other timers. So we could do the equivalent of

llSetTimerEvent(7.0);

llSetTimerEvent(3.0);

and we would get events at times, 3, 6, 7, 9, 12, 14, 15, ...

The trap was thinking in that model instead of the LSL environment where the above would generate events at 3,6,9,12,15 ... (no events at 7 and 14) because we essentially have only one timer object and the call with 3.0 as the argument resets that timer.

 

In the LSL single timer model global variables are sufficient. And, as in Rolig's example, for multiple timers we have to create a 'base' timer that evenly divides all of the work timers and keep track of the individual times ourselves in timer().

G

[Sabrina Tamerlane]

It is more complicated to explain than to write so here is how I would do it:

 

integer ElapsedTime = 0;
integer Running = FALSE;

default
{
    state_entry()
    {
    }

    touch_start(integer total_number)
    {
        if (Running)
        {
            llSetTimerEvent(0) ;
            Running = FALSE;
        }
        else {
            llSetTimerEvent(1) ;
            Running = TRUE;
        }
    }
    
    timer() 
    {
        llOwnerSay((string)ElapsedTime) ;
        if (ElapsedTime > 0 && ElapsedTime % 3 == 0) {
            llOwnerSay("3 seconds timer") ;
        }
        if (ElapsedTime > 0 && ElapsedTime % 7 == 0) {
            llOwnerSay("7 seconds timer") ;
        }
        ElapsedTime++ ;
    }
}

If you need more precision you can use one of the time functions such as llGetTime() to read the time directly... but of course they have a cost and might slow you down...

Edited November 5, 2020 by Sabrina Tamerlane
oopsie

[GManB]

Thanks Sabrina! Yes, what you suggest was what I had in mind.

Cheers,

G

[Anna Salyx]

What I do when I need multiple timers is a global variable to set the 'end time' for the timer tick against unix time.  then compare the current unix time against the variable on each timer event. 

This works for me as it helps me keep straight (if I use good var names) to know what's fireing on what intervals.  Now granted most of my timer needs are at intervals of more than 1 second, usually a minimum of 10 seconds, so I'm not sure how accurate it would be on fast pulse, but I don't really see why it wouldn't . 

You could also reset the variable after the 'do stuff' is finished simply by calling a get unix time + x at the end of the function.  this would allow time for things to finish before setting up the next pulse interval for it. 

Anyways, hope this helps spark some ideas for you

for example for a 1 mintue and 3 minute timer

integer gTic1;
integer gTic2;

default
{
	state_entry()
	{
		llSetTimerEvent(1.0);
		gTic1 = llGetUnixTime() + 60;
		gTic2 = llGetUnixTime() +300;
	}

	timer()
	{
		integer lTic = llGetUnixTime();
		if (gTic1 > 0 && lTic >= gTic1)
		{	
			//if done with timer is true set gTic1 to 0,
			// else gTic = lTic + 60
			do 60 second stuff 
		}

		if (gTic2 > 0 && lTic >= gTic2)
		{
			//same logic of setting to zero if done,
			// or resetting to another 5 minutes out. 
			do five minute stuff
		}
	}
}