Advice, please, on llSetLinkPrimitiveParams

I'm making something to loop through a large linkset changing various things about specific groups of prims, saying something like

string TARGET_PRIM_NAME = "Target";
changeAllTargetPrims(list primParams)
{
   integer i;
   for (i = llGetNumberOfPrims(); i > 0; --i)
   {
      if (llGetLinkName(i) == TARGET_PRIM_NAME)
      {
         llSetLinkPrimitiveParams(i, primParams);
      }
   }
} 

Because it's a large linkset and this has to loop though each prim individually, it's pretty slow.

My problem is this. Quite often I'm changing several things about a prim at once. Among these are things like the colour, alpha or texture.

Obviously there exist several specific functions, llSetLinkColor and the like, which let me change just the colour, alpha or texture. These have the advantage that I can use them to change the colour without having to bother about what the prim's alpha is, and vice versa, which is often all I want to do, rather than have to specify PRIM_COLOR, face, color, alpha all the same time, or the texture without having to bother about the repeats and offsets. This is particularly useful because often I don't know what the alpha or colour or whatever are unless I check them, since they may have been changed by something the user has done previously with the script.

Seems to me that when I'm just changing the colour or alpha or texture, I should use the appropriate function to do just that. But I'm not sure how best to handle situations where I'm changing, for example, the colour, texture and glow all at the same time.

I can't store data in the prims' names and description fields very easily, because I'm using those to identify what to change. I guess I could store all the variables in the script, but that's going to be an awful lot of variables and a lot of long lists to read, and it seems way too complicated to me.

Is my only option in these circumstances to change stuff separately, using llSetLinkSomeSpecific and then llSetLinkPrimitiveParams for the rest, and accept it'll take as long as it takes, or is there another way that I'm missing?

If you call llSetLinkPrimitiveParams with LINK_SET as the target it should effect all prims in the object.

I understand from the original post that different prims are to undergo different (or no) changes, depending on their individual names and/or descriptions; in that case LINK_SET wouldn't have the desired effect.

It's a very special case, but it may be possible to reconfigure the component prims such that only the ones that should undergo a particular change are showing the face to be changed. That would make the LINK_SET approach viable.

The dirty little secret is that very often a bunch of identical tiny "effector" scripts are active in the same prim, tasked to effect the llSetLinkPrimitiveParams() by link_message(LINK_THIS...) from the controlling script, in order to defeat the 0.2 sec delay per call to that function. Of course, every such effector script squanders some part of the benefit achieved by not having a script in every changeable prim.

As long as one is going to have to update prim parameters that require that 0.2sec delay, there's no benefit to calling the separate parameter setting functions. (IIRC, only llSetLinkColor() and llSetLinkAlpha()--and not llSetLinkTexture()--escaped imposition of that delay.)

Usually any appreciable slowness is in the accumulation of those 0.2sec per-call delays (hence the ugly hack above), but if the number of prims to be changed is sparse in comparison to the total primcount of the linkset, it can be worthwhile to maintain a list or lists of link numbers for the prims that are targeted for specific changes. One can populate that list at state_entry and update it whenever changed(CHANGED_LINK).

Oh, I was just looking at the code the OP posted.

In my experience, sometimes a link message and a helper script in each prim is just the only real viable option, despite the llSetLink...() functions. This might just be such a case.

In a case like this I guess it depends on what is more important:

A)Script Efficiency; Use your for loop.

caveat: It is not very pretty as each prim's values are set, one after the other.

B)Visual Effects; llRemoteLoadScriptPin into just the target prims and then send the params via llMessageLinked(LINK_ALL_OTHERS. After execution the scripts will remove themselves.

caveat: 3 second delay! BUT once that delay is over then all of the target
prims will change at the same time.

C)Visual Effects; Qie's effector scripts

caveat: High brain aneurysm potential while trying to code it.

D)Visual Effects; A script in each prim.

caveat: A script in each prim

Thanks, all. I think I'm going to have to live with the delays, though possibly mitigated to an extent by Qie's effector scripts if I can get my head round them.

Part of my problem, as I say, is that I don't think I can keep track of the prims' alpha values and texture offsets and so on without going completely nuts in the process, so even using effector scripts to call llSetLinkColor/Texture/Alpha (as appropriate), so I'm only bothering about -- for example -- setting different textures for different prims without having to remember their offsets and repeats, and loop through the linkset at the same time I'm using llSetLinkPrimitiveParams to set other stuff is going to save a considerable amount of time and effort.