The gem worked by itself, but uses Mouse mapping and is a slightly different use case…
It maps WASD the exact same way you do with the cursor keys. The only difference I see is that it uses an analog listener for movement instead of a state listener. (which makes more sense but it would be good to know if one way isn’t working)
Oh, I see… I used the gem back with my OTHER game, and used for movement+camera control. So yeah, the problem might be the analoglistener vs the statelistener.
Tried swapping up/down with W/S but the result is the same.
Alright, that’s it. StateListener DO NOT have the “Negative” Inputstate: it’s either Positive or neutral. So in my test case the “InputState.Negative” was simply ignored.
Is it by design or is it a bug?
Another weird thing: I’ve replaced the key input with mouse input and I never get the ‘0’ (neutral) inputstate.
Test case:
public class Test extends SimpleApplication{
public static final String GROUP_MOVEMENT = "group movement";
public static final FunctionId F_MOVE = new FunctionId(GROUP_MOVEMENT, "Move");
public static void main(String args[]){
new Test().start();
}
@Override
public void simpleInitApp() {
GuiGlobals.initialize(this);
stateManager.attach(new MovementAppState());
}
class MovementAppState extends BaseAppState implements AnalogFunctionListener{
public static final String GROUP_MOVEMENT = "group movement";
InputMapper inputMapper;
@Override
protected void initialize(Application app) {
inputMapper = GuiGlobals.getInstance().getInputMapper();
inputMapper.map(F_MOVE, InputState.Negative, Axis.MOUSE_Y);
inputMapper.addAnalogListener(this, F_MOVE);
}
@Override
public void update(float tpf) {
}
@Override
protected void cleanup(Application app) {
}
@Override
protected void onEnable() {
inputMapper.activateGroup(GROUP_MOVEMENT);
}
@Override
protected void onDisable() {
inputMapper.activateGroup(GROUP_MOVEMENT);
}
@Override
public void valueActive(FunctionId fi, double d, double d1) {
System.out.println(d+".........................."+d1);
}
}
}
Probably a bug. I will have to look deeper. If you are feeling especially generous then maybe you can file an issue in the tracker on the Lemur github project.
For your use-case, it seems like analog listener is more what you want anyway, yes? (Just noticed you are setting boolean flags… which are bound to be used somewhere else in update())
The mouse is never neutral. There is no ‘center position’ on a mouse.
1 Like
I do!
Yes, the analog listener is probably what I want.
How do I know that the mouse is not moving? I guess when I don’t see events the mouse is not moving. But since the underlying philosophy here is “you get an event when the state changes”, I thought that an event “Mouse stopped” should be fired… or not?
How long do I wait before deciding that the mouse has stopped? Every other axis type has a neutral position but the mouse doesn’t. Any way I pick to do it would be making too many assumptions that it’s easier for the app to handle.
Besides, I really tend to hate interfaces that try to treat the mouse like a joystick… just nasty.
1 Like
How do I enable gamepad/joystick support on Lemur?
Enable it in JME.
1 Like
Now I’m trying to add combo support to Lemur http://wiki.jmonkeyengine.org/doku.php/jme3:advanced:combo_moves
I’ve see that it requires some rework, have you already looked into this @pspeed?
Rework where? To the combo example or to Lemur?
In my opinion, Lemur isn’t where combos should be supported (as in sequence of actions). That’s a code thing. However, Lemur will already let you detect simultaneous combo keys which should make the rest easier.
Edit: Actually, I guess you could pretty easily write an app state that would accumulate combos as lists of function IDs (if properly registered with Lemur) and then once a certain set was matched could forward to a regular state listener with a custom function ID. Still not part of Lemur but could reuse a lot of lemur’s stuff. The app state would then clear the set after a certain amount of time without having received a new event. That would be your internal combo interval.
1 Like
Interesting concept, but how about the Axis? At the end of the day, I want something like the mortal kombat fatalities (up,down, up, up…). FunctionID do not store the direction.
Well, then don’t use function IDs to collect the state. Use your own object… or auto translate one function ID into multiples depending on axis direction.
Sky is the limit, really. All of those solutions are five minute easy solutions.
1 Like
Back to the gamepad support: the button works but when I try to bind the Axis.JOYSTICK_LEFT_Y to the movement I get:
WARN: no axis mapping for:JoystickAxis[name=Y Rotation, parent= XBOX 360 For Windows (Controller), id=2
WARN: no axis mapping for:JoystickAxis[name=X Rotation, parent= XBOX 360 For Windows (Controller), id=3
WARN: no axis mapping for:JoystickAxis[name=Y Rotation, parent= XBOX 360 For Windows (Controller), id=2
WARN: no axis mapping for:JoystickAxis[name=X Rotation, parent= XBOX 360 For Windows (Controller), id=3
WARN: no axis mapping for:JoystickAxis[name=Y Rotation, parent= XBOX 360 For Windows (Controller), id=2
WARN: no axis mapping for:JoystickAxis[name=X Rotation, parent= XBOX 360 For Windows (Controller), id=3
WARN: no axis mapping for:JoystickAxis[name=Y Rotation, parent= XBOX 360 For Windows (Controller), id=2
WARN: no axis mapping for:JoystickAxis[name=X Rotation, parent= XBOX 360 For Windows (Controller), id=3
…and so on.
The sample application works however https://code.google.com/p/jmonkeyengine/source/browse/trunk/engine/src/test/jme3test/input/TestJoystick.java
…but of course it doesn’t use Lemur.
Any advice is welcome, thanks!
Well, to debug further you may need to look at what the test joystick app is sending to the log for the various sticks.
1 Like
Also, those don’t look like lemur log messages so when do those log messages appear? When configuring or when using the joystick or during JME startup? Does the test joystick app output similar log messages?
Without seeing your code, another thing is to make sure that your function group is enabled. I know it’s obvious but I’ve been bitten by that so many times that it’s worth mentioning.
Thanks, if I can’t sort out things I’ll provide a simple self contained test case.
Now that I’m thinking about it… could it possibly be related to the fact that I use up/down with an AnalogFunctionListener and left/right with a StateFunctionListener?
I know that it’s weird, but why not? 
Shouldn’t matter… but if you are worried about it then it’s easy to test, right?