llWhisper not being received

I am having a problem with a game I have developed.
To allow for multiple game boards being within the vicinity I have coded a prefix which is added to each of the discrete channels used for llWhisper communication between the various scripts. Each new board is setup with a discrete prefix number.
To ensure that each game board operates separately when it is first rezzed the parent prim sends a llWhisper on a common channel (not 0) which is being received by all the scripts in the child prims. There are many child prims with more than 1 script. One child prim does not seem to receive or act upon the message in the llWhisper, so the game fails to operate. This child prim has 3 scripts. The scripts all contain the exact same coding with regard to the updating of the Variable. On of these scripts, the largest, does not act upon the message when issued by the parent prim. Contrarily it does respond if the command is issued by my avatar.

Any thoughts as to why and what to do about it?

I know that one solution would be to use more than one channel for the issuing of the prefix message.
A second solution might be to avoid llWhisper and revert to llMessageLinked.

The problem is compunded by affecting (I think) the operation later during the game in that multiple llWhispers are being missed by this script.

Prims do not hear the llwhispers and the llsays and llshouts that they emit.

Use llMessageLinked.

Have you tried using llSay instead of whisper? Could it be that this prim is just out of range of the speaking prim to hear it?

I'm assuming this method is used to avoid the delayed response on each prim that llMessageLinked would have and to have the respond as close to the same time as possible.

There is no attempt to listen to llWhisper, llSay or llShout within the issuing prim. Thanks for the input.

You are correct in your assumption the use of llMessageLinked became impossible to use because of the delay and indeed because of the intensity of use some were even being dropped by the sim. All the prims in question are within a 2.5 metre diameter 0.5 metre thick prim. So I don't think the distance would affect the problem.

If an Avatar issuing the say to the channel is correctly heard why should it not be heard when issued from within a script in a prim?

I am still puzzled.

If llMessageLinked isn't working, then llWhisper will work even worse. llMessageLinked is far more efficient.

llMessageLinked does have a limit of 64 messages in a script's input queue. Work out a protocol to avoid that limit and it should be the best solution.

llMessageLinked works in broadcast mode too, so I don't understand the comment above about a delay for simultaneous actions.

llMessageLinked is far better than llWhisper for inter-prim communication. llWhisper should be reserved for inter-object communications.

I believe 'objects' (not just prims) cannot hear themselves talk... my opinion would be that, where possible, llMessageLinked is always the preferred method for an object to communicate internally.

You are correct.

I think the confusion here is Tiarn is thinking of llInstantMessage rather the llMessageLinked. There is a delay on instant messages of 2 seconds.

The queue of linked messages only stacks up to 64 when I was testing.. in case that's related.

On the contrary I can prove that they do.
The game board in question consists of 14 linked prims all ALL of which talk to one another!
The restriction is that Chat messages cannot be heard by the sending prrim. A good job too otherwise infinite loops might occur. Yes that was one of the limits I hit early on in the development cycle.At one point I had to send 121 linked messages at the same time and you can guess what happened. In avoiding that limit I changed to llWhisper messages now I have this problem. Sigh. I have solutions tho' for this one, as outlined above, and if there are no other answers I will adopt one of them. I was looking for expert opinions on the way to proceed.
Thanks anyway.

No, I am not.

Linked prims do not receive LINK_SET messages at the same time.

Actually, they *do* receive them at the same time, because the link_message event is queued for all of them at the same time. The issue is that they will not process at the same time because 1) there may be any number of other events ahead of them for each prim, and 2) script execution is time-shared / multitasking, so some scripts will get to run and process the event before others.

In actual practice, the time differential between the first script to process the link_message and the last one is still small (less than a second, for sure), unless the sim is lagging badly.

The real point is that llWhisper/llSay/llShout/llRegionSay suffers from the exact same issues as link messages, and is still slower.

As for the OP's problem, I haven't seen any issues with llWhisper not being received unless it is lost from a full queue (yes, you can still lose chat messages when the queue is full, just like with link messages). If it is a constant problem (ie, fails every time), I would check the listening script to make sure it is 1) within range, 2) listening on the right channel, 3) running, 4) not getting its event queue overflowed, and 5) doesn't have any other filters on the listen which would cause it not to process an otherwise valid listen event.

Your game will run much more efficiently if you can overcome the 64-message limitation for llMessageLinked(). Note that the messages can be much longer than llWhisper() messages.

Furthermore, you'll be assured that your game won't bump into a queue limit for llWhisper() -- one that might be a lot harder to measure and might vary depending on circumstances.

1 It is. 3 It is. 4 Can't tell, but wouldn't have thought so at the point of failure. 5 It doesn't.
I missed 2 since I have to double check.

I'll be back.

Well Talarus, I'm not gonna doubt you just because I know you seem to know a ton about the little workings in LSL...way more than I do. I can only say that from what I've seen in practice it's always suggested it differently, but it could be other factors that hurt my testing.

Some of my later creations have attachments with a fairly large amount of prims...last thing has like a 250 prim attachment car that I made the doors open as well as other things. I tested the doors with a single listener with a LINK_SET command that used integer as well as message variation to differentiate between the 2 doors. With the link messages, I'd see parts of the doors move well before others even though the movement scripts in each piece were identical other than the pos and rot they used. When I switched them all to just listen on their own for their own messages, they moved together very consistently...every so often I would see a delay in execution of a single prim, or a pause in the movement across all of them, but not the consistent variation I had seen on the door before where certain prims always moved before others.

I had tested more thoroughly on another object where I was just simply changing color....I didn't use SetLink just because of the enforced delay and the fact that it won't currently let you put a list of link #'s in the command. Basically it's a ship and you can almost always see the right nacel light up before the left one to varying degrees...but it is noticable. The further away their link #'s were, the more of a delay. That could be attributed if there is there is a cutoff for how many receive at once....doing the same thing on the car for the taillights- they are almost perfectly sync'd using listens but I did nothing to get their link #'s closer when I tried to do link messages.

As I said though, there could be other attributing factors, but this was all in the same sim and the results seemed fairly consistent, and as I said, the scripts were the same in the different prims

But there's no delayed response to link message. It's just normal queuing delays.

Might have more to do with how long you take to process listens and linked message listens in your listening prims. Perhaps you need to break it up into an analysis of what is required in your listen and then a flag and a timer to actually carry out the task. That way script execution will spread more evenly.

You could also put more info into each linked message with indications of which part is aimed at which prim. That way you would reduce the number of linked messages being queued.

The link numbers of each prim can change over time when you edit them and with the large number of prims you are using they are probably hard to track. Perhaps after edits each prim could report its link number/name and you can more directly target each linked prim.

Aye, we have similar issues with Daryth's Dragon avatars. When you use the HUD to change texture/color/etc, the prims don't all change at the same time. However, between the older generations, which used listens in every script, and the newer ones, which use a listen in the root prim, and link messages to all prims, there is no noticeable difference in the speed of change.

Just on a lark, I created a 250-prim test object and tried it both ways. There was no appreciable difference in the behavior. The prims randomly processed the events, and the updates randomly appeared. The one anomaly with link messages was that the root prim did not change until the rest had finished changing. Apparently, the llMessageLinked function does not return until all link_messages have been queued, which will vary depending on a number of factors, not the least of which is sim performance.

So, in a way, I was mistaken about the events all getting queued at once; they /should/ be, but perhaps due to the multitasking nature of the script VM scheduler, it may also time slice ll functions.