Hi,
I’ve been using the inputManager’s method, simulateEvent, with sdk 3.0 RC 2, but now I checked the latest nightly build from 22-01-2013 and it’s gone. Why did it disapear?
Because it was only checked in by accident with another commit. It doesn’t really work and it’s unnecessary.
I see … Could you recommend anything else to simulate input events?
@ildikoszabo4 said: I see ... Could you recommend anything else to simulate input events?
Why do you need to simulate input events? I haven’t seen a use-case where it is required.
I'm working on a jmonkey application that will run on more computers, but only one will have controls and i need the other applications to responds to the same input events like the one with the controls does.
So i've sent the input event through socket (that's why I needed it to be serializable: http://hub.jmonkeyengine.org/forum/topic/inputevent-non-serializable ) and used the simulate event method to apply the event in the other applications, too.Why go this way? Just call the callback metods when events arrive (the approach is a bit flawed anyway but I guess its good to learn that first hand ;))
@ildikoszabo4 said: I'm working on a jmonkey application that will run on more computers, but only one will have controls and i need the other applications to responds to the same input events like the one with the controls does. So i've sent the input event through socket (that's why I needed it to be serializable: http://hub.jmonkeyengine.org/forum/topic/inputevent-non-serializable ) and used the simulate event method to apply the event in the other applications, too.
As normen suggests, it’s better to abstract this at the listener side instead of sending the raw events in and trying to poke them in artificially. Poking them in artificially will never run like a real user sitting there and will inevitably lead to dozens of unforeseen issues that can be avoided by just sending the commands instead of the raw events.
Could you be a little more specific? What callback methods?
Simple example. Button W - move camera forward.
Don’t send “move camera forward” command to the client, either send command “move camera forward 0.12 units” or “set camera position to x,y,z”.
Then no matter how many ways at the controlling client the user has to move forward you still only send the same move forward command.
Quite apart from anything else sending the key press you will end up out of synch surprisingly quickly. Every time you move that camera there is going to be a slight error introduced due to varying framerates, etc.
The server application doesn’t have predefined actions and mappings for keys. It shouldn’t care what an input does, it cares just to pass it away. And it should be done without analyzing whether the camera has moved, or a cannon ball was shot, for example.
From what I understand of what you want and how things are implemented, I see a huge wall-of-hurt coming your way.
Have the server distribute the “end result” because, as @zarch said, things will take the left field quite fast.
@ildikoszabo4 said: The server application doesn't have predefined actions and mappings for keys. It shouldn't care what an input does, it cares just to pass it away. And it should be done without analyzing whether the camera has moved, or a cannon ball was shot, for example.
But what does it pass it to? Another app that speaks your protocol. The server shouldn’t care what the event is but sending InputEvents directly “key W pressed… key W released” is generally the worst way to synch things up. Send the interpretation instead of the raw event.
Since I can’t even conceive of what you are trying to do or how it can be useful, that’s the best I can offer. The simulateEvent() thing was something I added when I was trying to send joystick events as keys to nifty… but that was a nifty problem and so the nifty layer has a simulateKeyEvent() now. The one on InputManager never worked properly because it is not really thread safe.
@pspeed said: But what does it pass it to? Another app that speaks your protocol. The server shouldn't care what the event is but sending InputEvents directly "key W pressed... key W released" is generally the worst way to synch things up. Send the interpretation instead of the raw event.Since I can’t even conceive of what you are trying to do or how it can be useful, that’s the best I can offer. The simulateEvent() thing was something I added when I was trying to send joystick events as keys to nifty… but that was a nifty problem and so the nifty layer has a simulateKeyEvent() now. The one on InputManager never worked properly because it is not really thread safe.
The clients should trigger their specific mapped actions after they receive the input. How can be this done without the simulate event method?
How can I send the interpretations if I don’t have access to all mappings and triggers registered?
Let me be as clear as possible. What you are trying to do will not work. Full stop. End of story. You may be able to bodge something together that looks as though it is working for a while but desynch and drift will always and inevitably appear.
You’ve already been given a few options as to how to do this properly - and there are plenty of others out there as well. Google is your friend.
@ildikoszabo4 said: The clients should trigger their specific mapped actions after they receive the input. How can be this done without the simulate event method? How can I send the interpretations if I don't have access to all mappings and triggers registered?
Key W is pressed.
You create your own “Key W is pressed” message.
You send the message.
You receive it on the client.
You call the listeners that would be called if “Key W is pressed”.
And then randomly clients will be out of sync with one another or buffer a full 2 seconds worth of input data and quickly stream it back because of network hiccups, etc… but you apparently don’t mind these glitches so it’s ok.
InputManager was not designed for this sort of multithreaded access and will have randomly lost events if you had actually used the incorrectly added simulate event method. My supreme apologies for having accidentally committed it in the first place and caused so much trouble.
If you want to really simulate user events and don’t care about all of the networking-related issues that make it look bad then you might want to investigate poking the events in at a higher stage… maybe using the Java robot classes or something.
Ok. Thank you for your answers.