This is just a question in the logic of AppStates.
The reference for AppStates HERE says to use cleanup() and setEnabled() for removing nodes after the state has been exited and for checking the activity of the state. However, the demo HERE overrides the stateAttached() and stateDetached() methods for adding and removing nodes, and never mentions the use of clenaup() or setEnabled().
Is this just a question of preference in terms of cleaning up the state or checking when the state is attached or not, or is there a specific way these methods are supposed to be called?
And ,on a related note to the AppStatesDemo, is my understanding correct in that the mapping for keys that helps switch between states should be in your main game file that changes the states, and custom mappings for that specific state (like, a to move the character left) should be inside the state itself?
There is generally never a reason to override stateAttached and stateDetached. Any demo that has you do that is probably old.
The issue is that they are called from whatever thread did the attaching. However, initialize(), update(), and cleanup() are guaranteed to be called from the render thread. As a general rule, setEnabled() is not thread safe so should already only be called from the render thread.
Well, both are part of the advanced documentation in the wiki. Should I be writing to someone to let them know to update it (I wouldn’t dare update it myself, since I’m still a beginner)?
I just had a look myself but it was complex enough and I’m tired enough that I didn’t want to just poke it in case I got it wrong. The page was created by @zathras who is the main documentation person, I guess she will see this post and know what to do
From what I saw the choice is either to move the code into setEnabled() with an if(enabled) … or to move it into initialize and cleanup. Without looking in more detail at what it’s all doing I don’t know which is the right choice though.
If you never plan to disable/enable your state then just put the creation in initialize() and the cleanup in cleanup().
If you want to be able to enable/disable the state while it is still attached then you have to play a small dance with initialize and setEnabled. I’ve provided this logic before as a BaseAppState again but I can do it again if your state will require that. Otherwise, go with the simpler approach.
Well, if a “paused state” is enabling/disabling a state while it is attached, I do plan to do that. But isn’t that simply using a “isRunning” variable and checking an if statement for isRunning, and doing what I want to do while disable/enabled. This means I can have an attached state that is disabled and attach a new state for the “pause” screen, and when the user exits the pause screen, that state is detached and the game state is then enabled, right?
@machspeeds said:
Well, if a "paused state" is enabling/disabling a state while it is attached, I do plan to do that. But isn't that simply using a "isRunning" variable and checking an if statement for isRunning, and doing what I want to do while disable/enabled. This means I can have an attached state that is disabled and attach a new state for the "pause" screen, and when the user exits the pause screen, that state is detached and the game state is then enabled, right?
If you setEnabled() false then the app state manager will stop calling your update method.
A lot of app states want to add and remove scene graph elements when they are enabled and disabled. To that properly you just have to do a little dance with initialize() and setEnabled() to make sure to cover all cases that might be done, ie: enabled/disabled before attached or after, etc…
If all you want to do is stop updating then that’s easy and already handled.
