Link Message overhead?

Let's say you have a large linkset (~200 prims), and 6 prims in it need to receive certain link messages from a switch, like a window controller or light switch. I have always just sent unique messages to the entire LINK_SET. But today I'm wondering: is there any overhead incurred in sending the message to the entire linkset, if the other 194 prims do not have link_message event handlers?

The alternative to broadcasting the messages in this case would be for there to be an "init" phase where prims needing to get these messages would register with the prim producing them. Seems like a lot of useless code if LSL is smart enough to not enqueue messages for nonexistent handlers.

it probably uses less resources to send a message to all the links than it would be to try to find out which links to send them to, and then send them. you would have to run them through a loop and send each one individually, thus sending more messages. now, if all the prims in the link set had a link_message event, but only certain ones needed to respond to certain commands, they would all still be triggered and would need to filter out. i wish we could feed the link-number field with a list of integers. but even for llSetLink* functions, you have to use separate calls for each link number if you're not going to do link set

if you do LINK_ALL_CHILDREN, at least you skip the root prim :X

The cost of LINK_SET etc. is very low if there are no /scripts/ in most of the prims, however if all your prims have scripts in them, then even if they don't have link_message handlers it will incur a cost.

In such a large linked-set though I'd say you probably want to use single link-messages as appropriate. The cost of this though is complexity.

To do it you'll need a root script that tracks the location of the other scripts. These scripts will then report their link-number whenever they detect that the linked-set has changed somehow (test the changed() event for CHANGED_INVENTORY, and look to see if the result of llGetNumberOfPrims() has changed), and also in their state_entry() event. Likewise you'll also want an additional link_message() ID that allows the root-prim to request an update, in case the root-script is ever reset.

In this case, you'll have a rare LINK_SET/LINK_ALL_OTHERS message if the root-script wants an update, and after that only directed link-messages.

The issue is that when you do a LINK_SET or whatever message, that the simulator has to check each relevant prim for a script, then each script for a link-message handler, not the most efficient unfortunately.

you could also have unique names or descriptions for the child prims, run a loop thru the links checking the names or descriptions, if it's what you're looking for, add the link number to the list

list prims;

integer = llGetNumberOfPrims();
for(i; i >= 0, --i)
{
string name = llGetLinkName(i);
key id = llGetLinkKey(i);
list dets = llGetObjectDetails(id,OBJECT_DESC);
string desc = llList2String(dets,0);
if(name == "msgme" || desc == "msgme"//checks if the name or the description matches the keyword
{
prims += i;
}
}

and of course you can have separate lists of links for separate functions

Thanks, Haravikk and Ruthven!This is what I was afraid of. There are 15-20 other scripted prims in the build, which is over 200 prims. If it were my build, I'd put my stuff in a separate linkset and stuff it all into a rezbox and be done, but this is a prefab I'm modifying for a friend and he's used to having it be one linked object.

Hmm. Looks like I'll be doing some sort of registration scheme - I was thinking along the lines of a poll/response thing like what you suggest, Haravikk, but the naming convention idea is sooooo simple Ruthven (I hadn't considered renaming the prims, but I bet they're all named Object anyway!).

Anyway, thanks much, I'll chew on it!

actually the naming method was hewee zetkin's idea i think, at least that's who i saw it posted from a while back

Here was how I worked it in a large attachment:

list myListCloak;
list myListHarness;
integer i;

myFunctionInitTables()
{
    i = llGetNumberOfPrims(); // how many prims are in set
    myListCloaks = []; // since lists are persistent across runs the only 
    myListHarness = [];  // thing that can clear them is script reset or null value
    for (; i >= 1; --i)      // countdown through all the prims in linkset including root
    {
        if(llToLower(llGetLinkName(i)) == "cloak")
        {
            myListCloak += i;
        }
        else
        {
            myListHarness += i;
        }
    }
}

default
{
    state_entry()
    {
        myFunctionInitTables();
    }
    
    changed(integer change)
    {
        if (change & CHANGED_LINK)
        {
            myFunctionInitTables();
        }
    }
}

The default state will trigger a rescan of the prims in the link set on state_entry or if any prims are linked or delinked

Just curious.. Do we know this is really the way the sim works? I don't think I've ever seen a Linden say this, though that doesn't, by any means, mean it isn't true anyway..