Is there a strategy for implementing "input-set" switching?

For my Nifty GUI, I pretty much followed the “Nifty GUI 1.3 - Usecase Scenarios”: every screen does “extends AbstractAppState implements ScreenController”. I have a tree-structured screen hierarchy, with a “stack” of active screens, so that when a child screen exits, it goes back to the parent screen. Each screen can have an optional “screenNode”, where it put it’s scene. The only thing that goes into the real rootNode is the “screenNode”, so that I can easily switch scene, to match the switching screens. This works well so far.

Now my problem is, that the input-binding is global. I would like to have the input-binding be associated specifically with the currently displayed scene (screen), and be able to switch, just like I do with the rootNode. How could I do this? I think this would mean having multiple InputManager instances, one for each screen, and switching which one is currently active. But the InputManager is created in “private void initInput()” of Application, so I can’t influence this directly. The field is protected, so I could change it’s value, but I think it needs something like an activate/passivate for me to be able to replace it.

The only option I see currently, is to have a registerInput()/deregisterInput() in each screen, and call them when I switch from one to the other. Is that what I should do?

@monster said: The only option I see currently, is to have a registerInput()/deregisterInput() in each screen, and call them when I switch from one to the other. Is that what I should do?

That’s the “JME way” unfortunately. It works out ok in practice. I don’t like it, personally, but when I wrote my own InputManager wrapper I didn’t deal with input sets either.

In my InputMapper, I have function groups that I can enable/disable but they still exist in the InputMapper when disabled. I have not checked InputMapper into my Lemur repo yet but I can. It tries to separate the mapping of keys to functions from the registering of listeners with those functions. So it makes sense that the mappings always exist (with appropriate groups) and the listeners come an go… but I still end up with app states that register themselves as a listener in enable and unregister in disable. But that’s usually just one line at least. (My InputMapper also supports key/input combinations which was my second motivation for writing it.)

1 Like

Thanks. I might very well write my own InputManager later, in particular because I think I will need to, when I add “scripting” to the game. But for the time being, I just needs something that works, so I’ll go with registerInput()/deregisterInput().