Welcome everybody. I am Auryn Beorn and I'll be your instructor for this class.

Lag is the common word used to name a slow reaction time when we're using an online application, like Second Life, World of Warcraft... anything like this that you can think of.

The fact of existing a slow reaction time means that "something's happening", either at client side, or at server side. The reasons and main culprits are discussed in detail in the class "LAG! Every script counts" and will not be the focus for this class.

This class is for the concerned builder that, not knowing about scripting, wants to use the basic effects in their builds, not creating lag. We'll talk about which effects and properties of our prims don't require of a script once it's working, and explain how to use the scripts in the supplies (free in Marketplace), which purpose is precissely that: to give you all, builders, a basic set of tools with zero lag cost.

There's something that all the people attending my scripting classes have listened me saying more than once, insisting once and again on it: the importance on knowing which the persistent properties for a primitive are, because that allows us removing the scripts in a lot of cases.

I'm sure that some of you have listened me saying, a lot of times: "if the particles are meant to be activated «forever», once the particles are on, delete the script, you don't need it", "once the texture animation is on, delete the script, you don't need it", "once the hover text is on, delete the script, you don't need it"... right?

Just by existing inworld, those scripts use resources from the server. If, once the effects are started, we don't need the scripts anymore... Why are we making the sim use these resources (including memory, yes!)? We don't neet to misuse the resources this way. We have to be responsible: Delete the script once you don't need it anymore. Keep a copy in your inventory, but delete the one in the prim.

I know, sometimes we simply forget about deleting. So all the scripts that I've included in the supplies in that regard, not just cover the most common uses for effects, but also autodelete themselves.

So... Let's begin examining the scripts from the "box of goodies" :o)

Beginning by the invisiprim script.

Important NOTE: Because of the invisiprim being broken when shadows are on, and because nowadays invisiprims are rarely used anyway (alpha layers do their work when it comes to being used in avatars), I've moved the whole section to the end of this page, once the rest of the class content is done. Invisiprims can still be used, griefers may use them, and it's important to know about them for that reason. Click here to get to the invisiprim section if you want to read it now :-)

We all know that primitives have several properties: Size, texture, rotation, "torture" parameters (path cut, twist, etc), the flexi parameters, light properties... right?

