I'm drawing a blank as to how to implement this with minimal impact on JME-provided code (that is, I think cut-and-paste coding is evil and don't want to cut-and-paste an entire action to add new behavior. 
I'm trying to add thruster sounds when my spaceship node turns. What I can't seem to figure out, however, is how to use the standard rotate right/left actions, which repeat, to determine when a key is pressed (and the thruster sounds should begin) or when the key is released. I've tried using isTriggerPressed(), but that's either not for keys or I'm not understanding how it works, because it doesn't seem to be true on first press and false upon release.
On one hand, I can see there being complications with a keyboard action requiring key repeat, as the held key is always being pressed. Yet, it seems like there should be some means of determining whether the key was initially pressed vs. being held, and perhaps some means of determining that the key was just released. Is this a bug, or am I missing some other method that would help? Or is there another way of implementing this that doesn't involve creating a whole new action that doesn't allow for key repeats?
Thanks.
don't have time to check any question related code, but no matter what the source is, you can always save the keystates from the last frame and compare…if a key was up the last frame and down now, it is pressed, if it was down last frame too it's being held down.
thewordnerd said:
it doesn't seem to be true on first press and false upon release.
It should be. And last time I checked that it worked (don't have the code at hand now). But I suppose it still works as I think many people are using it. Did you have a look at TestInputHandler?
Probably also have a look into the wiki on InputHandler mini-tut.
I have run into this same issue and have a bit more information. I decided to bump this rather than just make a new post, hope that's okay.
So anyways, I was getting this same issue and after reading this went to try out TestInputHandler, and that worked fine. So I tried changing my code to match it and it worked…
This is my code in the InputAction, it's the same as in TestInputHandler.
...
public void performAction(InputActionEvent evt) {
String actionString;
if ( !evt.getTriggerAllowsRepeats() ) {
actionString = evt.getTriggerPressed() ? "pressed" : "released";
} else {
actionString = "down";
}
...
This is the non-working code:
KeyBindingManager keyboard = KeyBindingManager.getKeyBindingManager();
keyboard.set( "flap", KeyInput.KEY_SPACE );
KeyInputAction flapping = new KeyboardFlap(bee);
addAction( flapping, "flap", false );
This was copied out of the FirstPersonHandler basically. When I run this code, the world "released" is constantly output, as if evt.getTriggerPressed is always false.
This is the working code:
KeyInputAction flapping = new KeyboardFlap(bee);
addAction( flapping, InputHandler.DEVICE_KEYBOARD, KeyInput.KEY_SPACE,
InputHandler.AXIS_NONE, false );
In this, pressed and released are output correctly.
So why is it that the way I had it originally doesn't work? Is this a bug?
Also, even with the new code, the InputAction is not being called when the key is held. Any help here?
The 'non-working' code is using action command (command is "flap") - and commands are not 'pressed'. Actually this command system is older than the trigger stuff, that's why it does not use it.
sclark3987 said:
Also, even with the new code, the InputAction is not being called when the key is held. Any help here?
That's because of the last parameter repeat which is set to false. If you specify true here the action is invoked each frame the key is down.
If I was to set the allowRepeat one though, there is no way of knowing when the key is released. (Other than doing it outside of the InputAction command)
… and if I have allowRepeat set to false, there is no way to handle a key being held each frame other than handling it outside of the InputAction…
In our code at work, I ended up giving up on using jme repeats (i think there was issues even with lwjgl being able to reliably tell you this information)… Instead I've written extensions of KeyInputAction and MouseInputAction and added them to the InputHandler with repeats set to false. I then keep a list of pressed keys that I scan on updates to determine if a repeat is occurring (I'm also using a repeat threshold and rate so I can control when and how often I send repeat events.) This is all code outside of the core jme (so no jme changes were required)
renanse said:
In our code at work, I ended up giving up on using jme repeats (i think there was issues even with lwjgl being able to reliably tell you this information)... Instead I've written extensions of KeyInputAction and MouseInputAction and added them to the InputHandler with repeats set to false. I then keep a list of pressed keys that I scan on updates to determine if a repeat is occurring (I'm also using a repeat threshold and rate so I can control when and how often I send repeat events.) This is all code outside of the core jme (so no jme changes were required)
If the code in JME doesnt work, why keep it in there.
Even better, why not implement a better solution to the core
I was writing a input handler for UI, so the needs I had are different. shrug
Not sure how the needs were different… Both of us needed to detect when a key was pressed, held, and released… yes?
…GameControls…
sclark3987 said:
Not sure how the needs were different... Both of us needed to detect when a key was pressed, held, and released... yes?
Actually, I only needed to know when it was pressed and released... Holding was something I wanted complete control over (for proper key repeat delays, etc.)
You can also check if a key is down yourself by simply asking if it is down.
Anyhow, I'm not saying it's perfect, but there are plenty of ways to get what you want accomplished.
Ah i see, I didn't understand what you meant before.
And yes, I have it working, I just am posting to see if there were better options, to alert you guys of a possible inconsistency in the codebase, and most of all, to add more information to this thread so the next poor soul who does a forum search will know why their code isn't working how they expect.