Help with Color Change Script

I'm not a scripter.

However, I made a color change script and put it in a pair of wings I was selling so that certain prims in them would change color on command. A customer very kindly informed me that she was having to use Reset Script upon first attaching/rezzing the wings (otherwise the prims wouldn't all change color at first), and made a suggestion for what I could do about it. (She also commented on the large number of listening objects I had, so I tried to work around that.)

Here is what I cobbled together, with some things snipped out for brevity. It seems to work for me, but so did my previous code. Could any of you smart scripter people look this over and tell me if it will elimate the need to use Reset Script, or if it will break when someone else takes possession of the wings?

Thanks!

integer x;

default
{
    on_rez(integer start_param )
    {
        llResetScript();
    }
    
    state_entry()
    {
        // This will listen on channel 90 for any chat spoken by the object owner:
        llListen(90,"",llGetOwner(),"");
    }
    
    listen(integer channel, string name, key id, string message)
    {
        
        //The following handle transparency and material:
        if (llToLower(message) == "glass")
        {
            for (x = 1; x < 22; x++)
            {
                llSetLinkAlpha(x, 0.5, ALL_SIDES);
            } 
        }

--Snip more of the same--

        if (llToLower(message) == "black")
        {
            for (x = 1; x < 22; x++)
            {
                llSetLinkColor(x, <0.0, 0.0, 0.0>, ALL_SIDES);
            } 
        }

--Snip more of the same, and ending brackets--

Yes, that system should work - each time the owner attaches the wings they're rezzing them, so there's a reset - however it will mean the custom settings are lost. The way around that is to check for the owner changing thus:

changed(integer change)
{
    if(change & CHANGED_OWNER) llResetScript();
}
CODE


and removing the on_rez event.

A little lower down you've got a loop that's sending the same colour data to all the parts of the wings through linked messages. The llSetLinkColour command will let you pass a LINK_SET parameter rather than the x parameter you've got, so, at least for the monotone wings you could do it one call rather than 22 calls in a loop. If you have varicoloured patterns you'd still have to do it with a loop, although if might be easier, depending on the patterns to hard code each one - maybe set them all to the predominant colour and then change the individual ones if that's appropriate to your needs.

Thanks.

So that bit of code would just go where the on_rez section is now? I'm assuming the script just needs to be reset once after the wings change hands? I'm a little confused, because I initially read my customer's comments as meaning that she'd had to reset the script every single time she rezzed the wings.

The loop is there because I don't want to change the color of all 90+ prims in the wings, just 21 of them. (My previous solution was to stick listen code into all 21, and then sell the wings bundled with nonscripted versions in case people were concerned about lag. I'm assuming what I've got now is a better way.)

Yes, that would replace the on_rez section now - it's probably the neatest way to reset the script on changing owners - although you do have other options such as removing and reestablishing listeners etc. but a reset is nice and neat.

And if you've got that many prims then yes, you've got a good option. For that large a subset it might work better to send a link message to the LINK_SET and have scripts in each of the prims you do want to change colour - responding to a link_message event rather than a listener but to be honest it's probably swings and roundabouts and in terms of updating the approach you've got is much simpler.

Yes, llMessageLinked() is much better because it won't affect any other wings near it...that means that George, who is standing next to Cindy, can make his wings blue while hers stay pink. Bleh