Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

How to flush the message/event queue, to keep the data source as current as possible?

Scalar Tardis
SL Scientist/Engineer
Join date: 5 Nov 2005
Posts: 249
06-20-2007 04:15
I am trying to build a sort of volt-meter display device to show real-time data from a fast-changing data source.

The problem with simply passing messages and updating the meter needle position or moving the texture to simulate a gauge..... is that moving or texture sliding imposes a 0.20 second delay or more on the script.

Meanwhile messages can continue to stream into the input queue of the script at a speed of 0.050 to 0.100 seconds, or 2 to 4 times faster than the data can actually be displayed.

Over time the event buffer fills up with a backlog of data messages for the meter, but the meter is now lagging so far behind the data source that the meter readout is essentially useless and wildly inaccurate.


I am trying to find a way to flush messages out of the event buffer to help the buffer catch up when the script has been delayed. It is far more important to discard the flood of messages and only show the most recent data, than it is to slowly show all the backlogged data in the queue.

Does anyone know if a way already exists to deal with these Linden-imposed script delays?


Currently I am looking at somehow using a time command like llSetAndResetTime() and llMessageLinked() to pass a timestamp along with the data. The display-meter gets its own local timestamp, and compares it with the recieved stamp. If the time difference between the meter and the data source greater than, say, 0.20 seconds, the event loop immediately ends to discard the data.

It will keep on pulling data out of the event buffer and discard the data, until the local time is within 0.20 seconds of the data source. THEN it updates the meter display with the data. If the update has bogged the script to beyond 0.20 seconds of delay, it again throws away a few messages to keep up with the data source.

-Scalar Tardis
Squirrel Wood
Nuteater. Beware!
Join date: 14 Jun 2006
Posts: 471
06-20-2007 04:55
Use one script to handle the data and multiple slave scripts to carry out the modifications. that way the main script won't get delayed and if you rotate the slave scripts you may be able to process all messages.
Resolver Bouchard
Registered User
Join date: 19 Jul 2006
Posts: 89
06-20-2007 07:45
Maybe try switching states after you have updated the display, I think this clears the event queue.