AppState now needs an Id?

I usually code with the SDK 3.2, so today when I built my game with gradle I got:

MyAppState is not abstract and does not override abstract method getId() in AppState

Oh well I said, that’s probably 3.3.0 alpha. So I went from

def jme3 = ["v" : '[3.1,)', "g": "org.jmonkeyengine"]


def jme3 = ["v" : '3.2.4', "g": "org.jmonkeyengine"]

But stil I got the same error :frowning:

Any help is appreciated, thanks!

Then something else is pulling in a newer version. Run gradle dependencies to see what.

Also, this is an indicator that you are implementing the AppState interface directly instead of subclassing one of the base classes. At best, this means you will be tweaking your classes every time we update the interface… at worst, it means your app states are actually not handling enabled state correctly, etc… which is tricky enough to get right that even the BulletAppState was messed up (and still is to some extent).

Best practice is to extend BaseAppState when possible because it takes care of enabled state with respect to init/cleanup correctly.

You’re right! Here’s the infidel:

import com.simsilica.lemur.event.BaseAppState;

Not sure how that’s the infidel. If you run with the version of lemur that’s compatible with JME 3.2 then you should be fine.

That won’t affect your MyAppState, though… unless you are extending the Lemur BaseAppState and using the last release (which is only compatible with JME 3.2).

I was waiting to release 1.13.1 until JME 3.3 beta… which was delayed because the build scripts were messed up.

And note, this versioning stuff will get resolved tomorrow or Saturday.

I mean, I was extending that instead of Changing the import to the right one solved my issue :slight_smile:

1 Like

Note: make sure you use @Override for the methods you override so that you see errors. Lemur’s base app state uses enabled()/disabled() while JME’s uses onEnabled()/onDisabled().

1 Like