Hi,
I faced this issue, but for something else than pausing, but the solutions are very similar.
basically a delayed event will fire even if you leave the state you fired it from, which can be seen as a bug, but it's actually by design.
the way to go about it is to not used the built in delay but rather implement your own timer solution, using a float and the current time, etc etc it's involving but it works. so when pausing, you kill the process and only retain the current elapsed time, when unpausing, you resume the timer and start counting from that elapsed time.
So,
1: Interested to know what you came up with
2: I don't think you can "hold" events, you will need to explicitly design your fsm to accomodate this. I do that on many occasion, it simply means maintaining a game "context" that when the fsm must comply too at key states, so for example pausing would mean calling a specific state and record here the current status of this fsm, maybe a variable or the last active state, and when unpausing, again a specific state that will resume this fsm.
This is tedious. I also implement another method which requires a fsm to ONLY have one starting point, and goes through all the required statements and checks to know where it should carry on what it was doing. This is difficult to put in place but extremely rewarding in terms of flexibility.
3: Yes, you could have a global var called "paused" and on key states first check if the game is paused or not, but that is going to bloat your fsm with a lot of redundant states and checks, which will in the long run make it difficult to edit, change the behavior globally etc etc,
Bye,
Jean
