llMinEventDelay(float delay)

Sets the minimum amount of time, in seconds, between any event calls. Any delay 0.05 or less has no effect. As an example, it is useful if you would like to increase the amount of time between calls such as touch or collision, thereby decreasing load on server resources.

Q: Will setting llMinEventDelay affect events that have internal timers, such as llSetTimerEvent and llSensorRepeat? If so, how does it affect these events?
A: I did some testing and here's what I got with a freshly compiled script with llMinEventDelay(float delay). These were counted using the highly-scientific "one mississipi" method since I don't have a stopwatch.

• Touch events (touch, touch_start, touch_end): These will not trigger for the first delay seconds after compile. After a touch triggers, all further touches are ignored and lost until delay seconds have passed. Min delay between touch events is 0.1 seconds.
Additionally:
1. touch: After the initial post-compile delay a single touch event may be triggered every delay seconds. Clicking and holding does not create multiple events every delay seconds.
2. touch_start: After the initial post-compile delay a single touch event may be triggered every delay seconds.
3. touch_end: The first touch does not trigger, but after that first touch (which may occur during the initial post-compile delay) a single touch event may be triggered every delay seconds.

• Collision events (collision, collision_start, collision_end): These will not trigger for the first delay seconds after compile. After a collision triggers, all further collisions are ignored and lost until delay seconds have passed.
1. collision: After the initial post-compile delay a single collision event may be triggered every delay seconds. Maintaining collision creates multiple events every delay seconds.
2. collision_start: Seems to trigger erratically. As best as I can tell, after the initial post-compile delay a single collision event may be triggered. It appears that after the first collision, subsequent collisions before delay seconds have passed are ignored and lost and add to the delay before another collision event can trigger.
3. collision_end: After the initial post-compile delay a single collision event may be triggered every delay seconds. The collision events trigger delay seconds after the collision. Subsequent collisions before the collision event triggers seem to restart the delay cycle.

• Timer events (timer): These will not trigger for the first delay seconds after compile. After this, if delay is less than the period of the timer, the timer event will trigger normally. If delay is greater than the period of the timer, the timer will trigger every delay seconds, and will not stagger or trigger erratically even if the delay and the timer are not evenly divisible.
• Sensor events using llSensorRepeat (sensor): This appears to behave the same as the timer event.
• Control events: control event has a min delay of 0.05, and can be triggered twice if the llMinEventDelay is long enough to allow it in one delay period.

At this point my brain melted.

See script delay for more information.

Q: After doing all this testing I question the usefulness of this function in light of the apparent randomness of its effect. Would one of my betters like to comment on how it might be used?
A: It seems to me that for touch or collision events, it might still be useful. You're right though, it's pretty limited.

---

This article wasn't helpful for you? Maybe the related article at the LSL Portal is able to bring enlightenment.

---

functions | events | script delay