llWhisper / listen() failing intermittently?

Just wondering if anyone has noticed this... I have a number of objects which communicate with other objects, that are always close by so I use llWhisper. For example, a rezzer will rez an object, and pass a chat channel to the rezzed object. The rezzed object, when activated, will llWhisper a message back to the first object on the passed chat channel,and then when its job is done it dies. The rezzer, having heard the message, rezzes a new object and the cycle continues.

However, intermittently, this cycle does not happen. As far as I can tell there are four points at which this can fail: 1) the llWhisper function is either intermittently failing, or is happening too late (lag?) or is working at much shorter range than 10m. 2) the listen() event might intermittently not actually hear what has been said. 3) the llRezObject function is somehow intermittently corrupting the integer it passes, so the rezzed object whispers its message on the wrong channel, or 4) the on_rez event in the rezzed object is sometimes receiving the wrong integer, causing it to whisper on the wrong channel.

I'm pretty sure that at least "something" is being passed from llRezObject to on_rez because the rezzed objects have an initialization routine that won't run if the on_rez event captures a 0 integer. So for the moment, I think that the problem is with either the whisper function, or the listen event.

I have had a few reports from customers of this problem affecting my products, and I have heard / seen a few times it has happened to other people's products which work in a similar way. Finally, I have witnessed the problem myself, once in a while.

Unfortunately I can't reproduce it, and I don't know what might be triggering it. I'm considering switching from Whisper to Say, or even Shout, which will eliminate the chance that the objects are getting out of range before the whisper has happened. The communications always take place on a large negative chat channel (which is randomized when the main object is first rezzed) so I am not worried about crosstalk between products.

Has anyone else heard of or experienced 'random' failures of inter-object listen-based communications? I think I first noticed this about 2 weeks ago... unfortunately I can't say for certain as it's one of those things that you don't really notice till after a pattern has started to appear.

-Atashi

If there is a lot of data flowing into your client then llRezObject will fail to pass the paramater. Happens a heck of a lot with my teleporter which rezzs an object you touch to tp. 75% or better rate of failure for the first couple of minutes I am logged in until the client and siimulator or in sync with each other.

You could set up a test by using llSetText to display the parameter and then it will still be there when the script dies.

I don't doubt for a moment what you're saying about a lot of data upon log in... and when TPing to a different sim, a lot of data starts flowing again when the TP is finished.

I am confused though as to how that is affecting the objects -- these are not attachments, they're objects that are rezzed in world at all times. In fact I have a similar application to what you mentioned - a teleport platform that rezzes a pad then whisper's coordinates to it. You can change the destination by operating the controls, it just whispers new coords to the existing pad.

So anyhow I'm trying to understand the relation between my logging in, and the whisper/listen failing? Is it because the objects are owned by me? there isn't anything in the scripting that is dependent on my being logged on or not... Is it because they're in the same sim I'm logging on to? If that's the case, then are they in trouble when anyone else logs on to the same sim?

Sorry if my questions are a bit basic, I'm just confused.

-Atashi

llWhisper() Range is 3m radius from the center of the object; not 10. Use llSay() if you need a range up to 20m. Use llShout() for range up to 100m. Use llRegionSay() for sim wide communication.

I think this is documented in the wiki.

llWhisper() range is a 10m radius sphere, this will be from the centre of the object/prim speaking.

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

I use this extensively in various products in a similar way to your rez, pass channel, respond system and have not once experienced a problem with either the whisper function, the listen event, or parameter passing of the channel, I have not noticed any difference recently and have been using and testing these setups on an almost daily basis. I have had delayed reponses in my objects communications due to lag, but nothing has been lost or failed to trigger in a random way...sometimes when I got my code or logic wrong though

As I think you know, llRezObject has a built in script delay after rezzing an object, depending on your setup, is it possible your rezzed object is communicating too quickly with the rezzing object, sending a message whilst that script is sleeping? (I am not sure if scripts that are sleeping miss all communications with them, or if they get queued to be dealt with when they start running again.) If this is a possibility, perhaps delay the rezzed objects response for a short while to allow the rezzing object to have its script active to receive the message?

If you cannot replicate this when you are there, I would set up an experiment with your devices also whispering debug messages that a seperate device listens to and stores for you to access when you are available. For example, a counter for each instance of rez with various data associated with it, such as the integer received by the rezzed object in on_rez(), the fact that the rezzed object replied and on what channel, and that the rezzer received etc.

It would be interesting to see how you get on with it. Best of luck

It varies, see the end of http://rpgstats.com/wiki/index.php?title=ScriptDelay

Listens have a particularly goofy implementation, and events are not queued when chat actually happens. Instead, the listen keeps track of its position in the sim's chat buffer, and will resume scanning from that point whenever it wakes up. This happens even if you uncheck the running box, chat, and then turn it back on. A side-effect of this is that multiple listens can be triggered in the order you set them up, instead of the order the chat actually occurred. Also, the name parameter of the listen() event is determined when the script notices the chat, not when the message is said. So a script that sends a message and then quickly changes the object name or deletes it may not be received with the correct name.