(The invisiprim texture is a texture, but as we've seen, it needed from a script to be set anyway).

Now, it turns out that there are other prim properties, BUT that can be set ONLY with a script: Particles, sound, animated texture, hover text, sit target...

These are properties that belong to the primitive, but these properties need a script to be set.

What do I mean with this?

Probably some of you see me coming: That once one of these prim properties has been set by using a script... We can delete the script.

So we may have, for example, a prim with a looping sound, with no script inside.

Do you want evidence?

Rez the "[Black Tulip] Haunted Box :o)" object included in the supplies folder, zoom your camera close to it so you can listen the sound louder.

Now inspect the box. Do you see any script in it? Even more... Do you see any sound clip in it?

The naughty box is sounding without assistance!

Because it has a loop sound set by a script, and once the script has set this property, we can get rid of the script.

So let's cover, one property at a time, the scripts from the supplies, which for many of these properties come in pairs: one script to help us set the property, another script to help us remove the property.

Do we want to SET a loop sound?

(Remember that the properties are PER prim. Not for the whole linkset. Each prim may have a different sound. That could sound like a real musical mess, but that's a different issue :o) )

So what we have to do is:

• Drop the sound in the prim
• Drop the script "Play loop sound & autodelete"

If there's a sound clip in the prim, the script sets the looping sound and commits suicide :o)

Then you can even delete the sound, as you all can see in the prim here, by inspecting it, and the prim will have the sound looping.

Now... How do we get rid of the bells?

Following the opposite way: Using a script to STOP (clean) the loop sound property for the prim. If I drop the "Stop loop sound & autodelete" script from the supplies, two things will happen:

• The script will STOP the sound
• The script will autodelete

(Do this! :-) )
And there it is: Silence.

It's true that one can use a script like The Scrubber (which is included in the supplies also, allowed according to the license for it), to clean ALL the prim properties at once, but I've also included several scripts to stop independent properties, because sometimes we want to stop only particles but not the sound or the texture animated. Sometimes we want to stop the animated texture, but not losing the hover text!

Same happens with animating textures, like rotating water, or a smooth motion, to name a few. Once the effect is running, we can delete the script. We don't need to be scripters to use these two basic effects in our creations, so I've included the following scripts in the supplies, and specified where to change the rate, for the animation running faster or slower:

Rotate Texture Smooth & autodelete
Texture Smooth & autodelete

The scripts delete themselves once the effects begin running. Easy, clean.

You can try this by doing the following:

• Rez the "[Black Tulip] Box to try the animated texture scripts" object from the supplies folder.
• Edit it, drop the "Rotate Texture Smooth & autodelete" script, for example.
• See how the texture is animated, even after the script self deletes.

Do you want to change the velocity for the texture animation, because it is too fast or too slow for you?

Then do this:

• Decide which script you want to modify (rotate or smooth).
• Edit this script in your inventory.
• Look for the line that says:

  float   rate = 0.05;    // Is this value too slow or too fast? Change it here, save your script.
  

  and where it says the 0.05, change that value and save the script.
• Once you've done that, you can drop the script in your prim.

The smaller the value, the slower the texture will be animated.

NOTE: If you change the value for face, you can make the script to animate just one face, instead of all of them (ALL_SIDES means "the texture will be animated in all the sides")

Once more, we have here an effect that, once set, doesn't need from the script anymore.

You can try this by doing the following:

• Rez the "[Black Tulip] Box to try the hover text scripts" object from the supplies folder.
• Edit it, drop the "Hover text & autodelete" script, for example.
• See how the text shows over the prim and stays there, even after the script self deletes.

How do we change the text?

Let's do it easy again:

• Edit the "Hover text & autodelete" script in your inventory.
• Look for the line that says:

  string  myText = "Sample text";    // Change the text here
  

  and change the text "Sample text" to the one you want, save it, and drop the script within the prim.
• Once you've done that, you can drop the script in your prim.

The script deletes after setting the hovertext. We don't need more.

A few prim properties are lost with shift+copy, if there's no script inside.

This is not a major issue, because of the following: if we take a copy of the prim with the effect, and then rez it again, we have a second prim with the same effect.

So, for the few properties that are lost on shift-copy (link for the JIRA filed, if you want to read more: https://jira.secondlife.com/browse/SVC-3925), that is:

• Hover text (FIXED!)
• Texture animation
• Sit target (FIXED!)
• Sound loop
• Text for "Touch" and "Sit" in the right pie menu (FIXED!)

Remember to do this once your script has autodeleted:

• Take a copy of the prim
• Rez again

In case you need more copies of the prim with the effect running.

IMPORTANT UPDATE: Also, this bug is finally being fixed, for some properties. So far, the following properties are fixed: hover text, sit text and sit target. We have to expect this bug will be completely fixed soon for all the prim properties that, nowadays, get lost on shift+copy.

Try for example shift copying the box with the hover text, and see the hover text remain. Don't forget this! Probably soon we won't have to worry about this anymore.

The same way that effects are started, we can stop them. There's a script that removes at the same time particles, texture animation, hover text, and other effects that the prim might have set. It's the well known "The Scrubber" from Jopsy Pendragon, included in the supplies. Also, I've included six separated scripts: for stopping a texture animation (single prim, whole linkset), and just that, deleting an hover text (single prim, whole linkset), and just that, and stopping particles (single prim, whole linkset), and just that:

• Stop Animating Texture (single prim)
• Stop Animating Texture (complete linkset)
• Stop Particles with Autodelete (single prim)
• Stop Particles with Autodelete (complete linkset)
• Delete Hover Text (single prim)
• Delete Hover Text (complete linkset)
• Stop loop sound & autodelete

Short note completely out of the blue

This came up in another class, as a question, and I consider it's important to know about. Since I don't know where to fit this, I've just labeled this section "out of the blue" :o)

There's the belief that spinning prims lag the server.

This is true ONLY if they are PHYSICAL. And physical is not the default option we create our prims with: Prims by DEFAULT are NON PHYSICAL. So a spinning prim doesn't lag the server, by default.

It's mentioning a "resizer" and, nowadays, close to 1/3 for all the lag suffered in SL comes to our minds, right?

2013 note: Remember the context... 2011! :-)

This happened because, as a start, many creators believed that no modify objects could not be ripped. Truth is, no modify objects won't stop a thief. But still, against evidence, many creators decided to make shoes, hair, etc, no modify.

Now, one can't sell a hair that the customer can't even resize. So, many creators looked for a solution in scripts.

By the time this happened, the only possible way to change properties for the primitives in a whole linkset was by having one script per child prim, plus a main one, that internally communicated with the rest, to make it possible that a no modify hair (say) was able to have the size changed at least (or texture, or color...).

The result for this was, all of sudden, "gazillions" of scripts all over the grid, lagging it really badly.

This made the Linden create new scripting functions using a new philosophy: one script to rule all the properties for the prims in a linkset, as a measure against all that misuse of scripts (who said they never care?). That way, if creators used this new tool wisely, they could keep their no modify objects, but with a considerable cut in the script usage.

That's how the first low lag resizer script was written, and guess what? It was written by a Linden, and it's set for free in the wiki.

Nowadays, there are two versions for a linkset-resizer-scripts in the wiki. I've included in the supplies the following one from the wiki:

Linkset Resizer Script

If you have to use a resizer in your creations, use this one.

Moral for this story: See how much damage can be done just by being misinformed and believing everything without having facts that prove what we're said?

2013 note: Of course there are valid reasons to decide making an object to be no modify. But if you want no modify only to "protect" your object from being ripped, then that's not a valid reason. Sadly, no modify objects can be ripped. Copybotters have proved this widely >.<

Speaking about resizers, this is something else I want to talk about: When we can expect a task being done by a single script, when no.

As you are noticing, like it happens with the resizer (which resizes ALL the prims in the linkset), many properties can, not only be set and forget about, but also, be controlled by one script. One single script that exists only in one prim (usually, the root).

We, as builders, need to know which properties for ANY prim in an object can be accessed by a single script.

Why?

For example: Because if we need a complex texture changer, and we find a script (or a scripter) that tells us, the texture changer will need to get a copy injected in each child prim... We're doing a bad deal.

We need to know this too, not to get fooled, and to know what to expect... from a scripter.

Note: As a scripter, I've always said to my students "Never trust a scripter, knowledge is your self defense kit against crooks", and I used to randomly trick them at class to prove my point.

So let me do a list of many, many properties that can be set from ONE script:

• Position, size, rotation, "torture parameters" for the prim... including SLICE!
• Flexi properties
• Light properties (except projectors - as of 2013)
• Texture properties
• Animated texture
• Particles
• Target omega
• Hover text

ALL of them can be controlled by a SINGLE script.

So if someone is offering you a cool particles weather system that requires a script per prim in a linked object, you're likely doing a bad deal. Ask why so many scripts. What are the options? A different effect per node? How different? All the properties different or just a few?

There are still a few properties, tho, that DO NEED a script per prim to be controlled, and we, of course, need to be aware of them. Keeping in mind, of course, that this COULD CHANGE in the future (as it has happened recently with TARGET OMEGA, now also accessible from ONE script for ALL the child prims).

How to know?

Reading the last server release notes
(If you're that curious :o) )

Properties that still nowadays need a script per prim are, for example, the loop sound :/ That's why I could not offer a serial killer for sounds, because, as of 2011-10-02, sounds still have to be controlled PER prim.

Also, applications like texture organizers STILL need a script per prim holding categories, because the inventory functions can't be used but by the prim containing the script :/

A prim can't access, as of today, to the inventory of another prim, so a texture organizer, a sound organizer, using categories... The scripter is not fooling you. We still need a script per prim in those cases.

Note: Actually, there's a trick that can be used to reduce the script count in those cases, but because of the requirements, and the complexity added to processing the data correctly, it may not justify the effort, being preferable the one script per child prim approach in this case. For example, T-Mat shuts itself down after being unused for an hour, reducing considerably the script time, so it's a case of a one script-per prim tool that is worth using.

Also, daily-use HUDs, like texture changers for hair, shoes... should not require more than one/two scripts (if it has a lot of functions... it could be three scripts... point is, we're not talking about 20 of them! 20 are too many.)

Unless there are many timers, listeners or sensors involved, one should NOT expect an application requiring from many scripts, and many can be done with just one.

You know that you need a timer, when you need an action that is repeated in time.
You know that you need a sensor when you want to know who is around.
You know that you need a listener when you expect the script reacting to commands in chat or menus.

To complete this list about good and bad deals, let's not forget about animating avatars.

One script can animate one avatar AND make the avatar change the pose to another one among several. A script can animate one avatar, and once the permissions to animate are granted, the SAME SCRIPT can make the avatar change the animation that is being played.

The rule is: One script per AVATAR. Because one script can't animate more than one avatar at once, but that's it all: the script can change the animation.

Note: Actually, again, there's a trick that can be used to animate several avatars sitting on an object, allowing to choose several poses each one, by using just one script. But then again, coding the trick leaves us with a script that has little memory to store animation data, so it may not be worth it. This trick could be combined with storing data in an external web server, and so bypass the memory problem, but I personally still have some reservations against having the script data stored in an external service. This doesn't mean, of course, that you shouldn't use those tools. Take an informed decision and decide what works best for you.

So I hope that all this information helps, on one hand, for us, builders, creating non laggy objects, and on the other hand, for us, builders, taking an informed decision and not letting a scripter to mislead us ;-)

And this is all!

-- Auryn Beorn

First question... Do you all know what an invisiprim is?

There was always people not knowing what invisiprims were, so I always explained what they are.

An invisiprim is a special prim that's used to hide the avatar, like the one I'm going to prepare now.

Ok, everybody please pay attention to the prim that has attacked my hand.

I'm going to drop a script in it, that will perform the following:

The script will change the texture of the prim, directly by UUID. This texture is a special texture that does not exist in our inventories.

That special texture, when it's applied in a prim, makes the prim to have a special behaviour:

• The prim hides the avatar
• The prim hides any other prim that is partially transparent
• The prim hides the Linden water

Pop!

Like the box is doing right now.

And check how the invisiprim hides the Linden water! You can really tell where it is:

How come this texture can be applied, if it's not in our inventories? Because you don't need to have a texture in your inventory to use it with a script, you only need to know the UUID.

That's why some of you have listened me yell so much when UUIDs that are not my samples are said in local chat :-)

I could take those UUIDs and use the texture, not having the textures in my inventory. What a bad joke for texture creators, right? Never, never forget the TOS, and never communicate the UUIDs. That's the same as giving them away.

Everybody has clear now what an invisiprim is?

Ok, back to me again :-) (and so I detached the prim)

This special type of prim has been used widely to hide the avatar feet when creating shoes, but it's not the only use it has. And as we have seen, it has to be created by using a script.

Although soon we won't need this anymore for shoes, the invisiprim still might have other interesting uses. In any case, anytime you need an invisiprim, the procedure is as simple as this: drop the script "Invisiprim & autoremove script" in the prim you want to convert in the special invisiprim one. The script does its job, and autodeletes itself.

2013 note: And once again... Context! :-) - In 2011, alpha layers started to be widely used, but there were still people in old viewers that didn't support them. Shoe makers used to give two versions: invisiprim and alpha layer ready shoes. Nowadays, in 2013... Alpha layers is the way to go for shoes, and likely no new shoe creations use invisiprims anymore.

