Yes. It overrides all default app states that SimpleApplication adds for you… like the FlyCamState. Which is why if you want some of the standard things like StatsAppState, DebugKeysAppState, and BasicProfilerAppState then you have to specify them yourself.
I prefer it this way for my own apps because then I know exactly what I’m adding… and I hate the fly cam JME includes so I get that removed as a bonus.
I’ve got a RoomState, which handles my rooms. And I have a CharacterState, which controls players and maybe AI.
How would I add the rooms and the characters to the same physics space?
I’m not sure what’s confusing… something like:
getState(PhysicsState.class).addTheStuff()
There is a way around , but it wonot work in all cases , which is making the physics space object public static , if you destruct & recreate the game at the same run , this might not work !
If you are already in an app state that extends BaseAppState then you already have simple way to access other app states. Might as well use it.
No need for static global variables in this case.
Yes , but because of this way of organizing the game as separate entities , I get OutOfMemoryException raised up when destructing & recreating the game in the same run , despite of doing detach or removing appstates in onDestroy() context , this happens mainly in android !
Static globals are not going to fix your memory leaks, though.
Yes , I know , So , if anyone has experienced this & got an answer please leave a comment !
To test that app states are cleaning themselves up properly, make them a child of CompositeAppState: SiO2/CompositeAppState.java at master · Simsilica/SiO2 · GitHub
Attach it when you want your game to run instead of attaching all of the individual app states.
Then verify that everything is removed once you detach it again. Note: some things like “did bullet native code really clean itself up” or “are their any network connections still open” are a little harder to check without being in the debugger. But it’s still possible.
Also note: this only works for applications that attach all of their app states one time and then use enable/disable. It doesn’t work with apps that attach app states at random times… or at least won’t check those states specifically. They have to be checked manually.
bulletState = app.getStateManager().getState(BulletAppState.class);
That seems to be working for me, but I’m getting the impression that it might interfere with cleanup?
No, it won’t interfere with cleanup. If cleanup is a problem then it is a problem even if you don’t call that.
If your app states extend BaseAppState (and they should… they really really really should), then from within the app state you can also call:
getState(BulletAppState.class) directly without the other indirection. It’s a helper method on BaseAppState.
And if you aren’t extending BaseAppState then you are just making your life harder. If you like that sort of thing then I have other suggestions, too. 
Yup, I’m extending BaseAppState. Is there anything else you suggest I do with my AppStates?
Not really. Just look at real examples around. I have quite a few apps out there and they are all heavy app state users.
(I’m a little disappointed that I don’t get to creatively suggest ways folks can make their lives pointlessly harder, though. 
)