no order in linked messages

I'm looking to have it so that it doesn't matter what order the links are, on my machine... As in my parent script can interact with all the child scripts without actually having to know the number... i.e. just send it to all the scripts, and the right one responds.

I don't want to do a for loop.
What would be a smart way of doing this?

Parent:

llMessageLinked(LINK_SET,1,"message text","random key");
llMessageLinked(LINK_SET,2,"message text","random key");
llMessageLinked(LINK_SET,3,"message text","random key");

Sample Child:

link_message(integer sender, integer num, string str, key id)
{
         if(num == 1) llSay(0,str);
}

The downside of this is both that you're broadcasting the message (laggier) as you're triggering events in every script in the object itself... which is pretty much unnecessary. You could also store a list of which link your children are on, via llGetLinkNumber, for your parent to send messages over without broadcasting, but I leave that to you to write.

use LINK_ALL_CHILDRENS
or LINK_ALL_OTHERS maybe, this will spare you to have the script broadcasting in the same prim and thus saving the message to be broadcasted in the same prim the script is (if you have multiple scripts here for example)

If you don't mind getting a little involved, you could have an initial broadcast to all children from the root requesting an ID callback from all the children prims/scripts.

Each child would respond with 'I am <script> in <prim#>' and the master script would then parse that and store that info in global vars designated for each child.

After that, all calls to children could be targeted to specific prims with llMessageLink(<variable for specific target prim>, <number>, <string>, <key>;

This would make coms a bit more efficient overall but I dunno how complex you want to make your scripting.

If you are willing to enforce a specific link oder when you build the object, you can assign specific IDs to each child and avoid the necessity for the initial broadcast and parsing of responses as well.

Racer P.

Eek!

Whatever happened to good old fashioned llGetLinkNumber()

--Jack Lambert