Also, it's important to know about this prim and the script used to create it, for a reason: Many no modify shoes have this invisiprim script in. Wait a moment. The invisiprim script from the supplies? I wish.

• Many no modify shoes have an invisiprim script using a timer to refresh the texture (which is not needed at all)
• Many modify shoes have this laggy script I'm referring to also

So this was important to know, not only to use the script from supplies when we need an invisiprim BUT to clean, if possible, all of our shoes!

Now we know what the invisiprim is. Now we know that, once the script has done its work, we can remove it. So not only create your items with the script in supplies: now that we're aware that many shoes use a laggy version... Delete that old invisiprim script from your shoes, and tell others about, so they do the same.

This will be necessary until alpha layers are finally settled, and nobody uses the old shoes with the laggy scripts (ok, and of course, it is necessary if we use invisiprims in other applications).

The script from the supplies folder is going to create really, really low lag... as low lag, as a non existent script can create. No lag at all. This is a good counterpart for all the shoes we see around, using a useless laggy script for the invisiprims.

Let's not forget about an important detail: invisiprims can be used by griefers to simply fill your parcel with prims that you're going to have a hard time to find.

Let me rez the invisiprim from before. Now, next to it, I rez a box that I'll make TRANSPARENT, which is NOT the same as an invisiprim. Of course, right now, you can't see the invisiprim in the picture, because there aren't avatars or transparent things it could "eat" :-)

