A question of timing ...

Don't laugh but ... how good would a timer be for say a tenth or even a twentieth of a second in passing a couple of messages via chat on an obscure negative channel?

I set up a timer to make two clicks feel more or less like a common-or-garden single-click. I'm testing it at the moment and it seems to work fine but it strikes me as a pretty clumsy way of tripping over a couple of states and I was wondering if I'm asking for trouble?

Should I just keep hammering away until I find a better solution?

Guess I should just keep hammering away then.

I don't think anyone understands what you're asking. Best I can guess is that you're trying to detect a double-click and make it act like a single click. Or trying to not allow super-fast touches.

If that's the case, then I can think of two options. Use llMinEventDelay(X) to limit the touch_start() event to only handle touches per X-seconds. If you only want to slow the touch_start() event, but not all the others... you can do something like this inside the touch_start() event:
if (llGetAndResetTime() > 1.0) doWhatever;

That's it. I use two 'say' functions - one on touch_start and another on touch_end. The solution works but I feel there must be a better way to do it.


Thanks for that DD. I didn't notice the llMinEventDelay() function before. I'll look into both options.

Just in case you're actually trying to simulate a double-click, two clicks within a short time-span.. here's a solution for that:

// Double-Click Method
float CLICK_RATE = 1.0;
integer doubleClick;

default {
touch_start(integer num) {
if (llGetTime() > CLICK_RATE) doubleClick = FALSE;
llResetTime();
}
touch_end(integer num) {
if (llGetTime() < CLICK_RATE) {
if (!doubleClick) doubleClick = TRUE;
else llSay(0, "Double-Click!";
}
else doubleClick = FALSE;
}
}

hold click can also be done

touch_start( integer vintTouches ){
  llResetTime();
}

touch_end( integer vintTouches ){
  if (llGetTime() > 1.0){
    //-- trigger
  }
}

as for ignoring double clicks, you can also cheat if llMinEventDelay is going to interfere with other event firings, and just drop a sleep into your touch event, which will prevent it from firing again before the code in the even has run (although it'll be queued one extra time, but it does cut down on frequency)

touch_start( integer vintTouches ){
  llSleep( 1.0 );
 //-- prevented from triggering more frequently than 1 second
}

another trick would be to change states on touch start to a state without it, which should dump any queued touches, then jump back when you're ready to handle touches again

default{
  touch_start( integer vintTouches ){
    state sCapture;
  }
}

state sCapture{
  state entry(){
    //-- do stuff
    state default;
  }
}

ps.
why yes, I AM alive.

Great to see you're back, Void!

Thanks for those ideas. I guess I need to do some thinking 'out of the box' but I have a notion the solution is somewhere on this page.

I really should browse the LSL functions more. First time I noticed llMinEventDelay was DoteDote's suggestion above.

thank you =)

yeah it's one of those functions that's kinda rare to be useful, but when it is, it REALLY is. it may suffer some of the same problems as the sleep delay trick (one additional queued event after the current running one).... I think the state change is the only safe way to actually dump them, although you can record a timestamp coupled with a key of the clicking agent and compare time periods, but I think that's going to work out to be slower and more code overall. although if you're logic requires you to remain in the same state I think that's the only other option for actually dumping the extraneous click(s).