When changing between AppStates I wish to change the keys that are being listened for, for example in each AppState I create a String[] containing all the keys I want to listen for and then add them using inputManager.addListener(), I then on cleanup() use inputManager.removeListener() using the same String[], then in the new AppState I do the same, create a new array and etc etc…
My Questions;
1 - Do I need to bother removing the listener in the first place? Or should I sick with removing the unnecessary keys from the listener? (I think that this is best as then I won’t have useless bits of code being executed when the user presses a key I don’t want them to at that time)
2 - I don’t see that I can remove the Mappings in the InputManager is it the done thing to map all keys that you might use and then only listen for the relevant ones in the AppState? This could mean mapping the entire keyboard, is this a problem?
3 - In the FlyByCamera class the keys are controlled by onAnalogue() why is this? Aren’t key strokes digital? I could understand if there were the potential of a joystick input or something but (at least for FLYCAM_Rise/FLYCAM_Lower) there isn’t, can I assume that this is for easy migration to joystick applications? Because I also see this in HelloInput() where it is only looking at key inputs from the keyboard, also I assume that keystrokes will always get a value = 1?
Marginally confused about best practices atm lol.
Thanks
Neilos said:
When changing between AppStates I wish to change the keys that are being listened for, for example in each AppState I create a String[] containing all the keys I want to listen for and then add them using inputManager.addListener(), I then on cleanup() use inputManager.removeListener() using the same String[], then in the new AppState I do the same, create a new array and etc etc...
My Questions;
1 - Do I need to bother removing the listener in the first place? Or should I sick with removing the unnecessary keys from the listener? (I think that this is best as then I won't have useless bits of code being executed when the user presses a key I don't want them to at that time)
I personally believe that InputManager could probably do more to make this easier but I haven't thought of anything good enough to propose.
Anyway, if you want your app states to be nicely modular then yes, they should register for (most of) their keys when enabled and unregister them when disabled. I have some in Mythruna that also register a key on initialize but this is a special case. Each of the "tabs" in Mythruna is a separate AppState and the TabAppState makes sure that only one of them is enabled at a time. So the map tab registers "m" as a short cut for itself, the blueprint tab registers "b" and so on. I want these to always be active which is why I do it in initialize.
All of my other key bindings and listeners are setup on setEnabled(true) and removed again in setEnabled(false). Sort of. I have a special base class that calls enabled() and disabled() methods whenever the app state becomes "really enabled" or "effectively disabled". For example, a setEnabled(true) app state (to me) isn't enabled until it is attached and initialized. It's disabled() when it's unattached or setEnabled(false). That way I can make sure the "enabled" and "disabled" code always gets executed appropriately. I can probably provide this base class if anyone is interested... simplifies things a lot, to me.
Neilos said:
2 - I don't see that I can remove the Mappings in the InputManager is it the done thing to map all keys that you might use and then only listen for the relevant ones in the AppState? This could mean mapping the entire keyboard, is this a problem?
http://hub.jmonkeyengine.org/javadoc/com/jme3/input/InputManager.html#deleteMapping(java.lang.String)
Neilos said:
3 - In the FlyByCamera class the keys are controlled by onAnalogue() why is this? Aren't key strokes digital? I could understand if there were the potential of a joystick input or something but (at least for FLYCAM_Rise/FLYCAM_Lower) there isn't, can I assume that this is for easy migration to joystick applications? Because I also see this in HelloInput() where it is only looking at key inputs from the keyboard, also I assume that keystrokes will always get a value = 1?
Marginally confused about best practices atm lol.
Thanks
I think it's because that it wants to move the camera while the key is down. And yeah, I'm 99% sure the value is always 1. That's the way I treat it anyway.
Neilos said:
3 - In the FlyByCamera class the keys are controlled by onAnalogue() why is this? Aren't key strokes digital? I could understand if there were the potential of a joystick input or something but (at least for FLYCAM_Rise/FLYCAM_Lower) there isn't, can I assume that this is for easy migration to joystick applications?
This is more of a concept than real Analogue. It doesn't have anything to do (pretty much) with analogue/digital input from keyboard/mouse/joystick.
You use analogue when you want to continually process a keystroke for as long as it's pressed/unpressed whereas actions are things you want processed once and only once (either pressed or released).
For example. Take a space ship. To rotate the ship, do you want to constantly hit the "roll left" button very rapidly until you face the wanted direction, or would you prefer to press the key and hold it down? So if you used the key binding of that ship and move it to action instead of analogue, only the first keystroke would be processed.
That's the main idea behind analogue/action.
Oh and FYI, joysticks are compatible with jME3. :)
pspeed said:
Anyway, if you want your app states to be nicely modular then yes
I do so I think that this is the way forward.
pspeed said:
http://hub.jmonkeyengine.org/javadoc/com/jme3/input/InputManager.html#deleteMapping(java.lang.String)
I'm blind lol, I was looking for removeMapping, it is so easy to miss something that you are not expecting to see.
madjack said:
You use analogue when you want to continually process a keystroke for as long as it's pressed/unpressed whereas actions are things you want processed once and only once (either pressed or released).
That makes more sense to me now thanks.