Timer Event Documentation

This was pulled directly from a PR to the legacy LBA repo

This resolves the comments made in PR#25.

Per the unsubstantiated comments in the prior PR, GLBA is not bare-bones, fast, or responsive.

I, however, submit this substantiation for why this is incorrect:

I modified LBA slim by deferring updates that use costly functions such as llSetPrimitiveParamsFast by using timer events.

Per @ThunderRahja's comment,

I disagree. Adding more events will actually reduce script responsiveness in a busy sim, due to how the event scheduler delays firing events when under strain. Timer is even worse because it can stack up in the queue I have reviewed all of the lines you changed or added and think they are not a good fit for LBA slim. You are, of course, welcome to share your own modifications of LBA, but I do not think this is an acceptable replacement.

This is false. Updating primitive properties in every frame is FAR more costly. Simply using a timer instead of doing more work every frame does not "reduce script responsiveness" in a busy or idle sim. Timer events also do not stack up. If you can provide proof of "stacking", please do.

All event execution (and for that matter, every single instruction within the events) happens during a frame. If event execution takes longer than what the scheduler has allocated, the execution state of the script (the stack) is serialized, being deserialized and resuming during the next frame the script is scheduled. So, with a costly instruction, such as llSetLinkPrimitiveParamsFast, while having less resource needs than llSetLinkPrimitiveParmas, may not finish executing during a frame.

Setting prim text is not something that needs to happen every frame. Per your own comment, the timer event gets delayed when there is resource exhaustion. Good. The sim can defer that event until it is less busy. The collision events (and listen events) still continue to process each frame it is scheduled. If the LBA health goes below zero, it will submit llDie just at the same time LBA-Slim would.

For these reasons, "adding more events will actually reduce script responsiveness" is incorrect. The only impact will be that the text above the object will not update until 0.15s (or so) later. Best practices in UX design will tell you that 200ms is a good target for "responsiveness." 150ms is below that.

I chose 0.15s as the timer because that is an update roughly every 7 frames (if there have been any actual hits). If your issue is with my choice of every 7 frames, please offer a different option.