llMessageLinked() – what am I doing wrong?

I have an object or three linked prims (a root prim and two children). I want to send a message from the root to the children – not necessarily the other way around.

This is the script I put in the root prim:

//Transmitter – root prim
default
{

    state_entry()

   {

     Touch_start(integer total_number)

   {

      llMessageLinked(LINK_ALL_OTHERS, 666, "number of the beast”, NULL_KEY);

    }

}

This is the script I put in each of the children:

//Receiver –child prims

default

{

    state_entry()

   {

   }

    link_message(integer sender_num, integer num, string str, key id)
   {
    llWhisper(0,"Message received from link #" + (string)sender_num);
    llWhisper(0,"num=" + (string)num);//666
    llWhisper(0,"str=" + str);// "number of the beast"
    llWhisper(0,"id=" + id); //0 zero
   }
}

When I touch the root prim I expect the child prims to whisper their message but they don’t !!??

As you have it there, I am surprised the first script compiled - the brackets are nested to include one event inside another. You don't actually need a state_entry() at all in any case. Something like:

default
{
touch_start(integer n)
{
llMessageLinked(LINK_ALL_CHILDREN, 101, "Foo", NULL_KEY);
}
}

should work.

the LINK_ALL_OTHERS constant sends the message to the other scripts within the same prim. What you want to use is LINK_ALL_CHILDREN.... read closer...

http://rpgstats.com/wiki/index.php?title=LlMessageLinked

No, it sends the message to all prims *except* the one the script is in, hence other scripts in the same prim wouldn't receive the message.

LINK_THIS will send the message to all scripts in the same prim, including the sending script.

thanks for that - the bracketing was a typo on my behalf and yes it works now.

I'm going to ask a stupid question just to get it straight in my head. llMessageLinked() transmits a message - and link_message () receives the message so why is llMessageLinked() needed in the receiver when it is only receiving data? not transmitting it?

It shouldn't be.

link messages sometimes fail, it is better to put all child scripts in a single prim, then use a targeted link message like LINK_THIS or LINK_ROOT or # to send a single message which is interpreted for all the child scripts... and has not been known to fail TMK (but if it does, it should fail for all, which is better than the following scenario)

for large # of prims linked, LINK_ALL_OTHERS, LINK_ALL_CHILDREN, and LINK_SET, may fail to give the message to a random prim... and that can bork alot of things

I think I'll add that to the SL wiki if it's not there....

you can quickly grab the link # of a specific prim by dropping the follwing script in the root and touching the prim whose number you need (so you can target the child script)

default{
  touch_start( integer vIntTouches ){
	do{
	  --vIntTouches;
	  llOwnerSay( "Linked prim #" + (string)LlDetectedLinkNumber( vIntTouches ) + " was touched" );
	while (vIntTouches);
  }
}

Thanks

You've had this happen to you? And how many is a large number?

only 2 times that I personally noticed, neither reproducable, using ~40... it may be related to sim lag, I really couldn't trace it... it was during testing of what each link was recieving, so in my case llOwnerSay was passing each heard message along (I was testing someone elses product). it's even possible that it was llOwnerSay that wasn't firing, but I recall a few others having similar random experiences... I never bothered to report it because, well, I couldn't reproduce it reliably :hrug::

I suppose creating a maxed prim object, with link-listeners in each prim that increment a variable each time, running a huge test of sends, then having them all report totals, all done in the laggiest sim possible, MIGHT get reproducible results... but that sounds like work

I know I DIDN'T ever notice it in my ~20 child project, but that doesn't mean it didn't happen. I tell people if it bites them, or if it's crucial, they might want the above method

as a side benefit, 20 scripts in 1 prim are easier to update than 20 scripts in 20 prims and targeting isn't so hard if you use a few tricks like taking your target prim number from the script name like:
integer vIntTarget = (integer)llGetSubString( llGetScriptName(), -2, -1);
since copies get convenient numbers

I got caught by that one when I had foolishly designed a game which had 134 prims, some visible some not, to try to avoid the rez delay. I gave up on llMessageLinked as a bad job and switched to specific llWhispers put on different high numbered channels.

That has its own problems message queues limited to ~64 before being dropped so I had to adopt yet another way.

Thanks. This is good info to file away for later, if I ever run into it.