Delay in detecting rapidly-pressed inputs through llTakeControls

[Eric Stuart]

Been working on a project with LSL where an object sat on uses llTakeControls and recognizes inputs for the script.  I've noticed two things that I feel are generally going to be LSL issues with natural delays, but I didn't want to shrug them off in case it wasn't and there was a better method.  What I'm looking at is the following:

1) On rapidly pressing the same button, it often doesn't recognize numerous button presses if it's too fast.  However, if it is multiple button presses on different keys it seems to be able to recognize them almost perfectly and as fast as if you press a single button rapidly with numerous dropped inputs.
2) Trying to use an alternating input method (so left and up alternating rather than just up), it seems better but still may suffer from dropping inputs if it's too rapid.

Am I just at the mercy of the nature of LSL or is there a better way to guarantee every input is counted?  And would there be reason to believe that if it is just SL being SL, would the launch of LUA likely fix this?  Thanks!

[Quistess Alpha]

3 hours ago, Eric Stuart said:

1) On rapidly pressing the same button, it often doesn't recognize numerous button presses if it's too fast.  However, if it is multiple button presses on different keys it seems to be able to recognize them almost perfectly and as fast as if you press a single button rapidly with numerous dropped inputs.
2) Trying to use an alternating input method (so left and up alternating rather than just up), it seems better but still may suffer from dropping inputs if it's too rapid.

TL;DR that sounds like SL just being SL, but to go into a bit more detail, LSL 'control' events are are server side and only receive input of what you're pressing or not pressing every 1/45 of a second, so besides inherent network instability, there's a hard limit on how fast detected inputs can be.

I don't know your ultimate use-case, but the possibilities that come to my mind are either to use a different input mechanism (Instead of faster/slower, consider llDetectedTouchUV() for variable strength input on one or 2 axes) or it might be possible to use media (fancy name for webpage integration) to collect the input client side, and send aggregated information to LSL at a slower rate.

Quote

would the launch of LUA likely fix this?

Very unlikely.

Edited July 29 by Quistess Alpha

[Mr Amore]

When you're tapping a single key, on most keyboards it needs to lift high enough to reset before it will register another tap. Modern gaming keyboards are resolving these issues.

 

 

In your case the issue may not be within SL, you can test how well rapid taps are registering using another app.

[elleevelyn]

a conversation about the issue here

https://feedback.secondlife.com/bug-reports/p/directional-input-delays-with-latest-pbr-capable-viewers?