Multiple Fast Clicking

Is there any way I could disable multiple clicking whether in Nifty or the actual application? In my app I want the user after clicking on a button not be able to click it again for like 0.5 sec or so.



Not sure wether to solve it from a GUI perspective or jme

Just ignore all input for 0.5 sec?

not sure how simple this is and please excuse my noobiness but my bytton code handling is:



[java] public void jump() throws{



character.jump();

}

[/java]



I want the jump method to be called every time the jump gui button is called. How can I ignore the input after the method has been called?



sorry if this is too simple

You tell me:

[java] public void jump() throws{

if(timer>0.5f){

character.jump();

timer=0;

}

}

timer+=tpf; //this should be in update

[/java]

1 Like

That wont work though for the first click, i’ll have to click multiple times to get it… i want the first click to get processed right away, but the second (fast) click to wait for the timer

@homsi said:
That wont work though for the first click, i'll have to click multiple times to get it... i want the first click to get processed right away, but the second (fast) click to wait for the timer

Do you really think thats that much more complicated so that I have to show it to you? Just let the timer start at 0.5 :roll:

I wouldn’t do it that way around @normen, just because then for each case where you are doing that you need to keep an incrementing timer.



Instead do:



[java]

ublic void jump() throws{

if(currentTime-lastTime>0.5f){

character.jump();

lastTime=currentTime;

}

}

currentTime+=tpf; //this should be in update



[/java]



Now you can have as many different counts/pauses/whatever running as you like and you only need to update the single currentTime value.

1 Like

(Oh my approach will also work for the first click too assuming it doesn’t happen in the first 0.5 seconds of the game starting).

1 Like
@zarch said:
I wouldn't do it that way around @normen, just because then for each case where you are doing that you need to keep an incrementing timer.

Instead do:

[java]
ublic void jump() throws{
if(currentTime-lastTime>0.5f){
character.jump();
lastTime=currentTime;
}
}
currentTime+=tpf; //this should be in update

[/java]

Now you can have as many different counts/pauses/whatever running as you like and you only need to update the single currentTime value.

Sure but you need to pass a global timer around. A Control can easily have its own timer variable and then needs nothing else.

@homsi


That wont work though for the first click, i’ll have to click multiple times to get it… i want the first click to get processed right away, but the second (fast) click to wait for the timer


that was only an example, just make initial timer = max time = 0.5f.

it will work like normen said in his first post.

trust me ;)

the best place to make it is control class for a button, if you have one.

and zarch, i know it is optimizing, but there are more important things to optimize ;)
anyway, every button should have it's own timer.

both methods work, thanks guys

I disagree. When there are two equally clean ways to do things (keep in mind you can still do the global timer per control if you want) then always choosing the more optimal one gives incremental benefits that add up over the course of a project.



If it made the code messy then I would agree with not doing it unless it is a problem but the code is just as good and the results are better.



As soon as (for example) on one control you start wanting a countdown for shooting, walking, jumping, etc then you immediately start using less code and running more efficiently if you do it the “store time” method instead of the “store counter” method.



You don’t even need a global timer. Use the System millisecond counter, compare lastTime vs System.getCurrentTimeMillis() and now you don’t need to increment anything at all. The only difference is your delays are expressed as milliseconds instead of floats… oh and all your lastTimes that start at 0 will also fire the first time they are run.

Yes, @zarch, it will make @homsis application much more efficient :roll: Who do you disagree to anyway? Me agreeing to you? @oxplay2 is right when he says caring for optimization too early is dangerous, especially when you are new like homsi. Nobody disagreed your solution is more flexible.

Also the milliseconds one is kinda dangerous, as it has different accuracy depending on the os.

I was disagreeing with the general sentiment that it isn’t worth doing just because there are other things that can be optimized. There are always other things that can be optimised - but that’s no reasons not to do this the best way you can.



This way around takes no more time to code, in fact it takes less as it uses less code, and performs better. There is no reason not to do it.



@empire_phoenix your objection is a straw man, in any case where varying precision of a millisecond timer could ever be an issue then an entirely different approach would be called for anyway since things like garbage collection pauses etc will be having far more effect on precision than anything else.

On x milliseconds is in 20 ms steps, that is far more noticeable than anything else, if not you produce so much garbage you should optimize your algorithms.



Not to mention that currentTimeINMillis can be a native call on the platform, leading to a context change, ect. SO it is quite possilbe slower than a singe global varaible you increment

Partly because I think it’s hilarious that this thread has gone on so long and partly because I want to join the bandwagon… :slight_smile:



[java]

private static long MIN_JUMP_TIME = 500 * 1000000; // 500 ms

private long lastJumpTime;



public void jump() {

long time = System.nanoTime();

if (time-lastJumpTime < MIN_JUMP_TIME)

return;

lastJumpTime = time;

character.jump();

}

[/java]



No separate counter required. Proper software engineering of the magic number constant. Use of nanoTime() for no good reason except there is no longer a reason not to.



I think this has now been over-engineered as much as reasonably possible. :slight_smile:

@zarch said:
I was disagreeing with the general sentiment that it isn't worth doing just because there are other things that can be optimized. There are always other things that can be optimised - but that's no reasons not to do this the best way you can.

This way around takes no more time to code, in fact it takes less as it uses less code, and performs better. There is no reason not to do it.

@empire_phoenix your objection is a straw man, in any case where varying precision of a millisecond timer could ever be an issue then an entirely different approach would be called for anyway since things like garbage collection pauses etc will be having far more effect on precision than anything else.

If myTime is not a double in your case you will run into accuracy issues after a while.. Depends on how long the debounce timer is.. In my case you reset the value each time so theres no such issues. I still argue its completely irrelevant and especially to homsi.