[SOLVED] How to get all App states that attached to the state manager in JME 3.2.?

how to get all App states that attached to the state manager in JME 3.2.?
I want to use it to pause and resume the game…

1 Like

For debugging purposes, I use reflection to access the state manager’s internal lists. I don’t put much faith in the results, however, since there are many possible race conditions that might cause inaccuracies.

        Method getInitializing, getStates, getTerminating;
        try {
                    = AppStateManager.class.getDeclaredMethod("getInitializing");
            getStates = AppStateManager.class.getDeclaredMethod("getStates");
                    = AppStateManager.class.getDeclaredMethod("getTerminating");
        } catch (NoSuchMethodException exception) {
            throw new RuntimeException(exception);

        AppState[] initializing, active, terminating;
        try {
            initializing = (AppState[]) getInitializing.invoke(manager);
            active = (AppState[]) getStates.invoke(manager);
            terminating = (AppState[]) getTerminating.invoke(manager);
        } catch (IllegalAccessException | InvocationTargetException exception) {
            throw new RuntimeException(exception);

I would suggest using a CompositeAppState for when you want to enable/disable a bunch of app states together.


For example, you can have a GameSessionState which extends CompositeAppState and add your app states inside it as a child state. Now when GameSessionState gets enabled/disabled all its children will also get enabled/disabled. The same goes for attach/detach as well.


thank you, I didn’t know about the race conditions of the Appstates…

From a game perspective - pausing - you should already know because you attached them. I don’t know of a situation I wouldn’t know. And I wouldn’t want to pause them all in a game, because if I’d done it correctly the pause menu would also be a state, and I’d very much want an update loop in that situation, and possibly attach others - in which case the list is invalid.

There are also other states like the audio positioning state that need to remain alive - or the physics state, a network state, etc.


As other suggest, you should never pause all of the app states. You have no idea what they are doing or if they are important or not. Someday, input itself may be handled by an app state then you’d never be able to unpause your game.

It’s a mistake to believe that “everything should pause” when the game has been paused. Only the game should pause.


@yn97 I am thinking of , if you want really to pause the game, then lose its window focus :


Then , fire an event for P button to display a JOptionPane or JFrame you customized as you want , & I think you have gained a Game Pause anyway ,if you have made it already , Can you post your code please ? Thank you

No… just no.

All pause on lost focus is doing can be done another way. One need only spend 20 seconds looking at the source code.

And again, it’s the wrong approach. You never ever want to pause “everything”… only the game. Which requires a proper architecture to define what should/shouldn’t be paused.

As an example, a lot of games ‘pause’ while you open up the in-game menu. You 100% would NOT want “everything” paused. You wouldn’t be able to click buttons, animated buttons wouldn’t animate, etc…

And you never want “paused” to look like “locked up” because then users will just kill the application through task manager. “Window not responding…”


So, Pausing each state as needed is the best method like pausing physics state for example .

One solution was already suggested:

The trick is actually thinking about what you are doing and organizing things appropriately.

In an SiO2-based app, you could also potentially just pause the GameSystemManager. Which would be kind of a cool effect for some games because grass would still sway, particles would still particle, etc… all purely visual effects would continue but the game state itself would be frozen.

Whatever the case, “lock up the whole application” is not the right answer.