Simple llSleep() question

Hello,

I have a simple question: What is the lowest interval for llSleep()? The wikis are not very clear but I'm guessing 0.1 sec? Would it make any difference if I do llSleep(0.05)?

Thanks for the info!

My impression is the problem is one of precision; in practice, the actual delay you get when you call llSleep can vary by as much as 0.1 seconds, so small values get you inconsistent results.

Try to make it work with a timer instead if you can, they seem to be more precise.

I'm not sure what the minimum is, but you need to remember that when using llSleep it is going to pause for at LEAST that long.

Since all the scripts in a sim share the same resources, it will process the sleep, and then it might still have a delay before getting a chance to process the next part of your script.

considering the processing speed of lsl why do you need such a short pause?

I've found that the accuracy of both llSleep() AND timers is only about 0.05 at best, and often is a little worse than that even with a time dilation near 1.00. I don't think that varies much whether you are asking for a 2 second delay or a 0.001 second delay. Maybe it'll improve with Mono, but I doubt it given the number of non-script tasks that have to be handled by the server every frame.

Thanks for the info!

Actually the accuracy is not that important for what I'm using it for. I'm making a little gadget that can display some pics and I wanted to do a sort of cross-fade or fade in/out transition between changing pics, so I did a hackish thing to fake a fade out/fade in transition. I'm using llSleep(0.1) to modulate the steps a little so the steps don't go too fast but aren't too slow. I've tested what I have and it works pretty well. It's not very elegant but it works and is not complicated and doesn't waste too many cycles and I hope doesn't create much lag (with mono this should be trivial).

Here is a test script for the "texture changing transition hack" I'm using. I'd be happy if the forum gurus can suggest a more elegant way of doing this...

// test script to cycle pics in inventory
// with fade in/fade out transition
// - just drop the script into a prim with a bunch of pics
//   and touch it to cycle through the textures

integer FADE_STEPS = 5; // number of steps to fade in transition
list gPics; // list of pics in inventory
integer gTotalTextures;
integer gCurrentTexture;



// load texture names into list

load_textures()
{
	integer i;
	integer n = llGetInventoryNumber(INVENTORY_TEXTURE);
	
	for (i = 0; i < n; ++i)
	{
		gPics += llGetInventoryName(INVENTORY_TEXTURE, i);
	}
	
	gTotalTextures = llGetListLength(gPics);
	gCurrentTexture = 0;
}


display_next()
{
	if (gTotalTextures <= 0)
		return;

	gCurrentTexture = (gCurrentTexture + 1) % gTotalTextures;
	
	string name = llGetInventoryName(INVENTORY_TEXTURE, gCurrentTexture);

	fade_out();
	
	llSetTexture(name, ALL_SIDES);
	
	fade_in();
}


// fade in / fade out transitions

fade_out()
{
	integer j;
	integer steps = FADE_STEPS;
	float alpha = 1.0;
	float delta = 1.0 / (float) steps;
	
	for (j = 0; j < steps; ++j)
	{
		alpha -= delta;
		llSetAlpha(alpha, ALL_SIDES);
		llSleep(0.1);
	}
}


fade_in()
{
	integer j;
	integer steps = FADE_STEPS;
	float alpha = 0.0;
	float delta = 1.0 / (float) steps;
	
	for (j = 0; j < steps; ++j)
	{
		alpha += delta;
		llSetAlpha(alpha, ALL_SIDES);
		llSleep(0.1);
	}
}


// default state

default
{	
	state_entry()
	{
		load_textures();
		display_next();
	}


	touch_start(integer num)
	{
		display_next();
	}


	changed(integer change)
	{
		if (change & CHANGED_INVENTORY)
		{
			llResetScript();
		}	
	}
}

Oh. I believe llSetTexture() itself has enough of a built-in script delay (0.2s) to likely do what you want.

the accuracy problem is easily attributed to time dilation, at dilatio of 1.0 (or normal) sleep returns it's specified length. at lower time dilations it should return ~ X/(time dilation) as the wait time, this isn't perfect because time dilation is an average across a reported slice (or perhaps a snapshot across a slice)... there may be sone slight addition for actual call time (not the wait time)

so it's much simpler (and explainable) to say llSleep is subject to dilation, thatn to say it's accuracy is 'at least X, maybe more' ... because there's no given explanation for 'maybe more'

aside from using a function call to space an event, I wouldn't be supprised if .05 was the minimum delay for anything, since it's the minimum delay for any event to trigger

Well, taking the difference between the sleep/timer time expected and the actual delay, the deviation USUALLY falls within about 0.05 seconds, but there are enough samples that are 2-3 times that to say it is not a very reliable prediction EVEN when time dilation appears rock solid at 0.99 to 1.00. Meaning a fall in time dilation implies increased delays, but steady time dilation does NOT imply very accurate timing.

In short, you can generally expect to be within about 0.05-0.1 of your target time, but don't do anything within SL that DEPENDS on it. It is NOT a platform for time-critical applications. And for the most part this is to be expected by a highly multi-tasked, multi-user network application. Even the prediction that time dilation can afford you can't be expected to be very accurate.