I understand the basics of it for use with the keyboard and mouse but i know you can use it for a lot more than that, but i have some questions.
The input system works a lot like event+eventlistener(if this connection isn't clear please tell) but instead of executing the event response when the event is dispatched the input system executes the response during the inputhandler's update cycle. 1.) I what is advantage of that? 2.) Why didn't jme use the mouse listener architecture like java swing uses?
in the case of the mouse the device schedules the mouse actions for execution by activating the trigger. 3.) Why are they processed later instead of the instant the code decided to process it?
key actions are reprocessed every frame. 4.) Why is checking them every frame needed?
- Events can dispatched in different thread without having the listeners to care about re-queueing the events or something.
- Because in 3D games you have quite different needs than for a swing gui. You do not listen to components. You don't want much garbage. You need other information on the events. You probably want to act each frame while some key is down. etc.
- see 1 ?
- It's not needed to check it every frame anymore. It was the 'old' way of handling input. It's still there for backward compatibility and because no dev rewrote the key-combinations part of it.
jme has a mouselistener class and a keyinputlistener class.
im using them right now 
irrisor said:
1) Events can dispatched in different thread without having the listeners to care about re-queueing the events or something.
what if i synchronize all the listener methods. so u cant trigger two events at the same time. the earlier event is always processed first in real time order.
i think this is enough for an rpg game right?
I'm not sure what your first question (if it's a questions) aims at.
re rpg: sure, why shouldn't it. Should be fine for an fps also…
irrisor said:
I'm not sure what your first question (if it's a questions) aims at.
sry i was trying to ask if i was correct about making the listeners synchronized would solve the queue problem? :D
what if you have a second or third input handler, would this break your synchronized pattern…
neakor said:
sry i was trying to ask if i was correct about making the listeners synchronized would solve the queue problem? :D
When you say that the listeners are synchronized you mean that the render/update thread and the listeners are using the same lock object to access and modify data? If so, then that is true.
PS Congrats on you 100th post: Full Member! :D
duenez said:
neakor said:
sry i was trying to ask if i was correct about making the listeners synchronized would solve the queue problem? :D
When you say that the listeners are synchronized you mean that the render/update thread and the listeners are using the same lock object to access and modify data? If so, then that is true.
PS Congrats on you 100th post: Full Member!
Snippet taken from ActionTrigger
protected ActionTrigger( InputHandler inputHandler, String triggerName, InputActionInterface action, boolean allowRepeats ) {
this.inputHandler = inputHandler;
this.action = action;
this.allowRepeats = allowRepeats;
this.name = triggerName;
synchronized ( this ) {
if ( inputHandler.allTriggers == null ) {
inputHandler.allTriggers = new ArrayList<ActionTrigger>();
}
inputHandler.allTriggers.add( this );
}
}
should the synchronized block be around inputHandler and not this
Try using GameControlManager and you'll get away from all these troubles. 
What do you expect from synchronizing anything? Usually it's not needed, as you call the update method of InputHandler in a thread of your choice. Why would you want to synchronize listeners with a common lock then?
I think the main intention was to be able to update any game state (geometric, render, etc) from a thread that is completely independent to the render GL thread. In order for this to work, you either need to lock the scene (as in StandardGame) before modifying anything, or submitting the change in a queue to be executed in the future. If I understand correctly, Neakor was just asking if he could do the synchronization himself from some input handler (and I presume, not using the lock in StandardGame).
Am I right or totally off? :?
thats what i was talking about. but yes, i do have everything in a queue which gets excuted to modify anything.
so i think its not necessary to make anything synchronized?
You should try to avoid synchronization where possible as it slows your application down, but sometimes it is necessary.
Don't over architect…if you are developing and it starts breaking, take a look at it then and determine if synchronization is necessary.
darkfrog said:
You should try to avoid synchronization where possible as it slows your application down, but sometimes it is necessary.
Don't over architect...if you are developing and it starts breaking, take a look at it then and determine if synchronization is necessary.
thx for the advise, ill keep it in mind~ :D
oh god im learning so much~ :-o
You should try to avoid learning where possible as it slows your brain down, but sometimes it is necessary.
Don't over think…if you are thinking and you start learning, take your head and hit it with something heavy and blunt, then and determine if learning is necessary.
I have a listener system setup on top of the MouseInput, and KeyBindingManager.
It works a treat.
I have also extended node to a button type that has its own listeners.
I am doing allot of user interface development, until I did this I had a mess.
Patmania said:
You should try to avoid learning where possible as it slows your brain down, but sometimes it is necessary.
Don't over think...if you are thinking and you start learning, take your head and hit it with something heavy and blunt, then and determine if learning is necessary.
What?!??! I don't get it. :?
Patmania said:
I have a listener system setup on top of the MouseInput, and KeyBindingManager.
hehe, well reinventing the wheel can be fun, yes :P