single-call link # function calls?

How can llSetLinkColor (and other link functions) apply to multiple prims in a linkset (object) with a single call? I want to do this to the function's prim AND 1 or more other prims--but not ALL child prims (OR necessarily the root prim).

I take it you didn't see "other link constants" in the middle of the sentence describing what LINK_SET did for llSetLinkColor.

If the answer you see is not on that page, then the answer you seek is: "It's impossible".

Um, sure I did (since I added it!)--check the edit history, "Blind Wanderer"... I doubt it's IMPOSSIBLE; it simply needs to be IMPLEMENTED by LL.

*rolls eyes*
Ok "It's Currently Impossible"

LL could implement a hotkey to eject my CD tray but they probably won't.
As to making llSetLink* functions work on multiple prims you could request LL add new LINK_* flags. I recommend Kelly's feature suggestion cylinder. Or were you thinking changing the syntax for the llSetLink* functions?

Edit: speak of the Linden (was taking my time to write).

Kelly, do you still read the feature suggestions dropped on your cylinder? It's been a while since i heard back on any of them .

Well, yes, ideally, any function that uses link numbers should have this functionality. How about it, Kelly?

Eep: How would you go about defining an arbitrary subset? (or did you mean more LINK_* flags).

I don't think more LINK_* flags is the way to go. Perhaps:

llSetLinkColor(integer [LINK_NUM1,LINK_NUM2], vector color, integer face)

Save the one prim color you don't want to change, change them all in one call, then set it back on the one prim. There, three calls.

Other than that it should be simple enough to make a subroutine for changing a given set of prims using a list to store the link numbers, and a for loop ?

Um, no, Jesrad. I don't want the other prim(s) colors changed at all. I am trying to do this in a SINGLE call since SL/LSL isn't fast enough to update multiple linked prims (not already defined in the link constants) fast enough. A FOR loop does nothing to fix this (and a list is unnecessary).

If you want to make it work for a subset of prims as quickly as possible, you may have to have a script in every prim that does something like this:

integer MY_COLOR_CHANGE_BITMASK = 0x0010;

//...

link_message(integer from,integer num,string str,key id)
{
  if(num & MY_COLOR_CHANGE_BITMASK) llSetColor((vector)str,ALL_SIDES);
}

Um, why? llParticleSystem and llSetPrimitiveParams use this syntax...what's the big deal about applying it to llSetLink* functions too? I wasn't sure where to put "integer" but was just trying to show that values in brackets weren't necessary but if multiple values WERE there, they WOULD be in brackets, like other functions do...

No need for new functions; just add an extension for some so they can take multiple parameters in brackets for link #s, sides, etc (but also accept single parameters without brackets). Shouldn't be that hard to do...

I'll try it but I doubt it'll be any faster than 2 llSetLinkColor calls (since it has no LL-imposed delay). What's the bitmask for? I want to have a random color so couldn't I just pass that vector instead?

llParticleSystem & llSetPrimitiveParams each have a list paramater not an integer.

"integer [LINK_NUM1,LINK_NUM2]" is a really scary syntax, because it suggests superposition of states; an integer with multiple values (in this case). Implementing such a thing in LSL would require rewriting all of LSL, I'm not exagerating; the LSL bytecode makes no pervisions for anything remotely like this, all functions would have to be rewriten, the way paramaters are passed to functions would change. It is a bad idea.

Lets pretend for a moment what you inteded was to overload llSetLinkColor. For someone who edits the wiki so extensively not to understand the syntax of function definitions (they are at the top of every page) is a travisty; not to mention bring into question his ability to script. So pretending is what we will do as to avoid such a posability.

llSetLinkColor(list faces, vector color, integer face)

In the bytecode this would require a new function to be built (there is no way to detect the difference in the LSL bytecode between an integer and a list pointer). Since such a function would be selectively updating prims in the object it would probably have some delay on it proportional to the length of the list.

Well, perhaps when Mono is implemented in SL it should be written to accept this, then.

I never claimed I was a programmer--in fact, I couldn't stand programming until I started learning LSL (but it's not a real programming language anyway, so I probably still can't stand a true programming language--but at least I'm more comfortable with its language and general syntax).

Why not?

Well, how do the link # constants do it so fast then? Perhaps multiple constants are needed: (LINK_ALL_CHILDREN !LINK_THIS) or (LINK_SET !LINK_ROOT).

Unfortunately, using the integer as a bitfield, which is what you seem to be suggesting by:


Will only allow you to address 32 primitives of the 255 currently allowed primitives of a link set. We would need a bigger integer for it to work that way. Not to mention a rewrite of the llSetLink* functions.
==Chris

1) This would require rewriting all code currently writen for implementing LSL in mono and requiring years of developer time. Trust me on this, it's not going to happen. I know there are times when SL seem to follow the laws of quantum physics; but we really really don't need quantum physics support in LSL. It would also confuse the heck out of everybody.

2) I take it you mean "Why can it not tell the difference between list pointers and integers." because LSL does not store types; only lists keep track of types. When lists are built by user code, the type of the variable is defined in the bytecode at the time it is inserted in the list. Its up to the compiler to track what the type is for that location in the stack. A couple years ago LL had screwed up how "--" worked on floats where the compiler mistakenly thought the return type was not float but integer. The result was the same effect as using a C Union on a float and integer. Keeping track of types at runtime would slow down LSL (if you can imagine that).

3) That syntax you have provided is invalid. LL could define new constants like LINK_SET_BUT_NOT_ROOT. But I don't see much point to that one. Just use a link message and route the call to the root and call with LINK_ALL_OTHERS or LINK_ALL_CHILDREN (will have the same effect).

If the way Argent suggests gives trouble since linkmessages might not arrive at exactly the same times, maybe a time could be sent in the link message from the synchronizing script and then when receiving the message, hold the scripts in a while loop until time+1 before setting the color. I dunno, but I'd guess it would improve the chances of setting the colors at approximately the same time.

Whatever. People just aren't used to it (though I suspect they are but just don't realize it).

Mono is supposed to run LSL faster, right? Why couldn't it keep track of types at runtime faster then?

That's slower. What about LINK_SET_NOT_SELF_OR_ROOT? Link functions just need more optimization. Rewrite 'em, I say. Poor initial design, it seems...

Functions with a side parameter should also be rewritten to allow multiple sides in a single call.

Nope.

A new function (eg: llSetColorList(vector color, list sides);) should be implemented.

In LSL, types matter. In a language where types are derived or implicit, things would be very different.

For example, in an OO language with late binding, color and sides would be classes, so the call would be object.sides[0].color = color; rather than llSetColor(color, 0);, and to change multiple sides you'd call object.sides[set(0,1,2,4)].color = color;. But that's clearly a different kind of language than LSL.

why don't you just use a for loop?

Too slow; see above.

A new function is unnecessary. LSL's current functions simply need to be written better to allow more versatility.