Disable W,A,S,D on camera control SimpleApplication

The title says it all what is the best way to the wasd on the camera control without disabling the mouse controls?



currently I am:

[java]

inputManager.deleteMapping("FLYCAM_StrafeLeft");

inputManager.deleteMapping("FLYCAM_StrafeRight");

inputManager.deleteMapping("FLYCAM_Forward");

inputManager.deleteMapping("FLYCAM_Backward");

inputManager.deleteMapping("FLYCAM_ZoomIn");

inputManager.deleteMapping("FLYCAM_ZoomOut");

inputManager.deleteMapping("FLYCAM_Rise");

inputManager.deleteMapping("FLYCAM_Lower");

[/java]


EDIT:
but this isn't working it can not find the mapping

Over-ride the application constructor, don’t add flycam. Create your own version of flycam with the keys removed. Add that as a state.

1 Like

@zarch Thanks didn’t think of that I was writing my own though. :smiley:

Yeah, doing it this way you get full control of the camera behaviour rather than trying to hack around the existing code.

It can’t find the mapping because they don’t exist until after simpleInit() is executed. The FlyCamAppState doesn’t initialize the fly camera until after simpleInit() (because of the way app states work) and fly cam’s keys don’t get registered until it has been initialized.



Zarch’s approach is probably the easiest way around this.

[java]flyCam.setMoveSpeed(0);[/java]



Even lets you use the built-in mouse cam without having to make your own.

1 Like

I know this topic is old, but I looked for an answer to this problem on the web without finding a simple working solution (Nah, didn’t want to override the FlyByCam :wink: )
So as pspeed said, the FlyByCamera mapping doesn’t exists yet when the SimpleApplication.simpleinitApp() method is called.
If you put a breakpoint in the FlyByCamera.registerWithInput() method (where the mapping is hard-coded !), you’ll see that it’s first called in the SimpleApplication update() method by the AppStateManager through the FlyCamAppState associated object (and called once of course because of the FlyCamAppState initialization done once).

So a (maybe not-so-clean ?) solution, without overriding the FlyByCam class, is to redefine the mapping in your SimpleApplication by registering a one-shot specific AppState.
If you add the code below a the end of your SimpleApplication.simpleInitApp() method, it works.

[java]
stateManager.attach(new AbstractAppState() {
@Override
public void initialize(AppStateManager stateManager, Application app) {
super.initialize(stateManager, app);
redefineKeys();
stateManager.detach(this);
}
});
[/java]

This code registers an AppState which has only the task to redefine your FlyByCam key mapping and then it unregisters itself from the StateManager.

For instance, my key redefining for an AZERTY keyboard is the following:

[java]
private void redefineKeys() {
inputManager.deleteMapping(“FLYCAM_Forward”);
inputManager.deleteMapping(“FLYCAM_Lower”);
inputManager.deleteMapping(“FLYCAM_StrafeLeft”);
inputManager.deleteMapping(“FLYCAM_Rise”);
inputManager.addMapping(“FLYCAM_Forward”, new KeyTrigger(KeyInput.KEY_Z));
inputManager.addMapping(“FLYCAM_Lower”, new KeyTrigger(KeyInput.KEY_W));
inputManager.addMapping(“FLYCAM_StrafeLeft”, new KeyTrigger(KeyInput.KEY_Q));
inputManager.addMapping(“FLYCAM_Rise”, new KeyTrigger(KeyInput.KEY_A));
inputManager.addListener(flyCam, new String[] {“FLYCAM_Forward”, “FLYCAM_Lower”, “FLYCAM_StrafeLeft”, “FLYCAM_Rise”});
flyCam.setMoveSpeed(10f);
}
[/java]

As this "Anonymous"AppState is attached in the StateManager AFTER the FlyByCamAppState (which is attached in the SimpleApplication Constructor),
the FlyByCamAppState.initialize() method (with the hard-coded mapping) is called BEFORE the AnonymousAppState.initialize() method (with the mapping redefining).

1 Like

Yep, that’s also a way around the issue.

Note: eventually just about everyone ends up replacing flycam. It’s chock full of such limitations. It’s good for demos/tests but most games will want more control over what it’s doing. However, your one-shot app state example may delay that for some folks and let them write their games more before needing to make a proper camera.

@pspeed said: Yep, that's also a way around the issue.

Note: eventually just about everyone ends up replacing flycam. It’s chock full of such limitations. It’s good for demos/tests but most games will want more control over what it’s doing. However, your one-shot app state example may delay that for some folks and let them write their games more before needing to make a proper camera.

Wow ! I didn’t expect to have an answer as fast on such an old topic ! You deserve your nickname :slight_smile: !
Yeah, you’re right, it’s just a temporary hack, good when starting a new game/demo from scratch.
Actually, it’s exactly my case as I installed JME3 a few hours ago to test the first simpleapplication example and discover this tool which seems AFAIK really great and well-suited for the little game I’d like to develop and I must say that I was a little bit disappointed with this keyboard issue.

I looked around on the web to get a solution (see some solution based on a KeyBindingManager, but didn’t find it in the code of JME3, maybe it was in JME2 and doesn’t exists anymore ?)

As you looked really involve, I think I will ask you a question by Private Message about another issue I have with the Netbeans IDE JME3 code source navigation (as my usual IDE is Eclipse) before possibly opening a new topic about it.

@hillheaven said: As you looked really involve, I think I will ask you a question by Private Message about another issue I have with the Netbeans IDE JME3 code source navigation (as my usual IDE is Eclipse) before possibly opening a new topic about it.

You should open a new topic. Other people know more about the IDE than I do, especially when coming from Eclipse.