You can have states nested within states. so more than 1 state returns true.
<img src="http://upload.wikimedia.org/wikipedia/commons/thumb/c/cf/Finite_state_machine_example_with_comments.svg/220px-Finite_state_machine_example_with_comments.svg.png">
This is what a Finite State Machine looks like. A door cannot be opened and closed at the same time. You could, however, have ANOTHER finite state machine that is only used while inside one particular state (thus addressing nesting properly).
For example, following the door diagram: the door could have a locking mechanism. When in the closed state, you could change to a lock state in the door machine. When in the lock state of the door machine, you could have access to a lock machine, that upon reaching a certain state, issues an unlock rule to the door machine, which takes it to the closed state again. This sounds rather complicated here, but it's veeeery simple using separate machines, and they never mix up.
Pert diagrams allow multiple active states, that is how concurrency is designed. FSM are completely different from Pert diagrams.
A finite state machine has only one active state, which is the current state of the machine. If there were any more active states, it woudln't be a state machine per definition.
All that said, I
have a request
(two actually).
- First the simple one: an expression to get the current state.
- Second: A FSM is much more useful with transition rules. Could one add rules in the form of rulename->destinationstate? so then one could just do Sprite[FSM].trigger("jump") and if any rule in the current state matches "jump", it would go there. Additionaly, a loop for traversing these rules would be nice (with currentRuleName and currentRuleTarget expressions). One should also be able to check if a state has a certain rule or not, in the form of Sprite[FSM].ruleExists(state,rulename).
The above, coupled, would enable pretty good AI.