Jump to content
Sign in to follow this  
RhaDo2496

llSetLinkAlpha

Recommended Posts

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?

Share this post


Link to post
Share on other sites


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);    }}

Share this post


Link to post
Share on other sites

^^ 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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Use llSetLinkPrimitiveParams with PRIM_COLOR and PRIM_LINK_TARGET

EDIT:   Ah, what Arton said ^^^  ;)

Share this post


Link to post
Share on other sites


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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites


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 :D

Thanks for the experienced insight.

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...