@normen:
I had an Idea of making the game run in a “runable-test-immediately” mode in SDK, so I want to provide the CharacterControl (or any custom Control ) the InputManager of the Application.
So the scenerio is:
When user click a control Node in Node Explorer type CharacterControl
====> a plugin named “Character Control Manager” show up, then it has a button titled “Link/Unlink”, which attach/detach that Control to inputListener of inputManager of the Application
(other tie-up and link works like provide soundManager, niftyDisplay come in the future if we really need)…
As for now, because of don’t really know where can find the InputManager in the Application of SDK thread, I still have to bind it to the input of the AWT thread, which is a very ugly thing to do and handle, because we must change attach to AWTQueue callLater …everytime, kind of crazy !!!
So, how can I provide the InputManager to a custom control - in the SDK? 
You can’t.
and why can’t I ? Can you tell me a little bit more about it? Because there is no inputManager for the Application ???
Well how would you do it? You don’t have any access from the Control. Also the InputManager is the one from the SDK and not the one that would be in the game later.
Ok, so in SceneApplication class, I see that there is no way to get control over inputManger but through an public method to set an AbstractCameraController …
Y_Y ( what IMO is another ugly sollution )
I just want to move my character, make some sound, … other things LIVE , but no way but modify the SceneApplication code, or Implement another SceneApplication myself!
@#$ , tell me if you think I should stop doing LIVE things right now, for some reason???
Theres no way to do that, you can only use controls somewhat sensibly.
You know, I just want to TEST, all the physics stuff are ready, all the spatial are inplace, so I want to move around, (but like a player) to check if everything ok, test some triger… It’s not absolutely like the in-game but a TEST mode!
For the concerning about the inputManager is not the in-game one, I’ve describe my keyboard and mouse trigger in a XML, then I load that file to automaticly bind my CharacterControl to inputManager via inputManager.addMapping(). So, it’s easy enough to sync in-game and in-edit trigger.
Another approach is to make an “in-game edit” mode, but IMO it’s diffirent with “LIVE test mode”!
so…?
Sorry for this stubborn “LIVE TEST” idea obsess me a lot!
Since I work as a asset artist, it’s ten thousand times conventional to work with SDK more than run a code to see something (agaib sorry for that).
Please tell me can I do this approach without hacking? ( Hacking and modify that code is my last choice )
Here is my first try :
AbstractCameraController
public void onKeyEvent(KeyInputEvent kie) {
if (kie.isPressed()) {
if (KeyInput.KEY_LSHIFT == kie.getKeyCode()) {
shiftModifier = true;
}
} else if (kie.isReleased()) {
if (KeyInput.KEY_LSHIFT == kie.getKeyCode()) {
shiftModifier = false;
}
}
}
MyAbstractCameraControler extends AbstractCameraController
@overide
public void onKeyEvent(KeyInputEvent kie) {
log.info(“We take it from here! Sorry!!!”);
}
in Application.getApplication().setActiveCameraController(MyAbstractCameraControler);
I know it’s bad but … 
Did you see that LIVE TEST or just public inputManager (…soundManager, an NiftyDisplay ) via get() is really a need if we want to provide more features to the developer.
We 've had CustomControl (My most in-love-with feature), but for god sake nothing really interactive can be done with them by now??
my other try is : (being F#$K by this approach already)
MyTestSceneApplication
public class MyTestSceneApplication extends SceneApplication implements LookupProvider {
InputManager getInputManager(){
return inputManager();
}
MyTestSceneViewerTopComponent
// really f#$%ked
public final class MyTestSceneViewerTopComponent extends SceneViewerTopComponent{
// the same thing but
app = MyTestSceneApplication .getApplication();
// F@#$K …
}
:o
Dude, stop it!!! It doesn’t work! You will get more functionality when AppStates are added in some way but that introduces other issues. Just run your game for gods sake.
SceneViewerTopComponent is FINAL and … :x
Yeah, to prevent silly ideas like yours ^^
I really think the first approach can be run without modify the orginal code…
but what issues it can face, conflict with AWT key control??? why don’t we just public the inputManager ???
So, what I have done so far :
- A. Make a new plugin which set a new AbstractCameraControler
1) B. Change the SceneApplication code,( not yet )
- bind inputManager with Control with some special key via that plugin
- disable keyStroke on KeyListener of other Netbean platform components
=> not signifial error appear yet!
8):evil:
Thats actually a good idea as a personal workaround as its not very invasive. You could also make a special wrapper for your Node so that it gets special options in the SceneExplorer (see wiki on how to wrap special controls).