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