Accessing one of multiple AppStates of same class via the AppStateManager

Would it be possible for future versions to get one of the following:

  • a method in AppStateManager to get a new List containing all AppStates
  • a method in AppStateManager to get a new List containing all AppStates of a specified class
  • AppStateManager.getStates() to be made public (probably with a comment warning of the dangers)?

I have one VehicleAppState per vehicle, and so, would like to be able to access the correct one through the stateManager, for example when a player leaves to remove the vehicle and driver or to change vehicles (detach old/attach new) via the vehicle editor and more.

Or a’m I missing something?

@loopies said: Would it be possible for future versions to get one of the following: - a method in AppStateManager to get a new List containing all AppStates - a method in AppStateManager to get a new List containing all AppStates of a specified class - AppStateManager.getStates() to be made public (probably with a comment warning of the dangers)?

I have one VehicleAppState per vehicle, and so, would like to be able to access the correct one through the stateManager, for example when a player leaves to remove the vehicle and driver or to change vehicles (detach old/attach new) via the vehicle editor and more.

Or a’m I missing something?

This is not as trivial as it would seem. Every time you asked for such a thing we’d have to synchronize and construct a new list for you.

While it is perfectly fine to have multiple app states of a specific type for various reasons, once you need to access only one of them it calls your design into question.

For example, why do you have multiple app states in this case? Either a control is what you want or you really only want one of these app states at a time. It’s not clear.

1 Like

Ah ok, guess I missed that difficulty part :D.

I could do it another way, but I like the beauty of simply adding or removing appStates.
I find it more generic too. Everything is adding and removing, not sometimes calling specific methods and sometimes adding/removing.
I could make a screen to enable/disable any appState… kind of works for everything.

It’s kind of perfect for me.

@loopies said: Ah ok, guess I missed that difficulty part :D.

I could do it another way, but I like the beauty of simply adding or removing appStates.
I find it more generic too. Everything is adding and removing, not sometimes calling specific methods and sometimes adding/removing.
I could make a screen to enable/disable any appState… kind of works for everything.

It’s kind of perfect for me.

Adding and removing is fine but from your description you have state within states. “I need to find a particular state so I can set the state in the state…” I want to make an Xzibit “Yo dawg” statement here. :wink: Something is wrong.

Otherwise, app states are for global state and controls are for spatial-specific state.

:D.
Currently, I attach states and they deploy themselves; and detach states and they clean behind themselves. No states in states ^^.
They extend your BaseAppState and I can easily add enable and disable code if/when I want to. Would probably be used for pausing or something.

My vehicle spatials are already controlled by controls. The appstates are there to deploy, undeploy and most, to “transfer” update calls.

@loopies said: :D. Currently, I attach states and they deploy themselves; and detach states and they clean behind themselves. No states in states ^^. They extend your BaseAppState and I can easily add enable and disable code if/when I want to. Would probably be used for pausing or something.

My vehicle spatials are already controlled by controls. The appstates are there to deploy, undeploy and most, to “transfer” update calls.

“But I need to find one of these individual state to set (something I’m not calling state but is clearly state) in it…”

I still don’t understand why you need to access a specific vehicle state. I think your control is missing a reference maybe… or some state.

i think the most problematic part is that your mind forces you to use app states for everything :slight_smile:

for example, i have entities manager which is app state and in it something like this
protected ArrayList<EntityEvents> entityEventsListeners = new ArrayList<EntityEvents>();
protected HashMap<String, Entity> entities = new HashMap<String, Entity>();

yea yea string based hash map is bad, i know :slight_smile: planning switch to int or long in future

entities manager have methods such as
loadEntity(EntityProfile, SpawnPoint)
unloadEntity(String)
updateEntity(EntityUpdater) (mainly for networking purposes to synchronize hitpoints etc)
getEntity(String)
i can simply give him entity profile which describes entity, and he builds it for me and adds it into its container node (which also is in its entity profile, spaceShips node for space ships), he also fires entityLoaded(BaseEntitiesManager, Entity) and entityUnloaded(BaseEntitiesManager, Entity) events on which i can hook from almost anywhere

simply said, for me, Entity is {EntityProfile + Node + EntityUpdater} - only node, not any control in that node :slight_smile:

bad habit: i hate constructs like
stateManager.getState(BaseEntityManager.class).getEntity("name");
so i can do
((MyApp)app).getEntitiesManager().getEntity("name");

hope this helps you to not depend on appstate for everything :slight_smile:

@Ascaria said: bad habit: i hate constructs like stateManager.getState(BaseEntityManager.class).getEntity("name"); so i can do ((MyApp)app).getEntitiesManager().getEntity("name");

I think this is a completely arbitrary and subjective preference that kind of goes against standard JME practice. Also, you took something that was kind of portable and made it very specific to MyApp. You don’t really gain anything by doing this, it’s not even shorter. Any problem you can conceive of with the first case exists just as much in the second… only now you have to cast to your app class.

BaseAppState even nicely gives you a getState() method right on it to make it even more convenient:
getState(BaseEntityManager.class).getEntity(“name”);

@pspeed said: I think this is a completely arbitrary and subjective preference that kind of goes against standard JME practice. Also, you took something that was kind of portable and made it very specific to MyApp. You don't really gain anything by doing this, it's not even shorter. Any problem you can conceive of with the first case exists just as much in the second... only now you have to cast to your app class.

BaseAppState even nicely gives you a getState() method right on it to make it even more convenient:
getState(BaseEntityManager.class).getEntity(“name”);

yea i can agree with you :slight_smile: im not mature enough yet :slight_smile: but in my case, i want high degree of confidence, that when i ask for entities manager, he is there, because it is crucial for app :slight_smile: yea i can modify your getState method to what i want, maybe to throw null pointer instead of returning null, and i probably do it in the future. im doing ocassionally brutal refactorings :slight_smile:

@Ascaria said: yea i can agree with you :) im not mature enough yet :) but in my case, i want high degree of confidence, that when i ask for entities manager, he is there, because it is crucial for app :) yea i can modify your getState method to what i want, maybe to throw null pointer instead of returning null, and i probably do it in the future. im doing ocassionally brutal refactorings :)

In both cases, if the entity manager hasn’t been initialized yet then you will get a NullPointerException… the single easiest exception to track down. getEntityManager() could just as easily return null as getState(BaseEntityManager.class).

Noooo :D.
At one point, I don’t need a particular vehicle, and so I detach it’s appState and everything gets cleaned.
Player leaves game… so I clean up. In the vehicle editor, I change a vehicle, and therefore remove the old one and put the new one.

Also, when I return to the menus, I need to clean everything up in the opposite order it was added. Getting the list from the appStateManager would allow me to do that without having a different clean method for all different game play modes or using a special list of added appStates, that would be very susceptible to changes in the actual appState list.

I kind of see appStates as a main pattern of developing in jme and think it would be great for it to be totally supported by the api even if it could be argued that there are better ways of doing that.

Perfectly happy as it is… not going to end up screaming naked in the woods if I don’t get it my way… I just think it really makes sense.
This being said, I know I’m not great at patterns and so might be very wrong.