Script load

[Ally Whitefalcon]

I'm curious how bad certain things are to do in scripts, and what to avoid in order to not be a Bad Script. I'm no software engineer, so maybe some things that are obvious to programmers aren't so obvious to me. Do scripts run on the server or on people's viewers? How does one tell how much a given script is contributing to, idk, lag or script load, or whatever?

Say I want to write a script (yeah, I'm sure one exists somewhere already, maybe I should just find one) to make a lamp flicker a bit, as if it's a candle. That means (I think) a timer firing a lot - maybe a few times a second? Is that too much? Will that make it a Bad Script?

Is there a way to measure the load a given script is putting on the system?

Thanks

[Profaitchikenz Haiku]

If you are an estate manager on an island you can look in the top scripts console to see metrics for script time, and I think one or other of the TVS can also give you some sort of measure. Have a look through the recent threads in the technical section on idle scripts for other ways of assessing script time as well, but bear in mind what you will be measuring will be both the script itself and the impact on the server if all the other things going on.

[Wulfie Reanimator]

Scripts only run on the server, never in the viewer.

That said, the answer is definitely... subjective.

There are lots of things that could be considered "bad." Sometimes those "bad" things are better than other options. Sometimes "bad" things can't be avoided, or the "less bad" alternative takes more effort than the improvement is worth.

Is a fast timer bad? How fast is it? How long is it active? What does it do? How much script-time does it take to do that? There are so many things to consider.

At least on Firestorm, you can right-click any object and select "Script Info." This will give you a message in chat which shows you some details about the object's script usage. Most importantly, it tells you the average amount of "CPU time consumed" by the script. This is by far the easiest thing to keep an eye on after you have written your script. Script time can vary wildly per script/object, so you just need to get a feel for it from experience.

For example, in order of script time:

• 15 scripts, 0.032720 milliseconds - My avatar in total
• 6 scripts, 0.027171 ms - Assault rifle with AO, unknown timer (idle use)
• 3 scripts, 0.009672 ms - My regular AO, unknown timer if any
• 3 scripts, 0.007124 ms - My mesh head, unknown timer
• 3 scripts, 0.006660 ms - My rifle with AO, 0.1 second timer (idle use)
• 1 script, 0.013944 ms - My attachment with 0.1 second timer
• 1 script, 0.006975 ms - The same attachment with 0.5 second timer
• 1 script, 0.001735 ms - My bento tail, unknown timer if any

These values can fluctuate by a lot, as well. A gun (or any object, really) might use little script time when nothing is happening, but increase by tenfold when it starts working.

But if all you want to do is change the appearance of a light every X times a second, it's going to be pretty hard to make it a "bad/laggy script." Just focus on what looks right, first. You could then come back and ask for opinions or more advice.

[panterapolnocy]

If you look for some small tips LSL Portal is still the best place to go (like, the tutorial). For example http://wiki.secondlife.com/wiki/LSL_Script_Efficiency would tell you a bit about how to write some basics and http://wiki.secondlife.com/wiki/LSL_Hacks may show you some creative ways to play with the language, but the best place is just to explore the functions reference; Every one of them have tons of interesting caveats and tips.

For your lamp see llSetLinkPrimitiveParamsFast() or llSetTextureAnim().

Edited July 3, 2019 by panterapolnocy

[Fenix Eldritch]

First up, kudos to you for being conscientious about sharing the limited resources scripts have to play with!

You can get a generalized reading on how much time the server spends processing a script via llGetObjectDetails and the OBJECT_SCRIPT_TIME constant. This assumes the object only has one script in it, otherwise it's an average for all scripts running in the thing you targeted.

6 hours ago, Ally Whitefalcon said:

Say I want to write a script (yeah, I'm sure one exists somewhere already, maybe I should just find one) to make a lamp flicker a bit, as if it's a candle. That means (I think) a timer firing a lot - maybe a few times a second? Is that too much? Will that make it a Bad Script?

Speaking to your specific example, depending on the details, there are lots of ways you could approach this effect.

For example, instead of using the timer for every single flicker, you could instead have a custom routine that simulates the flicker by turning the light off, sleeping for a small amount of time, then turning the light back on. You could repeat this sequence a few more times in the routine to have a short burst of flickering. Then, you would start a timer on a longer delay to call this routine whenever you wanted to initiate a burst of flickering. In fact, you could randomize the timer at the end of each flicker routine to make it look more natural instead of flickering at constant intervals. Of course, I'm just assuming your lamp would be on most of the time, and flickering every so often.

If you intend to flicker you lamp constantly, another approach could be to use texture animation to simulate the visual effect in the client. This would be by far the least laggy from the server's perspective since texture animations are done one the viewer and you could skip and timer based updates altogether. The drawback here is that you'd need to make a custom texture cell animation to get the feel of a flicker when played. And if you are doing other things like enabling/disabling actual light sources, those would still need a timer - and would likely not say in sync with the client side animations.

Just to give you some ideas.

Edited July 2, 2019 by Fenix Eldritch

[Ally Whitefalcon]

Thanks!

 

[Arduenn Schwartzman]

If you really rely on a timer for your special effects, maybe include a slow-timed scanner that stops the effects whenever there aren't any avatars nearby anymore (say, further than 20 to 40 m).

But animated textures are really the way to go, especially for fast changes. The dozens of flickering lights in the spaceship below are really just one single face with a texture animation (the animated GIF may take a minute to download):

It uses this texture to make the lights flicker:

Edited July 3, 2019 by Arduenn Schwartzman

[Qie Niangao]

As long as we're talking about using animated textures to make blinkenlights, just a reminder that the Emissive Mask flavor of Alpha Mode makes stuff fullbright or not (or a fullbright gradient), without need for updating a prim property. Or at least it works if the viewer is set to Advanced Lighting Model. Also, it "uses up" the diffuse texture's alpha channel, so a surface painted with an emissive mask will be fully opaque.

None of this causes blinking of point/projected light effects cast on nearby surfaces, which are pretty viewer-laggy anyway, but they too can be shown by projecting the light source through an animated alpha texture -- no script required -- but only if shadows are enabled in the viewer.