" * This function delays the script for 0.2 seconds."

We've all seen it and sort of take it into account when we're working on a script, but I've run into a conceptual sort of a brick wall and the time scale is small enough that I can't sit there and test it out by counting "one tenth or one Mississippi, two tenths of one Mississippi..." so I turn to you.

I'm revamping one of my older vehicles - the Flapter which i sort of like a cross between a Jet Ski and a very large beetle (it's from the film "Laputa". The original version had 12 individual wings - three sets of four wings positioned up, flat, and down. The animation effect was created by rapidly flipping all of the wings to transparent then flipping one set to 50% transparency so that they looked like they were moving. It works fairly well but requires 12 prims and is prone to all sorts of alpha issues plus the occasional missing wing when one of the prims misses the linked message for some reason.

The new version of the Flapter has a single wing which is a sculpty. I flip the sculpt map using llSetPrimativeParams to animate the wing by reshaping it, and it works great. The trouble is that darn .2 second delay. The animation process is quite simple as you'd imagine, a link message from the root prim activates or deactivates a timer and each time the timer runs I flip to the next sculpt map in my list.

So, here's the question. If I set the timer to 1.0 second what happens? Does the script delay stop everything in the script for .2 seconds so that the timer has an effective cycle of 1.2 seconds? Or does the timer continue ticking away seconds so that - as long as the llSetTimerEvent is set to greater than .2 the built in delay has no effect on it?

Hope that makes some sense - my head hurts just reading it back to check spelling

From my experience, the timer is independent of the script delays.

Yes. That is correct. BUT if the delays in the script are greater than the period of the timer, then things can get a little odd. So it is probably best to avoid that: make sure your timer period is a bit larger than the sum total of the script delays built into the functions you call each time.

script delay only effects continuous script processing, for instance if you have a single .2s delay in a timer called every 1.0s then there is no continuous processing, because there's .8s of dead time in there. however, if your timer includes 6 functions at .2s each, your timer will never fire faster than 1.2s because the delays for the code within it are longer than it's own period.

regardless of whether a listed function has a delay listed or not, it does take some time, so if that total time to execute all instructions in a timer is longer than the timers period, it'll force a longer period.

treat delay as being the amount of time each particular function takes to complete (with the realization that no event is actually zero)

i haven't seen in action to know if this would work or not. but if the wing is a sculpty, you could make it so that the pivoting edge of the wing is the center of the sculpted prim by offsetting the bounding box in whatever sculpty creator you use. after that, use a swing script, that way you're not also stuck with the blobs while the new sculpt map loads

It would be a lot better for you to go back on the alpha switching, but with the two sculpties, please don't change sculpties, it is known to be extremely laggy, all those sculpty changers on those fishes and animals is contributing to a huge amount of lag on the grid, stressing limited resources on the simulators, just please don't add to that existing ignorance.

The most efficient and easiest form of getting an animation flicker is via texture animations using an texture with the second half of the texture being fully transparent.

The alpha-issues can be very easily ignored if the flicker happens fast enough.

This method is commonly used on modern weaponry for efficient muzzle flash effects for example.

For the muzzle-flash-style efficient method:
The textures would look kinda likes this for your application, to abstract it into a diagram:

___________________
|VISIBLE  |INVISIBLE|
|INVISIBLE|VISIBLE  |
    

The top half would be the first frame, the bottom half the second frame. The sculpty would be both wings in one and applying the UV map correctly.

The easier method but more laggy (Much less than changing the sculpty though), would be to simply do llSetLinkAlpha on the seperate two sculpties from the main script in the existing vehicle timer.