Just a quick one here. I'm in a situation where Next Frame Event is sometimes quite useful if only to synchronize various FSMs. That's perhaps one of the most practical solutions I can rely until we can have some kind of metaFSM overseer.
The thing is, I have some actions that do tests or check for other conditions upon which they may send events. Typically, boolean verifications, but it's certainly not limited to them (although the tests tend to be very binary most of the time).
I do not wish to bloat my FSMs with intermediary states that will just force a frame delay (or a waiter of any type), nor do I wish to force an Action Sequence in whatever following states come next in the chain, most certainly because it would break this state's internal logic.
So, with the ability to use relayed events inside a state, I could use such a relayed event in a Bool Test action: for example for the True condition, instead of defining an event directly, I would actually pick an event tagged as "relayed" that is actually sent by another action later in the state.
On a similar setup, the Next Frame Event could be made to actually relay any event sent by a targeted earlier action inside the state. So reusing my above example, whether it's the event for True or False, Next Frame Event would simply pick it up and send it.
It's even possible that it would allow actions to communicate, and combine, by sharing such events, and perhaps creating a chain wherein one action that fails or disagrees would actually block the event chain and stop it from being sent.
This essentially making such linked actions act as IF systems.
This is however a complicated revision and for the time being it would be simpler to do duplicates of every action I wish to use in this manner and cram a x frame(s) delay there, for example in the Bool Multi Condition action or the Conditional Expression one too. It's a very rushed idea and I'm not sure how useful it would or if it has potential for something bigger.