Now I make the second box transparent, and enter into transparent mode (CTRL ALT T)

Now you can see the problem: Invisiprims don't appear in transparent mode, while the box I've just made transparent, does.

Now I move the transparent prim toward the invisiprim, so they overlap. See the changes in how the transparent box is represented in transparent mode:

The invisiprim is, so to speak, eating the transparent one.

And how do I know that the invisiprim is there?
(Apart of course that I know where I've rezzed it :o) )

Ok, follow this menu:

Develop: Metadata: Bounding Boxes

Everything will be outlined with the corresponding bounding box.

And this, YES, includes the invisiprim.

That's how I know the invisiprim is there.

So if you suspect that somebody is using your prims, use this display to find invisiprims. They can't hide from this :-) (Or, of course, to find one you could have lost!)

Now, again "Develop: Metadata" menu, and we untick the "Bounding Boxes" setting to stop seeing the bounding boxes. It's kind of a trippy sight! :o)

Then CTRL ALT T for exiting transparent mode... and we're ready to continue.

We have a whole box full of scripts to explore!

Some effects used in jewelry, as the glassy one, require from a script which performs almost the same task as the invisiprim script. Same happens here, then: we don't need the script in our gems anymore, once the script has done its job. So I've included three related scripts in the supplies that autodelete themselves after doing their job:

Invisiprim + Shiny HIGH
Invisiprim + Shiny LOW
Invisiprim + Shiny MEDIUM

2013 note: This effect nowadays doesn't work as it used to. But the paragraph is kept for completion, as well as the scripts.