Fantastic! Thanks.
What I had in mind with this action is to preload some results, like some produce that a FSM is going to generate based on some numerous operations and calculations that can create spikes in CPU/GPU usage. Instead of eating up some 120 ms of calculations for example, it's possible to spread it over 4 frames that only eat 30 ms each.
So in CPU intensive loops that involve one or more FSMs that at some point validate phases with events, controlling the delay (by remote for example, notably through a Global int var) helps spread certain processes over several frames, this ahead of the moment the final "produce" (whatever the app does that's BIG).
If the device is weak (low entry smartphone) and/or if the FPS rate drops too much, the delay can be changed from 0 to 1 in certains FSMs so as to spread calculations over several frames, either exceptionally or continuously. This provides a dynamic way to manage the density of processes during x number of frames.
This special send event action needs to be placed at several key potential bottlenecks.
This is solely for optimization.