One thing that would be great would be the ability to nest event actions together to circumvent some issues with how event actions are currently evaluated.
For example, let's say I have a loop called "vfx_sparking" and these tend to play together in game in close proximity.
Regardless of how many variations I have, I optimally would want to add both a randomized delay (say 0-200ms) and a randomized seek percent to these loops.
With the tools currently available (and correct me if I'm wrong) - seek actions do not work if the play action is calling a sound with an initial delay.
The seek happens, but the event isn't playing, so it always plays from the start.
I could randomize the delay on the Play action itself, but I would also need to do the same on the Seek action - which could result in the seek not working.
If we had the ability however to nest both the Play and Seek actions in an action which I could delay, it would solve the problem.
It would also help with organize events which contain a number of actions on multiple sound containers by grouping them.
Am I completely missing something? We've needed to implement a randomized initial delay on the engine side to mitigate this. Seek is the only option for offsetting playback location, and with issues like placing Seek before Play also not working, or the issues with "Seek to Nearest Marker" (see my other post from today) - there are a number of gotchas designers need to look out for when trying to use the behavior.