llSetLinkAlpha

[RhaDo2496]

is there a way to use llSetLinkAlpha at a list of faces at same time?

atm im writing them all in single line like

llSetLinkAlpha(3,1,ALL_SIDES);
llSetLinkAlpha(4,1,ALL_SIDES);
llSetLinkAlpha(5,1,ALL_SIDES);

so every face goes visible one after one. how to script it that they go visible all at same time?

[Codex Alpha]

---

RhaDo2496 wrote:

is there a way to use llSetLinkAlpha at a list of faces at same time?

atm im writing them all in single line like

llSetLinkAlpha(3,1,ALL_SIDES);

llSetLinkAlpha(4,1,ALL_SIDES);

llSetLinkAlpha(5,1,ALL_SIDES);

so every face goes visible one after one. how to script it that they go visible all at same time?

---

 

Function: llSetLinkAlpha( integer link, float alpha, integer face );

- http://wiki.secondlife.com/wiki/LlSetLinkAlpha

 

LINK_SET

-1

refers to all prims

 

// Make the entire object disappear for 5 seconds default{    touch_start(integer num_detected)    {        // transparent                llSetTimerEvent(5.0);    }     timer()    {        // opaque                llSetTimerEvent(0.0);    }}

[RhaDo2496]

^^ ofc i know Link_SET but i cant use it its couse the object have to hide the one halfe of his prims while the other is visible and reversed.

[Codex Alpha]

Then use a for loop, as you can see on that LSL function description page.

[arton Rotaru]

You could use PRIM_COLOR, and multiple PRIM_LINK_TARGET flags in a single llSetLinkPrimitiveParamsFast function call. But don't add too many prims to a single call.

[Rolig Loon]

Use llSetLinkPrimitiveParams with PRIM_COLOR and PRIM_LINK_TARGET

EDIT:   Ah, what Arton said ^^^ 

[Codex Alpha]

---

arton Rotaru wrote:

You could use PRIM_COLOR, and multiple PRIM_LINK_TARGET flags in a single llSetLinkPrimitiveParamsFast function call. But don't add too many prims to a single call.

---

Thanks for adding that tip.

Is there really any difference between using separate calls, and putting it all into one call as far as the SL 'interpreter' is concerned?

Why would I use it ( its like a shorthand version ) over perhaps a more clear separate call?

 

Also, If I have a product with 10 prims that need to have this applied to in the product, would this be the best way to perform the task? For readability, debugging and future changes/tweaks, I just used llSetLinkPrimitiveParamsFast in a for loop, and changed properties based on current index. One statement, but looped.

From a coding standpoint, would it be more difficult to read or maintain?

Thanks for any additional experienced info and/or clarification WHY to use this method.

[Love Zhaoying]

Putting it in one call, the actions occur faster - especially if you use lLSetLinkPrimitiveParmsFast()! (Except for any specific calls that have built-in delays).  This is the main reason to use certain "multiple-call" formats.

 

The code is clear if you structure it so that you can see each individual call

llSetlinkPrimitiveParamsFast(link_number,

[CONSTANT1, parm1, parm2, parm3,

CONSTANT2, parm1, parm2, parm3, parm4]);

etc.

[arton Rotaru]

When simultaneity is important, like it seems to be in the case of the OPs alpha toggle, PRIM_LINK_TARGET is your friend. It tries to do it all in a single frame.

Personally I use it only for small numbers of prims (like up to 5 or 6), and when simultaneity is of concern. Otherwise I run the function in a loop as well.

I dunno if it's has much of an advantage regarding the interpreter. The list has to be proccessed as well, and if it's too large (too many prims) it might get worse, doing it all at once.

[Codex Alpha]

---

Love Zhaoying wrote:

The code is clear if you structure it so that you can see each individual call

llSetlinkPrimitiveParamsFast(link_number,

[CONSTANT1, parm1, parm2, parm3,

CONSTANT2, parm1, parm2, parm3, parm4]);

etc.

---

True.

---

arton Rotaru wrote:

When simultaneity is important, like it seems to be in the case of the OPs alpha toggle, PRIM_LINK_TARGET is your friend. It tries to do it all in a single frame.

Personally I use it only for small numbers of prims (like up to 5 or 6), and when simultaneity is of concern. Otherwise I run the function in a loop as well.

I dunno if it's has much of an advantage regarding the interpreter. The list has to be proccessed as well, and if it's too large (too many prims) it might get worse, doing it all at once.

---

 Yes, that is what I would think... if it really shaves off any noticeable time using it either way. I'm more trying to understand if there really is that big a difference between the two, as in a simple thing like turning on/off visibilty on child prims appears seamless as it is - in fact I added time in between to simulate the delay of multiple power sources going on

Thanks for the experienced insight.

[Nova Convair]

Using one call will make sure the change happens in one frame.
If you want to use a loop just build the parameter list and then use llSetLinkPrimitiveParamsFast.

list params;for (...) {    params+=[PRIM_LINK_TARGET,...,PRIM_COLOR,...];}llSetLinkPrimitiveParams(LINK_THIS,params);

The max. # of parameters I don't know, but warpPos is still working and that uses about 1000 list entries in one call.
The # of faces and prims for one call I don't know, but you can find out maybe.

 

[Qie Niangao]

---

I'm more trying to understand if there really is that big a difference between the two

---

It's pretty big, as such things go. Just in genral it's best to minimize the number of library function calls -- use one big one instead of a lot of little ones whenever there's a choice. That's true not only in LSL, but especially in any language that doesn't compile all the way down to native instructions. (And in LSL that rule of thumb used to be a very big deal indeed, back before Mono.)

For setting link primitives, not only sim resources are involved, by the way. If multiple changes are being made to a single prim, grouping them all into a single update reduces demand on both network and viewer.

The downside, as Arton mentions, is when the list gets too big. It does have to fit in memory for as long as it's in scope (so a script can't safely cons up lists where the length is only knowable at runtime).