Hello guys,
there is a SERIOUS issue when deactivating the FlyBy Cam!
This is (generally), what I want to do:
[java]
flyCam.setEnabled(false);
inputManager.setCursorVisible(false);
[/java]
But the internal code of jmonkey will revoke my decision to disable the cursor visibility!
Class: com.jme3.input.FlyByCamera
[java]
public void registerWithInput(InputManager inputManager){
this.inputManager = inputManager;
// both mouse and button - rotation of cam
inputManager.addMapping(“FLYCAM_Left”, new MouseAxisTrigger(MouseInput.AXIS_X, true),
new KeyTrigger(KeyInput.KEY_LEFT));
inputManager.addMapping(“FLYCAM_Right”, new MouseAxisTrigger(MouseInput.AXIS_X, false),
new KeyTrigger(KeyInput.KEY_RIGHT));
inputManager.addMapping(“FLYCAM_Up”, new MouseAxisTrigger(MouseInput.AXIS_Y, false),
new KeyTrigger(KeyInput.KEY_UP));
inputManager.addMapping(“FLYCAM_Down”, new MouseAxisTrigger(MouseInput.AXIS_Y, true),
new KeyTrigger(KeyInput.KEY_DOWN));
// mouse only - zoom in/out with wheel, and rotate drag
inputManager.addMapping(“FLYCAM_ZoomIn”, new MouseAxisTrigger(MouseInput.AXIS_WHEEL, false));
inputManager.addMapping(“FLYCAM_ZoomOut”, new MouseAxisTrigger(MouseInput.AXIS_WHEEL, true));
inputManager.addMapping(“FLYCAM_RotateDrag”, new MouseButtonTrigger(MouseInput.BUTTON_LEFT));
// keyboard only WASD for movement and WZ for rise/lower height
inputManager.addMapping(“FLYCAM_StrafeLeft”, new KeyTrigger(KeyInput.KEY_A));
inputManager.addMapping(“FLYCAM_StrafeRight”, new KeyTrigger(KeyInput.KEY_D));
inputManager.addMapping(“FLYCAM_Forward”, new KeyTrigger(KeyInput.KEY_W));
inputManager.addMapping(“FLYCAM_Backward”, new KeyTrigger(KeyInput.KEY_S));
inputManager.addMapping(“FLYCAM_Rise”, new KeyTrigger(KeyInput.KEY_Q));
inputManager.addMapping(“FLYCAM_Lower”, new KeyTrigger(KeyInput.KEY_Z));
inputManager.addListener(this, mappings);
inputManager.setCursorVisible(dragToRotate || !isEnabled());
Joystick[] joysticks = inputManager.getJoysticks();
if (joysticks != null && joysticks.length > 0){
Joystick joystick = joysticks[0];
joystick.assignAxis(“FLYCAM_StrafeRight”, “FLYCAM_StrafeLeft”, JoyInput.AXIS_POV_X);
joystick.assignAxis(“FLYCAM_Forward”, “FLYCAM_Backward”, JoyInput.AXIS_POV_Y);
joystick.assignAxis(“FLYCAM_Right”, “FLYCAM_Left”, joystick.getXAxisIndex());
joystick.assignAxis(“FLYCAM_Down”, “FLYCAM_Up”, joystick.getYAxisIndex());
}
}
[/java]
And this is the line where the engine thinks to know things better:
[java] inputManager.setCursorVisible(dragToRotate || !isEnabled());[/java]
I wonder, why the registerWithInput method is executed though I deactivated the FlyByCam. In my opinion the whole method should not be called when the cam is deactivated.
I think this is a bug that should be fixed. I don’t see a chance to have no flyByCam and no cursor simultaniously, as the registerWithInput method is called after simpleInitApp is done.
EDIT:
Additional Information:
The registerWithInput method is first called by:
SimpleApplication.update:238 => AppStateManager.update:249 => AppStateManager.initializePending:219 => FlyCamAppState.initialize:75 => FlyByCamera.registerWithInput:191.
The line numbers match the latest nightly build at June 8th 2012.
First of all I think there shouldn’t be such legacy initialization and everything should be done after simpleInitApp. But this is a design thing I want to leave to the developers. But what must not happen is, that the flyCam is initialized, though it is disabled - imho.
subclass flycam and override what you need.
If with “initialize” you mean the call to initialize() - that can’t be avoided, the semantics of the state manager’s attach() method mandates that initialize() will be called.
But I think
[java]inputManager.setCursorVisible(dragToRotate || !isEnabled());[/java]
is wrong: The cursor should be invisible only if the FlyCam is enabled AND it’s in drag-to-rotate mode. Negating that condition ('cause we need the “is visible” state) gives
[java]inputManager.setCursorVisible(!dragToRotate || !isEnabled());[/java]
@Sploreg:
Sorry, if I want to work around this thing I just put inputManger.setCursorVisibility(false); to the simpleUpdate method so it is called after your design flaw. But you should be seriously interested in fixing those things.
The control flow would be as follows:
We initialize something we don’t need, cauz it’s disabled
We mess up other stuff while doing this unnecessary step
We override things to fix that fail…
Excellent. Why not just following the single responsibility principle and remove any setCursorVisibility calls from the FlyByCamera class? They are not needed there as the user should decide during application initialization, if he wants to have a cursor from the beginning or not.
One of the most important things when constructing an API is: NEVER revoke decisions the user explicitly sets! Throw an Exception if the user decision is in conflic with what the API needs, but never revoke a user’s decision silently!
Why you should follow those guidlines when developing JME:
If you want your engine to become a serious option for game developers, the API needs to be prepared for formal verification of the programs that are using it. So it must not change states silently within methods that are not responsible for these states. The verifier will not expect this! After all it is documented nowhere!
Your parent’s didn’t give you many skillpoints in Tact did they?
@Sploreg said:
Your parent's didn't give you many skillpoints in Tact did they?
They probably had to work with a low pool to start with.
@universe I'd suggest you drop the condescending tone. Not very welcomed here.
Ok, may I just validate your last posts @Sploreg and @madjack?
[ ] qualified post to the topic
[ ] respecting contribution of an obvious bugfix
[ ] understanding the deep impact of the design flaw just displayed
[x] personal offense
A poor summary… I take the liberty to validate mine:
[x] qualified post to the topic
[x] contribution of an obvious bugfix
[x] understanding the deep impact of the design flaw just displayed
[ ] personal offense
I did not know that JME developers are pissed off so easily when someone emphasizes the importantness of a special thing when the respective developer seems to care not a bit about it. I did not say that you all are poor developers, I said that this is poor code - and this is something we should say very often in development stage - this is how progress works! If I do something very stupid in code, I would be happy about someone detecting the flaw. Obviously you aren’t.
Feedback is always welcomed and often integrated if it works with the codebase; you can see posts all over the forums of this working. However if the person is rude then there are better things to spend our time on. Who wants to work with someone with that attitude anways?
@Sploreg
I admit that I reacted very irritated to your unqualified first answer - I fear that this had some impact on my second post.
But please be honest: don’t you think that answers in the form of “we don’t respect things, just override stuff if you are not confident” are the wrong way reacting to serious reports?
And if you are REALLY honest, you will admit, that you STILL have not answered in a qualified way to this report. You gave no reason why chaning this particular line of code is impossible. You still have not explained the decision behind this internal setCursorVisibility calls. I miss any technical or professional statements.
I don’t want to blame you if you have other things to do - but this seems a lot that you just don’t care.
EDIT:
Appendix:
If I call behaviour “unqualified” I don’t mean stupid, dumb or silly. By unqualified I mean something like “not topic related” or “not interested in discussion or solution”. Maybe you missunterstood that.
The point you decided on using SimpleApplication, dont use Simpleapplication if you dont want what it offers, you could just use Application class as a base.
It also has no flycam.
@Empire Phoenix:
You may be right about this. But still: This is just a workaround! I expect that things are fixed. If I develop things and users come to me with flaws I do fix them.
Btw.: this is no behaviour the SimpleApplication class “provides”. It is invoked implicitly. And in respect of loose coupling of the individual components the SimpleApplication class should provide, it the individual parts should be turned off, when not needed, without affecting the other parts.
Your answer may be right, but is unfortunatly of the form: “if it is wrong, don’t use it.” But why should it stay wrong?
Yeah, we have enough people who tell us what and how the engine should work and what they regard as a good way of writing libraries so going down that road is a reliable way to get ignored.
With our experience we can say that the simple FlyCam control exactly serves its purpose as a simple and flexible way to deal with mouse input at the beginning of your game development. The FlyCam is not intended to be the base class for all mouse input in jme, its supposed to do what it does, which involves managing other aspects of the input scheme.
And btw, jME is out for almost ten years now, its definitely not like this is in the beginning stages, we already have two versions worth of experience behind us.
@normen:
Okay, so why do you call it beta? Sorry, but this is unbelievable…
First of all I know that you have lots of work to do and can’t respect any suggestion. This is obvious. To be everybodies darling is impossible.
But you deal with things in a way that is just unprofessional. You don’t even spend a thought about this issue. Maybe you are going the way “if less than 100 people are complaining about it, we just don’t care”.
Yes, the flyCam does what it should do. But it fails when getting deactivated. Aren’t you interested in ALL of your code beeing flawlessly and not just the important or most frequently used stuff?
Just tell me! If you tell me that you just don’t care I go my way and will work around it. You should not do this, but it’s your free choice. But this is PHP developer style - and I hope you all know how many flaws this language contains. I just don’t want jme - as a very good opportunity to have a great java 3D engine - to fail on such simple things.
a) its the jME 3 beta, genius
b) again you complain about a simple example class that would never be used in any real game and is contained in an open source game engine developed by people in their free time as “unprofessional”… How exactly do you expect your elaborations to be perceived? How exactly do you think this is purposeful at all? You understood how the class works, fine for you, now you can do with it what you want.
I did exactly what @Empire Phoenix said.
My reasons were different, but the basic situation was the same: I found SimpleApplication and its associated standard AppStates too tightly coupled and too little open to modification (not even via subclassing), so I took that code, copied it, and built my own little framework.
Currently I have:
- ClientApplication - equivalent to SimpleApplication but tied to having a display. I don't need AppStates for the server (headless) mode, so the standard Application works fine there.
- StdAppState - some convenience methods (logging, clean switching from one AppState to the next; I'll probably put more functionality there)
- NodeAppState - an AppState with a notion of a root node.
- GuiAppState - an AppState for a Gui. Defines a root node for GUI purposes and initializes it accordingly (culling etc.). NiftyScreenAppState and StatsAppState are subclasses.
- SceneAppState - an AppState for a Scene graph. Very little logic here, standard scenegraphs already do the Right Thing. (Multiple SceneAppStates will end up having multiple root nodes. I think/hope that jme3 can handle that easily enough, it's already handling gui root and scene root.) The ability to use multpile SceneAppStates at the same time could be used to overlay a "ghost world", for example; other than that, you're probably never have more than one SceneAppState active at the same time.
- FlyCamAppState - directly descends from AbstractAppState.
a) oh i’m sorry - the experience hides the bugs - i missed that point
b) I expect that all API elements are working as expected (i.e. at least as documented). This is purposeful for any developer trying to use the stuff provided by the engine. And if there is an adapter class that takes care of some things I don’t want to take care of, it should work flawlessly so I can use it.
Just imagine the MouseAdapter of AWT would do random stuff and messing states up. Silly example, isn’t it? But that’s just what your FlyCam does.
If things are there I expect them to be correct. If they aren’t, they should be fixed. If there is no priority to fix this, it should be marked unstable. If there is any intention behind those things beeing like this, it shold be documented. This is all I want - and this is just the standard in software development.
And what I want most is good support and qualified statements. I visited some other threads in this forum and quite in every thread I find answers like:
“Don’t do this.”
“Try something else.”
“There are better ways.”
“Uncommented wikipedia link”
If you don’t have the time to do good support, don’t do it - this is ok! But this is bad support. And obiously you are not ready to understand this. Admins that are downvoting criticism are arrogant as hell - why don’t you ban me right away to underline this? I’m done here - this is ridiculous (but worth a try).
I somewhat agree with the OP as you would expect that to work. And it’s because (maybe already mentioned) that the FlyCamAppState.initialize() method call (which calls flyCam.registerWithInput()) is executed on the next frame after simpleInitApp(), hence negates any settings in simpleInit().
@wezrule said:
I somewhat agree with the OP as you would expect that to work. And it's because (maybe already mentioned) that the FlyCamAppState.initialize() method call (which calls flyCam.registerWithInput()) is executed on the next frame after simpleInitApp(), hence negates any settings in simpleInit().
I guess I'm confused as to what is really wanted since there was too much warring in the other posts for me to read them. I thought the problem was the registerWithInput was still called even if the camera was disabled. You should be able to set the flyCam to disabled in simpleInit() but it will still register with input.... because otherwise re-enabling it would fail.
There may be a misconception on what enabling/disabling the fly cam means.
Edit: wezrule removed his sample code so my response no longer makes as much sense.
I'm the best person to answer in this thread but I'm kind of done with it now. It's not clear what the problem is anymore and there was too might fighting for me to bother reading all of that other stuff.
@universe said:
@normen:
:D Okay, so why do you call it beta? Sorry, but this is unbelievable....
First of all I know that you have lots of work to do and can't respect any suggestion. This is obvious. To be everybodies darling is impossible.
But you deal with things in a way that is just unprofessional. You don't even spend a thought about this issue. Maybe you are going the way "if less than 100 people are complaining about it, we just don't care".
Yes, the flyCam does what it should do. But it fails when getting deactivated. Aren't you interested in ALL of your code beeing flawlessly and not just the important or most frequently used stuff?
Just tell me! If you tell me that you just don't care I go my way and will work around it. You should not do this, but it's your free choice. But this is PHP developer style - and I hope you all know how many flaws this language contains. I just don't want jme - as a very good opportunity to have a great java 3D engine - to fail on such simple things.
One thing, if you want to remove the fly cam then remove it. SimpleApplication was modified some time back so that you could completely remove fly cam if you wanted to. Search for FlyCamAppState and you should find another post talking about this.
@pspeed:
The first useful answer from the staff - i very much thank you for this. I would like to have a +5 button for you. I’ll search for it.
I missed a direct remove method but if there is any other way to remove it (via the AppStates) I’ll find it.
And yes, the problem was that the registerWithInput methods overrides any previously set visibilty of the cursor.
@Others: take an example - this is how support works.