Hi,
I don't think the api expose any ability to extend and modify the current transition behavior.
A transition has one event only, you can wire two transitions to go to the same state, that's fine.
In your case, I think you need to create more states, one that will transit under the "ALLOW ATTACK 2" to a state listening then to the attack button and would fire the "ATTACK BUTTON" event when pressed.
This is a very common practice, nothing wrong in cutting down the task into several state to really define the process and flow.
Checking for invincibility would simply require a third state inserted anywhere in your flow.
another variant would be to store all these states in boolean variables, and use the action found under the logic category like "bool all true" and list all them bool ( you would actually define invicible as the opposite, for example "vulnerable" so that the "all" true check passes)
However I would recommend the first solution, because visually it is clear and you can very easily insert more and more checks and let your system grow in complexity easily. Make use of generic events such as "YES" "NO" "TRUE" "FALSE" or similar and name your state. you will find that you can describe complex flow with a limited number of events ( instead of having specific events for each statements)
I have attached a dummy fsm showing the kind of possible flow. the global transition "ATTACK" would be fired by a fsm listening the the attack button, or you could just plug that to the button itself and listen the "MOUSE UP" or else.
bye,
Jean
