I added an optional boolean to isValidCommand… if you set it to false, it will not allow repetition which is nice for toggle type key commands.
That’s what I love about this project. You’re all such wonderful mindreaders!
I was just getting ready to post a question about how to deal with repetitious keyboard input for toggling commands!
[I’m implementing an IncreaseSpeedAction to change the movement speeds which multiplies the current speed by a value – the only problem was that when I tested it, the speed went to FLOAT_MAX due to repetition!]
-Mike
Can we add support for this in AbstractInputHandler?
I’m thinking something like this in update():
if (keyboard
.isValidCommand(((InputAction) actions.get(i)).getKey(), ((InputAction) actions.get(i)).allowRepeats())) {
And then define allowsRepeats() in all InputAction implementors.
I know it will break InputAction backward compatibility, but I don't see any other way to support it.
Since I'm going to try this anyway to fix my action, I can go ahead and generate a patch later today.
seems like we could maintain backwards compatibility if we say that allows repeats defaults to true in the actions.
Yes, but the interface has to be changed to provide the method, which meant that all of the InputAction implementors had to provide the method as well.
I set all of them to unconditionally true except for KeyScreenShotAction which I set to unconditionally false.
I left off the reason I wrote that previous post.
It’ll also mean any user code implementing InputAction will have to be updated as well.
Stupid interfaces… I was thinking it was an abstract.
Actually, why not switch it to being an abstract class? I don’t see any real reason for it to be an interface.
Also, don’t forget that multiple key presses are allowed in KeyBindingManager. See TestKeyBinding, there’s a SHIFT+I command.
I guess I will hold off on submitting a patch if you’re going to make it abstract.
I’ve tested my changes locally, and it works great!
It’s nice to finally “move around” on the terrain model at something greater than a snail’s pace 
Back later this afternoon.
-Mike
Speed has always been implemented. You are just thinking about it in the wrong place. Speed is defined in the actions not the inputs.
Right. Speed is defined in the actions.
But my action that changes the speed multiplier (x2 for +, /2 for -) had to wait for no-repeat support to be usable.
-Mike
updates done to InputAction… it’s now AbstractInputAction. All implementing classes have been changed to extend this now and most methods were moved into the abstract class.
Great!
Is there a reason why you made setKey final?
Seems pretty arbitrary.
-Mike
to track down the classes that were reimplementing those methods and yank em. just forgot to remove the keyword.