llSetTimerEvent low value effectiveness?

Just wondering if it's viable to have a timer that triggers every 0.0625 (1/16th) seconds, or will the margin for error be too big for it to be worth it, not to mention server load and other things? What's the lower end value you can use for llSetTimerEvent while retaining a reasonable degree of resource effectiveness and error margin between events?

What are you trying to accomplish? Timers less than 1 second are considered pretty "rude". Some say that timers more often than 30 second are often better done in some other way.

I'm building a sort of game machine that has a steady flow of updates. It's not very complex but when a game is running it obviously needs to update on appropriate intervals.

Is there a better way to do high resolution timing? Or should I just forget about the project completely before I build a sim-crashing lagfest machine instead of anything actually enjoyable?

Basically, all the timer would be doing would be checking if it was time to fire a particle, and if so, it would fire... one. If I can get that functionality at all, in some less rude way, I'd be delighted to hear it. It needs to be an autonomous function of the script though, it can't rely on user input or something like that.

You can control the rate of particle emission using the PSYS_SRC_BURST_RATE parameter of llParticleSystem which has the advantage of being client side and having no sim impact after the call to start the particles. As the RATE parameter is a float in seconds you probably have finer grained control than you could ever get with timers.

I gather from "it can't rely on user input" that the stream is not conditional upon anything in which case this is the solution. Please let me know if I have assumed incorrectly.

It is, actually. the 0.0625 seconds is the smallest "tick" the machine can have. To elaborate I'm trying to build something DDR-ish in game, using particles a lot for less server-load, yes. But - if you are familiar with Dance Dance Revolution games - the particles, in this case arrows floating up then dissapearing, cannot come at a steady interval: that would make the game completely predictable after all. So I need some way to check when a particle needs to be shot up. Most of the time the ticks themselves will not execute any code beyond a few conditionals unless a particle is to be created.

So I'm really curious if this is a scenario that can be done in SL. I'd assumed timers weren't performance heavy considering after all that LSL states the timer interval is a float, so I assumed lower values would be okay.

The timer isn't heavy per se but event handling is and a call to llParticleSystem is relatively heavy at such a high. I'm not sure, but the llParticleSystem call may exceed the timer interval you are seeking.

I have seen DDR and I think your best bet, even better than particles, is likely llSetTextureAnim which is also client side and would allow you to vary patterns simply by swapping textures, or changing the "start" parameter. With a documented maxium of 65k frames per texture, that's a lot of arrows (although I've never tried anything that big). Moreover, I think the visual would be more like DDR than particles would be.

Good luck.

Wouldn't using llSetTextureAnim still be reasonably timer heavy, although far less so than the particles?

The documentation on that function was poor and hard as hell to understand so I'm not really sure I even understand how it works or how it would practically apply in this case. Wouldn't it still be timer heavy?

EDIT: Or are you thinking of simply cutting up a whole song sequence arrow wise into a ton of frames of animation? If you had 10 frames per second and a 60 second game, that would make for 600 images. Wouldn't the load from loading them all kill people with lag as well, and also wouldn't there be the blurry "hello I'm a texture still being loaded" effect as the textures are being loaded on the fly?

And even then I'd still need timing to make sure the user inputs their moves at the appropriate time... this project seems doomed to fail before it's even started.

EDIT2: I could do 15 FPS for a full minute using 4 1024x1024 textures. It's not pretty and its not really uber lag preventative, but still workable if people are willing to take a slight hit to play a cool game in SL?

So that's -one- problem solved, but that still leaves me utterly baffled about how to register if the players it timing his/her moves right. Oh well, that's an experiment for another day. I'd like to hear opinions on using 4 textures this big for a single song though. And keep in mind that'd be on top of 6 wave files 10 seconds long. Is this viable at all? Come on people, let me know >_<

I could maybe do with 4 512x512 instead (which is effectively only ONE 1024x1024), I suppose I'd need to test that, see if it looks halfway reasonable to cut down the size by half.

Read this page on event delays: llMinEventDelay
Bytecode takes time to execute
running a list though llParticleSystem could easily take 0.012 seconds.

Well I think I have a way figured out that can do all this without any timers or particles, only animated textures and user input events. (which will still be spaced fairly close together but that's nothing new, considering Animation Overriders and Vehicles and other things like that, right?)

So that means no active loops, no timers, pretty much nothing but the user input events. That should be fine with server load, I assume?

I'm assuming since llSetTextureAnim has no delay and is entirely client side it shouldn't matter much if you call it often, since obviously it isn't an intensive task for the server to relay said information from the call for users.

I'm also going to use 512x512 textures for every "arrow" track in a song. That means a whole song of a minute can be recorded in one 1024x1024 equivalent texture. I know 1024x1024 isn't usually recommended, but considering I'm fitting a whole game song in there, I think the small extra hit of 4 512x512 textures or 1024x1024 equivalent is acceptable.

If I'm making any false assumptions about lag from data transferal or server-load here, please point it out so I can think of a better way to do things that won't inconvenience other SL users.

Sounds to me like you've got it.

If you are concerned about the 1024x1024 texture size (which isn't rude for your usage in my opinion) but may tax the capabilities of some player's graphics cards, you may wish to try a bicubic resampling to 512x512. This is about making your game pleasing to players with widely varied hardware and has nothing to do with "rudeness".

At one point, I had made a nipple piercing texture for a friend by starting out with a big metalic gradient. When shrunk to the size required for wearing (512x512) the metal part was a whopping 3x15 pixels and yet still retained its appearance with perfect fidelity. Yes, it was "stretched" by the skin dressing code in SL, but the stretching couldn't add data not present in the 3x15 original. I was very surprised.

If only every creator gave as much consideration to these issues as you have, the world would likely run twice as fast

Well, the 512x512 per arrow track is doing a resample down to half the size. The original was 16x64. I've asked people what they think and they're unanimously okay with the quality loss, so I'm actually only using 8x32 per "frame". This gives me a little over 1000 frames, which at 15 frames per second lets me have songs of over a minute in length. It's about as low as I can go.

And really, partly why I'm so careful about not contributing to massive server-load and loading-lag for people is enlightened self interest. I want a machine of my own and it won't do if it lags me every time I log into my home location, nor will it help people be eager to buy or use them if they're massive lag fests, and with a project like this the potential is obviously there, so I need to - for my own sake as well as everyone else's - reduce it as much as possible.

I'm glad I found ways to do that though I was inches from giving up. Of course this is all theory, I still need to build out of SL software to generate the tracks and do a lot of other preprocessing to actually get it working with the least load in SL itself. Hope I can stick with it til it's done.

Slight misconception there. llSetTextureAnim() is client side only when it's running. It's a server hit every time you call it. If you call it once and leave it alone, the server tells clients within range what to do with it and they take over. If you keep calling it repeatedly, the server keeps updating the object and clients.

What's the load-hit then, for llSetTextureAnim? Since it has no built-in delay I can only conclude it isn't -too- heavy? Anyone can shed any light on this?

I don't think it's ever been quantified for us, and you're right that a lack of delay suggests it isn't too bad. I just wanted to be sure you understood when it's client-side and when it's not, and that it isn't free.