Reproduction: 1. Try to create a viable product in LSL 2. Observe that many silly walls are run into Script delays that are meant to prevent or slow down griefing and spamming do not work. Griefers, spammers, and honest developers alike can work around these problems by using the dispatcher-to-agents technique. Griefers and spammers don't care if they run into walls. They just try again and again and again. The honest developers and their customers are the ones who really suffer because of these limitations. Developers can work around these delays, but due to the delays, they cannot easily write a robust, reliable application that will always work. In addition, the use of "multithreading" in scripts causes more overall lag, due to the way that LSL is scheduled, and due to interscript communication overhead. These delays that are designed to lessen lag are actually causing more lag. Allow honest developers to write robust applications. Don't cripple your technology to fight griefing and spamming. 1. Remove all simple script delays from the LSL runtime. 2. Use throttles similar to HTTPRequest has, if you must, on functions that really need it only. 3. Consider which functions really don't need delay/throttles.

• but make sure we have a way to detect if we've been throttled

If detection of throttle is impossible then as a less desirable alternative cause the script to block when it is throttled (i.e. dynamic delay) This dynamic delay should only kick in after a threshold, it should be possible to make several zero-delay calls before encountering any with delays.