avoid listen() event queue?

Hey, I noticed that listen() builds up a queue of incoming messages. I'm wearing a HUD that is transmitting my current position to another prim via llShout(). I noticed the other prim wasn't keeping up with my movements. I experimented some more and found its queuing up the messages.

Is there an easy way to limit the number of messages is queues, or perhaps another method to get around this problem?

llShout() has a radius of 100m while a sensor has a radius of 96m.

Is there any reason why you're not just firing a sensor in the other prim at regular intervals to keep track of your position?

Kitty makes a good point. Especially if you don't use a fast sensor repeat. Be nice to the server. =)

Alternately, you could increase the llSleep(X) delays between shouts.

Alternately, if you wanted to be really nutty about it, you could keep speed-spamming the listener but give the listener an llMinEventDelay(X) and have it discard extra shouts.

The solution to this problem is actually pretty simple, though it comes with a couple of caveats.

listen(integer channel, string name, key id, string message){
//do your code here

llResetScript();
}

This solution works for my particular situation. The HUD transmits my position every time I move. I use llShout because the remote prim could be anywhere within 100m radius. The prim receives the most recent vector, then does its code.

So in this limited situation, calling llResetScript() repeatedly has less overhead than letting vector positions queue up. Once I implemented this, the delay I was experiencing dropped dramatically, and my prim is now able to track me in real time.

A much more elegant solution would be if we had a method to clear the listen() queue. In fact, a great little function would be

 llClearEventQueue(string event_name); 

You could specify the name of whatever event you are interested in and have the script immediately clear whatever was queued in it.

You're still unnecessarily stressing the sim this way.

If you don't want to use the sensor for some reason, the other solution is to limit the rate at which you're sending out updates so that the prim can keep up. If you're sending out updates, only to discard them at the destination because you don't need them, you're wasting resources.

You can limit the rate by either sending updates in a timer() event, or change to a polling model where the other prim "shouts" whenever it's ready to process another update.