|
RaveWolf Strauss
Registered User
Join date: 1 Jan 2006
Posts: 53
|
03-02-2008 02:43
Im having a problem with this script.I want it to perform as follows.... when touched it stops on the default texture which i named totallyclear which is a alpha texture so therefor making the object "disappear" then touch it again and it would show up again and start cycling the textures again .... The Way it sits it cycles and stops on textures other then default and when touched again does not restart cycling the textures.Would be happy to tip peeps or something for there help or rescripting............jus sick of banging my head an cant see why it wont perform correctly. integer auto = FALSE; float time = .02; integer total; integer counter; string default_texture = "totallyclear";
next() { string name = llGetInventoryName(INVENTORY_TEXTURE,counter); if(name == "") { total = llGetInventoryNumber(INVENTORY_TEXTURE); counter = 0; if(total < 1) return; else name = llGetInventoryName(INVENTORY_TEXTURE,counter); } else if(counter + 1 >= total) total = llGetInventoryNumber(INVENTORY_TEXTURE); llSetTexture(name ,ALL_SIDES); if(total) counter = (counter + 1) % total; }
default { state_entry() { total = llGetInventoryNumber(INVENTORY_TEXTURE); next(); llSetTimerEvent(time); } touch_start(integer total_number) { if(auto == TRUE) { next(); llSetTimerEvent(time); auto = FALSE; } else { llSetTexture(default_texture, ALL_SIDES); llSetTimerEvent(0.0); auto = TRUE; } } timer() { next(); } }
TYVM in advance for any help
|
|
Pale Spectre
Registered User
Join date: 2 Sep 2005
Posts: 586
|
03-02-2008 04:50
I never did fully get my head around the next() function so I just redid it.  I think the other problem is that with such a fast timer (0.02 is damn quick!) you definitely need to stop the timer before setting your default texture. integer auto = FALSE; float time = .02; integer total; integer counter; string default_texture = "totallyclear";
next() { if (counter >= llGetInventoryNumber(INVENTORY_TEXTURE)) counter = 0; llSetTexture(llGetInventoryName(INVENTORY_TEXTURE, counter), ALL_SIDES); counter += 1; }
default {
state_entry() { total = llGetInventoryNumber(INVENTORY_TEXTURE); next(); llSetTimerEvent(time); }
touch_start(integer total_number) { if(auto == TRUE) { next(); llSetTimerEvent(time); auto = FALSE; } else { llSetTimerEvent(0.0); // stop the *very fast* timer first llSetTexture(default_texture, ALL_SIDES); auto = TRUE; } }
timer() { next(); } }
...completely untested. 
|
|
Void Singer
Int vSelf = Sing(void);
Join date: 24 Sep 2005
Posts: 6,973
|
03-02-2008 06:25
and while the wikis aren't clear on the point, timers won't ever fire faster than .05 (at least that's what testing has shown).
it might be better to either change states or put a check variable in the timer loop to prevent extra firings from queued timer events. in fact with a check variable it coud set the default.
_____________________
| | . "Cat-Like Typing Detected" | . This post may contain errors in logic, spelling, and | . grammar known to the SL populace to cause confusion | | - Please Use PHP tags when posting scripts/code, Thanks. | - Can't See PHP or URL Tags Correctly? Check Out This Link... | - 
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
03-02-2008 12:15
From: Void Singer and while the wikis aren't clear on the point, timers won't ever fire faster than .05 (at least that's what testing has shown). It's stated, but I think not specifically with regard to timers. The minimum time between event calls is 0.05, supposedly for all types of events. You can increase it, but not decrease it.
|
|
Void Singer
Int vSelf = Sing(void);
Join date: 24 Sep 2005
Posts: 6,973
|
03-02-2008 12:49
stated yes, but not within the function descriptions, so many miss it, I know I did at first.
and there's still a question of how the queue is built, we know the event will only get queued once (those the variables for that queue slot can continue to build as in the case of listen) but we don't know if the trigger continues to fire, and it seems it does in the case of timers, effectively eating a potion of time that is available to scripts, and thus forcing a greater processor use for all scripts... if enough do it, the result is increased lag on scripts (not necessarily on the sim though).
which is why it's good to try to fit the timer to the amount of code it has to run, thus eleminating the extra triggers that will be ingored anyways...
an example would be timer code that takes 6 seconds to run, with a timer event of 1 second. the timer event gets queued 1sec in, and ~4 more triggers for it will get ignored... those ignored triggers still take up time, which becomes wasted. but if the same timer event were declared at 7 seconds, it'd run a hair slower on average, but also leave time for other events code to run, so it'd allow for a more consistant average running.
there's also a question of how timers trigger, whther it's on an absolute we've mapped in Xsec between triggers, or if it's Xsec from the last trigger (which could be a notable difference with other events processing code)
_____________________
| | . "Cat-Like Typing Detected" | . This post may contain errors in logic, spelling, and | . grammar known to the SL populace to cause confusion | | - Please Use PHP tags when posting scripts/code, Thanks. | - Can't See PHP or URL Tags Correctly? Check Out This Link... | - 
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
03-02-2008 12:57
Agreed. I've done non-physical movement scripts where the helpers all use timers (and texture faders, and a few other small implementations). Trying to set the timer interval to less than the script delay caused by your code (e.g. the forced sleep time imposed by llSetPos() or llSetPrimitiveParam()) actually causes the performance of the scripts to decrease DRAMATICALLY.
So my recommendation for tight timer loops is to always count up the maximum total script delay your timer event handlers might impose, and always set the timer period to something a little larger than that (say 1.5 times the maximum total script delay). Otherwise you might just be shooting yourself in the foot, and that is in ADDITION to whatever extra sim CPU cycles you might be using up to the detriment of other residents and scripts.
|