If I’m not mistaken, there is no way for me to ask jme for what triggers are linked to what mapping.
Two reasons:
there is no method to get useful data out of the jme input system
the input system holds triggers as hashed integers
Did I miss something? Or do I have to duplicate such data like I had to with appStates?
Mind you, in this case, it’s not only about duplication, it’s also about dependencies between libs… I’m hoping to add support for custom triggers to TGG so it can support joystick and so on without depending on special classes to feed it data.
You might want to look at Lemur’s InputMapper. It can be used without ever touching any of the rest of Lemur but it provides a LOT of useful stuff on top of regular InputManager and support a logical delineation between what triggers a function and the function being triggered in a more general way.
From there if it is still missing methods then we can talk about it… as one of its main jobs is to support the kind of thing you want to do.
Sadly, it’s a very different paradigm and would force me to change half my application and change half of TGG’s main class.
Yes… it does make me very self-conscious :.
Basically, TGG kinda takes care out of the box of registering/listening and on my side, I just react to events on the TGG controls.
Each of my 2D screens are made of 3 classes:
the screen (the view)
the GUI (fetches data + reacts to activations (and ddlb selection changes etc))
the listener which checks the name of the control activated and calls the linked reaction method from the badly named GUI class. NB: I enriched the controls so they provide their name when they call their listener.
… and mostly due to my track editor, I have dozens of such screens. It is very convenient though and supported everything I wanted to do out of the box, up to crud generic screens built from adapters.
TGG itself has hard coded what triggers it listens to.
It also supports home/end/shift/etc and such inside text inputs which I think would be hard to move to inputMapper.
I was hoping to add a refreshTriggers() or something method on TGG’s main class that would have it interrogate the inputManager and from there discover what triggers it should listen to instead of checking for constants. I would have to add the joystick part.
The idea is to make jme core the core data handler and have libraries interrogate it.
I really like what you did there (I’m in awe about your addMapping method), but on this project, it seems a hard task moving to it due to how TGG and my stuff works. We are the culprits :D.
This is what I’m currently thinking… not saying it’s right or anything (how would I know lol). I’m open to debate/discuss this if you want to.
So currently, I’m thinking of making an InputManagerWithRead class composed of the app.inputManager, that would store mappings/triggers and offer methods to get that data. That would create a dependency and data duplication though.