hey, cliff

I like the changes, simple and yet obvious.

Interested to see how this will change the way I use it.

consider this:

<fsm initial='A'>
    <state name='A'>
        <transition action='toB' target='B'/>
    </state>
    <state name='B'>
        <transition action='toC' target='C'/>
        <transition action='toD' target='D'/>
    </state>
    <state name='C'>
        <transition action='toA' target='A'/>
    </state>
    <state name='D'>
        <transition action='toA' target='A'/>
    </state>

</fsm>

if the state is B, you can go to C or D (be calling ACTION 'toC' or 'toD')
however in A calling these ACTIONS would do nothing. You would have to call 'toB' to change state, as the only legal state that you can go to from A is B

does that answer your question?

cool :)

on passing states

@Cliff: the argument here, I think, is not to pass the state in the StateMachine's outgoing notifications, but to be able to pass the body of an incoming ACTION notification onto the outgoing ones, instead of the state.

@undersound: I've come across this problem myself, and my solution was to change the model, then change the state.  I don't necessarily think that data should be passed from one state to another, surely states need have no knowledge of each other.

The state in flex is specifically a visual state.  The StateMachine utility, manages application wide states.

take a look here http://puremvc.org/pages/demos/AS3/Demo_AS3_Flex_StopWatch/srcview/ to see the Stop watch demo, study the InjectFSMCommand.as (org.puremvc.as3.multicore.demos.flex.stopwatch.controller).  The states are defined in xml, then injected via the FSMInjector into the StateMachine.

I can see a big value in being able to pass the notification body on to the entering notification, and I can also see that instead of passing the State in the body, we could pass the state name in the notification type...

I'm not totally convinced though

except that the body of the notifications sent by the StateMachine is the State which is being moved to... isn't that pretty important information?

how would you get round that?

well, since the body is not being used I can see no reason not to
Cliff?

gjastrab, can I confirm that you are requesting that if you send a body with an StateMachine.ACTION notification, then it gets passed to the subsequent notifications sent by the StateMachine (ENTER_STATE, EXIT_STATE and CHANGE)?

this seems like quite a good idea.... will ponder

@cliff - is this where we should look into implementing conditionals into the FSM?

sorry, didn't see this thread...

@cliff - ok by me to remove the entry into same state... I think I was even harder and threw an error.

as for AsynchCommand, I did this demo http://revisual.co.uk/?p=409 and failed to get it to hold the thread, so I don't think that is a so;ution here, though I may have done it wrong.

I can see this Asynch incompatibility with the Statemachine as being a problem for some people, though I myself haven't yet come across a way of organising the states that can't overcome this.

@sinosoidal what I have done in the past is to sendNotification(CHANGE_STATE_REQUEST, null, ACTION_NAME), which will trigger a Command that pops the alert, or does what ever checking is necessary.  If all conditions are met, a sendNotification(StateMachine.ACTION, null, ACTION_NAME) is triggered, otherwise nothing.

hope this helps

at the moment, a transition to self is not accepted, and will fail silently.

Have a look at this post:
http://revisual.co.uk/?p=237
This was my original version of the StateMachine, it is linear, and so is probably more what you are looking for, though you won't be able to cancel your transitions in it.

My advise is that you'ld be better off using the current version (hosted here in the manifold), and declare the seven different actions for each state, as you will have more control, and better future-proofing (you will only have to type it out once, after all).

cheers:~)

Are your states purely encapsulated within your characters, or are they dependant on higher level state changes?

I think that maybe you are confusing the State Pattern with a Finite State Machine.

the State Pattern would control the different states within your characters (walking, running, etc)
a Finite State Machine would control the higher level application states (loading, practice mode, saving).

They could of course both be used together.

I like the switch statement, and abstraction of this method leads to obviscation

if it gets too long, your mediator is overloaded, and i have used this as an indicator in the past.
also, for good practice, your case statements shouldn't contain much code, infact it is best if they refer to class methods, then you don't need local vars, you can cast and pass body and type as method arguments.

the listNotificationIntrests gives you an immediate rundown on framework dependencies too.

cheers:~)