More ability to affect link prims from same script!

I was pondering awhile about the usefulness of llSetLinkColor() when it dawned on me. It would be incredibly interesting and useful if we had a whole set of llSetLink* and llGetLink* functions.

I am currently scripting an object that requires scripts in each of its child primatives just because we dont have something like this. This is horribly un manageable, and creates additional stress on the simulator.

---------

Here's the rundown of what I'm requesting:

llSetLinkPrimitiveParams(integer linkNum, list parameters);

The linkNum parameter would have the same significance as it does with other link functions, accepting either the link number of the target prim, LINK_SET, LINK_ALL_OTHERS, or LINK_CHILDREN.

Example usage:
llSetLinkPrimitiveParams(LINK_ALL_CHILDREN, [PRIM_SCALE, <3,0.2,3>, PRIM_POSITION, <0,1,0>]);
This line would set all child primitives to <3, 0.2, 3> scale, and at an offset from the parent of <0, 1, 0>.

Parameters passed to this function are equivilant to those passed to llSetPrimitiveParams, with these exceptions:

PRIM_POSITION - Acts like llSetPos() does with child prims - accepts an offset vector from the parent. (This does nothing to the parent prim.)

PRIM_ROTATION - Acts like llSetRot() does with child prims. - Accepts a rotation. (This does nothing to the parent prim.)
---------

I think this would cut the load necessesary to create equivalent functions by putting scripts in the actual child prims themselves. I could have a parent prim controlling the movement of its children, and it would be totally independant of the scripts in the children, the children woundn't even need to have scripts.

I also think that this is completely possible, but abandoned for some reason. llSetLinkColor() is alive and well, so why not other llSetLink*() functions?

==Chris

EDIT: Provided nice formatting for everything

EDIT2: Changed the suggestion to one function, like the llSetPrimative() function proposed by Cory here.

EDIT3: Changed the constants to match those of llSetPrimitiveParams.

This thread seemed to fall quite rapidly to the second page of Feature Suggestions.

Is it really *that* bad?

Bump! This is quite an old suggestion, but it still has relevence. I updated the suggestion a bit more (see EDIT3 at the bottom of the original post) to conform with standards set by the llSetPrimitiveParams function.
==Chris

I endorse this.

More linking features via script would be great.

Bump

/bump

/stamp

<bump>
<stamp>
<drooool>

I really don't know what this means (semi-jesting), but since I see people I respect endorsing it, I might as well give it the goahead too.

You're back in SL and you didn't TELL ME?

This sounds good to me. Of course, you'd need a corresponding llGetLinkPrimitiveParams call, and the format for the returned values of multiple prims might be tricky to manage. Once again we need multi-dimensional arrays or at least lists of lists.

<stamp>

I would like to see this o.o
(drools as well.)

<bump>

freaky, I just posted a question about this in the scripting tips forum.

*signed* Yes please
Just found out my scoreboard was one of the laggiest scripts in my sim because of the presence of all the tiny llSetTexture scripts.

<signs>

I want this too. Although if given a choice I vote for llGetLinkParams and llSetLinkParams. Be nice to have all that functionality in one go. Also makes it easy to set a bunch of params all in one go and syncronyzed

This is an old thread. But I still wants it! *sign* *stamp*

Just think of how much easier this would make it to use XYText, and how many little "prim param relay" scripts we could get rid of...

*Bump*

Someone call the Lindens!

here here. I'm not sure why this is hard to implement, but I think when it came up the first time I saw it there was no concrete reason that the primparams scripts in the linked prims were bad. Inconvenient but not bad. Now, we've since learned that scripts even when not doing anything take sim resources, maybe not much and possibly more memory than processing time, but some. And none would definately be better than some .

this would be very useful. it might be laggy though to set new things for high prim objects so, knowing LSL, they'd probably give it a decent sleep script delay.

Is there a feature vote proposal for this yet? Not like it'd matter much but it seems the Lindens couldn't give a shit. This would be good for the new PRIM_FLEXIBLE parameter too...