Multiple "dependencies" for state machine "change"

[realien]

I've finally got round to looking at the FSM implementation and really like it for a project I'm game I'm working on that has has a lot of states.

couple of questions

1) can you have as many FSM's as you need ?  They are just separated by the states they are listening for ?  I would need a state manager for some game "overlays" like highscore, login, prizes and a different manager that manages where you are in the game, and they both run in parallel.

2) I load quite a few modules to run the game, one module has a game in it, another has the games videos and another has the games dialogs/overlays.  I can't be "ready" until these modules have loaded, it doesn't seem that the FSM is involved in this issue, i.e. it needs to know when an action takes place, but if I had 3 modules that had to be loaded before the the state RUNNING would be entered, it seems its up to me. The state could be INITIALIZING but after I've loaded 3 modules I could send the ACTION INTRODUCE_GAME and the new state would be INTRODUCING.  Is this "roughly" how it should be done ?  I've been trying to avoid some dependency mechanism for all my modules both being loaded and initialized, but looks like I need to suck it up

[puremvc]

Using MultiCore, each core (the shell or a module) can have it's own StateMachine. So your shell could have the 'macro' level state machine (LOADING, PLAYING, SCORING, etc), then each module, a game level, for instance would have it's own StateMachine that govern's gameplay. It's even possible that modules could represent self-directed meanies, each with their own StateMachines.

-=Cliff>

[realien]

Thanks Cliff, is it "ok" to have multiple state machines ?  I have quite of few different things to keep state of that somewhat "do their own thing" in parallel.

[puremvc]

Currently, no. The StateMachine was designed to hold application state, and there was no intention of managing multiple states within the same core. The main technical reason is that their is no way to give it a unique name at registration time. This could conceivably change, but for the moment the only way to have multiple StateMachines is one per core.

-=Cliff>

[realien]

ok thanks.