Alcibiade, thank you for your feedback on my initial thread.
You’re right, when the async event is planned, there is nothing to prevent it from happening in my different test cases (like the one you’ve shown).
In my case here’s what I tested :
The yellow container is triggered at intensity 2 and the purple one at intensity 3.
"The not so bad case" : if the game changes state from intensity 1 to intensity 2 at the red spot (1), and changes back to intensity 1 at the blue spot (2), the yellow container will play anyway. In this situation, this is not really critical, you will eventually have 4 measures of intensity 2 playing then going back immediately to intensity 1.
The bad case : if the game changes state from intensity 2 to intensity 3 at the red spot (1), and changes back to intensity 2 at the blue spot (2), the yellow container AND the purple container will play together, which is not good at all ( in my implementation, it’s one or another, not both ).
I’m was changing the structure of the project (before you answered in my initial thread), because having all intensities on the same section has some drawbacks for what I have in mind. Which will solve the bad case scenario.
That said, the not so bad case still stands. I’m pretty sure that the game will not send an intensity change that fast, but if you kinda have OCDs like me, wanting everything to be perfect… you know that in some instances, you could have the music glitching because of this behavior.
So yeah, I’d be curious if this is something we could prevent (or not).
EDIT : I forgot to mention that the containers are conditionals. When the intensity changes, they are enabled or disabled with the trigger behavior setup.
