I’m wanting to setup my game so that when someone pushes a movement key, the camera updates also, is it possible to have more than one action occur, such as strafeLeft and updateCamera? The way jme is structured this seems to be the way something like that should be handled, but the reality seems to be, I have to write my handlers so that they do the movement and then update the camera directly, which when using the various KeyNodeAction classes means a lot of new classes so that a minor change can be made. If multiple actions are allowed to occur on a single key press, the KeyAction/KeyNodeAction stuff would be a lot more flexible/pluggable. As always I assume I’ve overlooked the obvious so feel free to smack me upside the head and point out the obvious thing I overlooked.
Have you tried setting more than one action to a key?
KeyBindingManager keyboard = KeyBindingManager.getKeyBindingManager();
I'm not sure if this will work as I've never tested it but it seems plausible.
(Where StrageLeft and UpdateCamera are your InputActions)
This overwrites the first action and only performs the second action. It’s easy to have multiple keys do the same command, but it seems difficult to make a single key perform multiple commands while using the action classes, without overriding them. I will likely scrap the action stuff and use keyboard based on the example in the start.pdf file.
Generally I write my handlers to bind actions to the keys and then the handler itself refreshes the camera on update calls based on the state of world objects it is tracking (eg, a node it is tracking, walls it wants to not hit, etc.) Thus the actions worry only about changing world data and the camera itself is intelligent. Not sure if you can make use of the same method though. As for the main point of your thread though, definitely something to think about.
If the plan is to eventually have something that’s somewhat like a pluggable game (game studio or there are a few others) it seems like that’d be something to shoot for, since a few defined actions could be combined to create a fair number of more complicated actions… of course, though possibly instead of an interface setup (requiring a class per action) it might make some sense to simply make a class full of various common movement type methods, called via KeyBindingManager (which is essentually what I intend to do… and I even plan to rape a few of the Action source files to avoid having to look up the math for movement hehe). I’m not in a position to really consider the overall benifits of any particular approach for the JME api, probably some damn fine reasons for why things are the way they are that I haven’t considered.