I have a question. In my game I’m moving around with the keyboard and when I go into a building. I register that appstate to start listening to keys.
Problem is if it is closed! It just puts up a “we are closed” and press any key to to leave. So to move around, I"M holding down the “W” key to move forward. When the appstate runs there are many “W” keys in the buffer and when it register to listen, it grabs those keys.
Is there away to clear that when they appstate starts?
Is that going to solve the problem?
If the player is holding the W key and thats producing continuous Ws then even if you clear them out the player is still going to be holding W.
Don’t you want your logic to be that the held state has changed (from unpressed to pressed) not that a key is pressed
Yeah, I don’t remember any buffering anywhere. But if the ‘w’ is still being pressed then maybe it’s possible that key events continue to come through until released.
No simple way to handle that, I think… could watch for down events and ignore any key event that you haven’t seen a down event for or something.
What happens is they are holding the key down moving, and before the player knows it, it is loading the screen and displaying it. During this time inputs come in.
I changed the appstate to not start listening to inputs until the screen displays, and then it listens to the input. This all happens with in a 1 second at the most and player doesn’t react fast enough to release the input.
Thanks for your ideas.
Down event comes.
Player walks into whatever.
No up event.
Something in the infrastructure starts pumping “typing” events.
Should still have been no up event or further down events.
I can’t speak for your listeners on the child app state or how they are listening… but one way would be to ignore all events for a key until you see a down event.
If you don’t see a down event then the key is still pressed from before.
There are really only two kinds of events: pressed and released. Everything else is “made up”… either by the OS or the library (probably glfw in this case but it’s just a guess).
Glfw does fire pressed events in case of long presses.
Even listening for key down events make the app snappier i find waiting for a down-up sequenze more userfriendly.
You mean you get more than one “press” per press? If so, that’s completely brain dead.
Glfw fires: down → pressed → up events. (Pressed only in case you hold the key down)
Tbh i habe not checked how jme handles it.
And the pressed event gets fired on each update
//Add: reading the code. Jme should fire input events more then once in case of long presses.
Pressed is set to false but repeating to true. So if you check for keyup with !presses only you should get false positives
Ok, so just a terminology misunderstanding.
down and up are the real events from the physical keyboard. ‘pressed’ is the made up event for when things want ‘typing’ style input.