Hi,
I’ve found very tricky bug today.
It seems like in Application class in this method
[java]
public void start(JmeContext.Type contextType){
if (context != null && context.isCreated()){
logger.warning(“start() called when application already created!”);
return;
}
if (settings == null){
settings = new AppSettings(true);
}
logger.log(Level.FINE, “Starting application: {0}”, getClass().getName());
context = JmeSystem.newContext(settings, contextType);
context.setSystemListener(this);
context.create(false);
}
[/java]
and exactly in the last line
[java]
context.create(false);
[/java]
application settings are being redefined.
I’ve created my own settings class and loaded them long before the start method was called.
After exiting this method my settings class was AppSettings instead of my own.
I think it is a bug but correct me if I’m wrong 
Why do you create your own settings class? You’re not supposed to I guess.
And why not ??
I need some additional behaviour and I extend the AppSettings class.
But I think that the ‘context’ is not supposed to write its own settings when not asked 
There is no mechanism for that really. What do you want to do? Just use the setSetting() and getSetting() methods…
But it is what I do.
The problem is that I do it before the start method and my settings disappear.
It is not only a problem of the class I use.
Even if somebody uses AppSettings class and sets his/her own key-value pairs in it everything will be lost if it is overwritten.
I don’t think so, you sure you correctly override the copyFrom and mergeFrom methods of the AppSettings in your extended class?
OK I didn’t implement these methods before.
But now that I did I still canot use my own class.
It is still being replaced by AppSettings 
Oh yeah, sure… Still, what you do is simply not supposed to happen, you can’t just go and replace classes as you like ^^
Just use setSetting and set an object of yours with the methods you need instead of doing the evil extension dance, thats way safer and easier…
But I’m not doing anything bad with my classes.
I create my own settings (extending yours) and call the setSettings() method a moment before I start the application.
Even the ‘start’ method in ‘Application’ class is checking if the settings are null or not before setting default instance.
So I still think this instance replacing should never happen.
In the code it looks more or less like that:
[java]
public class MyApplication extens SimpleApplication {
@Override
public void start() {
MyCustomSettings settings = new MyCustomSettings();
settings.doSomeExtraStuffWithMyClass();
this.setSettings(settings);
super.start();
}
@Override
public void simpleInitApp() {
MyCustomSettings set= (MyCustomSettings)this.settings; //ERROR: ClassCastException raised here
}
}
//in some other file…
public class MyCustomSettings extends AppSettings {
//some extra methods and fields
}
[/java]
And pleas do not tell me I shouldn’t do that. I belive there will be plenty of developers extending the settings and setting them before starting the application
Where is the point? You have an option to add any object you like to the class using setSetting(). If you have that theres absolutely no reason to extend the class. And obviously nobody did this before as it does not work. Its like extending Spatial instead of using a Control, bad practice.
[java]
//custom settings does not extend AppSettings
MyCustomSettings settings = new MyCustomSettings();
appSettings.setSetting("customSettings",settings);
//later:
((MyCustomSettings)appSettings.getSetting("customSettings")).doSomeExtraStuffWithMyClass();
[/java]
There is a “save setting to the registry” feature maybe that’s messing things…
This feature allow jme3 app to rememeber what were previous settings.
It’s supposed to not load them when you set your own settings, but maybe there’s a bug…
OK @normen, I see it is a good workaround to the problem and probably a good practice too
But anyway if you allow to extend AppSettings (the class is not final) and you allow to set it to the GameApplication class before the start then
I belive nothing should move it from there.
@nehon if you could check if there is a bug I would be grateful
You have a point there, I made AppSettings final 
Noooooooo …
I still planned to use it the way I did before
It was quite handy.
OK from now on, no more stupid ideas.
Kaelthas said:
Noooooooo ....
I still planned to use it the way I did before :P
It was quite handy.
OK from now on, no more stupid ideas. :P
Bwahaha! You thought you were so clever huh? ;) I think I'll learn from that. Thank @kaelthas :D.