llMessageLinked and Efficiency

Hi. I'm just starting to make a more serious effort at understanding scripting. I make jewelry, and what I'm trying to put together is a texture changing script that will, when the linked object is touched, change the textures of all the "gemstones" in the item. So someone could, for instance, go from having a diamond necklace to a ruby necklace at a touch.

Here's the thing: I'm not sure if it's more efficient to use LINK_ALL_CHILDREN in llMessageLinked, and only put the receiving code in the gem prims, or to set up a loop for the link numbers and only have llMessageLinked go to the gem prims. My jewelry tends to be quite prim-heavy (my average is probably 180), with a fair chunk of those (20%-40%, I venture) being gems.

Efficiency aside, I'm leaning towards the specific link numbers because, though I plan on setting the scripts no modify/no copy, the jewelry itself is copy/modify, and the script sets textures based on UUIDs. Specific link numbers would cut down on people moving the scripts to other objects and suddenly having a lot of texture changing jewelry.

Hmm - I'm not really sure about the permissions system but if a script inside of an item is no mod/ no copy the person shouldn't be able to copy the item he or she purchased so only the original item would have the script and unless you sell them at a bargain price taking the script out and putting it somewhere else is not financially attractive, since for every item the copycat would sell he'd have to buy one of your originals.

In addition to that I'd prefer using a kind of password system between the root prim and the child prims. This way the link number wouldn't even matter - you just send an encoded message to the child and the child decodes it and - if it matches a certain pattern - changes colour.

Even with a basic encryption routine it would probably put most of the copycats at bay - even if they instaleld a listener and dumped the received message in the chat window they'd still have to try to decode it.

This would - I think - eliminate the need for adressing individual links and would probably save yourself a lot of trouble in the long term should you decide to add something to an item and then having to recode it because of no longer matching link-numbers.

I don't think this is the case. I have an AO I bought that's copy/mod/no transfer, and one of the poses inside is no copy/no mod/transfer. I can rez as many copies of the AO as I want, and they all have the no copy pose inside them. What I can't do is pull multiple copies of the pose out of a single rezzed AO.

Actually, now that I think about it, that setup has quite the potential for abuse.


I'm not sure how this would work? Anyone taking the scripts would have to take both the sender and receiver scripts. If the encryption is decoded by the receiver script, there isn't much point in this.

Ah .... think meaner

There is such a nice function that is called llGetCreator and such a key WOULD indeed be a nice component for an encryption algorithm. So - if one either decodes or encodes statically with YOUR key and the other does the opposite direction with the dynamically acquired key via llGetCreator ..... much luck by just dragging the scripts into new prims.

Edit: Well - rethinking it - just using llGetCreator would probably solve the problem as well without need for further encryption?! If script and object creator do not match - it's a rip off and the script shouldn't work.

Be careful. If the pose were no copy, you should not be able to copy AO with that pose. If you made the pose by yourself, it would be very different situation.
Your jewelry will turn to be unable to copy for buyers.

[EDIT]hmm... Did you mention that the pose had alredy been inside it and it was no copy? It might be the trick that no rez objects' permission is lost.
Try to rez the AO on the ground once and take it. Then make sure that permission.
Aha, you might like to do so. It is good. Forget it.

And speaking of the original question, LINK_ALL_CHILDREN or even LINK_SET is good. Don't use specific link numbers and loop because you have to send llMessageLink as much times as the number of your prims. Recieving stress is the same with LINK_ALL_CHILDREN but sending stress becomes so heavy.

This might work. Have not tested it though.
It gets the key of the script creator and compares it to the creator of the object. If they match than the MessageLinked call is allowed.

// root script

integer lchange_textue = 10000;
key script_creator_id;


default
{

    state_entry()
        {
        script_creator_id = llGetInventoryCreator("name_of_this_script");
        }

    touch_start(integer num_detected)
        {
         if (script_creator_id == llGetCreator())
            {
             llMessageLinked(LINK_SET, lchange_texture, "", NULL_KEY)  ;
            // change the texture here
            }
        }
}

// receiver script

integer lchange_textue = 10000;

default
{
    link_message(integer sender_num, integer command, string str, key id)
        {
        if(command == lchange_texture)
             {
              // change the texture
             }
        }
}

* shameless plug * i kind of made such texture changing script. menu driven and all. It's for sale on slEx. Part of protection is, the texture changing bits are performing check on both start and texture change command and refuse to work with prims that aren't already textured with one of 'valid' textures (list of which is stored in compiled scripts themselves) ... so placing them in someone else's objects generally doesn't work.

re: the original question, i found LINK_SET efficient enough for the task (using this one rather than LINK_ALL_CHILDREN to cover situations where the root prim holds the menu script but also undergoes texture changes itself)