Consolidating llSetLinkColor

Hello Fellow Scripters!

I hope I can find some guidance in your infinite knowledge for my most recent project, a color change system.

Well, all I'm really looking for is a way to consolidate groups of similar commands in one script into a simpler and less lag-bearing format.

For example, I have chunks of my script using several llSetLinkColor commands back to back:

integer wing1 = 8;
integer wing2 = 9;

llSetLinkColor(wing1, (vector)message, 0);
llSetLinkColor(wing1, (vector)message, 1);
llSetLinkColor(wing1, (vector)message, 3);
llSetLinkColor(wing1, (vector)message, 4);
llSetLinkColor(wing1, (vector)message, 5);
llSetLinkColor(wing1, (vector)message, 6); //All sides except side 2

llSetLinkColor(wing2, (vector)message, 0);
llSetLinkColor(wing2, (vector)message, 1);
llSetLinkColor(wing2, (vector)message, 3);
llSetLinkColor(wing2, (vector)message, 4);
llSetLinkColor(wing2, (vector)message, 5);
llSetLinkColor(wing2, (vector)message, 6); //All sides except side 2


Is there anyone who knows a way I can tidy those blocks of commands up a little so they don't make such a lengthy script for my more complex builds?

Thanks,

Rena Kuhn

integer wing1 = 8;
integer wing2 = 9;

llSetLinkColor(wing1, (vector)message, ALL_SIDES);
llSetLinkColor(wing1, <1,1,1>, 2);

llSetLinkColor(wing2, (vector)message, ALL_SIDES);
llSetLinkColor(wing2, <1,1,1>, 2);

Sometimes it's faster to "change all" and then "change back" the ones you want to stay the same.

Hate to break it but sadly I already thought of that. :<

The whole reason I leave off side 2 is because it has another script recoloring it for this particualr build. I don't want them fighting over the color on that face.

Thanks for the tip though.

Can you put more than one PRIM_COLOR in a llSetPrimitiveParams, like this?

llSetPrimitiveParams( wing2, [ PRIM_COLOR, 0, (vector)message, 1.,
PRIM_COLOR, 1, (vector)message, 1.,
PRIM_COLOR, 3, (vector)message, 1.,
PRIM_COLOR, 4, (vector)message, 1.,
PRIM_COLOR, 5, (vector)message, 1.,
PRIM_COLOR, 6, (vector)message, 1.]);

There is no way to address a specific list of faces with LSL... Alas!

In your snippet, you use (vector)message as color, I guessed you use linked messages, so let your script "hear" the color for the face(s) you don't want to change --and store it in a global variable-- so you could use a single llSetLinkPrimitiveParams().

llSetLinkPrimitiveParams(wing1, [PRIM_COLOR, ALL_SIDES, (vector)message, 1.0, PRIM_COLOR, 2, StoredColor, 1.0]);

Just do not forget to initialize the global 'StoredColor' with something meaningful, or else send a linked message before any color change happens.

There is a race condition in that solution, so don't expect it to work ALL the time (though it may well work MOST of the time).

A race condition... LOL (I'm really amused to see such a technical term applied to LSL.)

In theory, yes, that's possible... But very unlikely because of the queued event... unless if some messages get dropped from SL pipes. I'm not even sure because that's a domain I have succeeded to avoid so far.

In my reply, I deleted a sentence before to submit. I was suggesting to merge the 2 scripts so that only one link_message() handler takes care of the color changes.

Since, Rena uses linked messages, it would be easy to use the integer to indicate if that's a global or single color change.

link_message(integer sender, integer num, string message, key id)
{
if (num == 1000)
{
StoredColor = (vector)message;
llSetLinkPrimitiveParams(wing1, [PRIM_COLOR, 2, StoredColor, 1.0]);
}
else if (num == 1001)
{
llSetLinkPrimitiveParams(wing1, [PRIM_COLOR, ALL_SIDES, (vector)message, 1.0, PRIM_COLOR, 2, StoredColor, 1.0]);
}
}

This way, there no race condition would be possible.

Yeah, that should work.

I often do a llSetLinkColor(); to all the prims for the basic change.
I then have the prims llSleep(0.1) //So there is no timing conflict for the double color change
And then do their local correction with llSetColor();

Oddly enough, you guys only assume that I used linked messages. I don't. The Vector message is a user input, so I can't change that. I only have the color vector on that message, and its staying that way. Also, I cannot merge the two scripts for the side 2 face either.

There seems to be no way to consolodate those like terms without making the script a patchjob at best.

I'll just continue the script as I have it.

Thanks for the help anyway though.

how about this script?
/54/f3/71810/1.html

I think most scripters know about that script... and it doesn't work for everything.

In this case, there's a point to vector(message), its so I'm not limiting my colors to a simple list of crappy hues... but letting the user define it instead.

Not everyone likes the same shades of grey.

unles your depending on this one color for some screwball realtime need to know NOW!! information its still faster to recolor all

and since you have a script in this "magic" prim just have it look for a change in color then recolor accordingly

its much faster to recolor the entire object THEN 1 prim than it is to recolor each prim in the object

give and take man, always in any language

1. What I do have hardly seems to change any slower than all-side changes.
2. I wanted to consolidate the script so I wasn't running similar commands over and over and over.

3. Topic is kinda old, so unless someone has something remarkable... the scripts are already implimented so I can't really change it now. Thanks for the help though.

actually, that script also listens for custom vectors, so they could have the option of the preloaded colors, or a custom one

dunno if you have it solved, yet, but you can also list the links and faces. here's an example script it sets face of links, 1,3,5,7,9,11,13,15,17,19, to red



of course you can also configure other lists to set a certain color on certain faces of certain links, and another color on another list of links/faces