Can Command Instruments not be fired while an event is running, if they were turned off when the event was instantiated/played?
Scenario:
1.) I have a looping music event. For reasons, it has Command Instruments set up every beat on a 2nd audio track to start another event under the condition that a labelled parameter has the value of “On” (value possibilities are only “On” or “Off”).
2.) If this event is started with the parameter value “On”, the first command instrument works and starts the other event.
3.) If this event is started with the parameter value “Off”, turning the value to “On” while the event is playing does not end up activating any of the Command Instruments.
What are the scenarios under which this is intended behavior, as far as FMOD is concerned? What could potentially be the cause of this, without more information?
The situation you describe should only occur if the event stops before the parameter’s value changes from “Off” to “On.” This could potentially occur at any time if the event is not set to be persistent and reaches a natural end.
If the event is reaching a natural end, setting it to be persistent should solve the problem - though you’ll need to ensure the event instance is stopped by your game’s code when it is no longer needed.
I can confirm that I’m not stopping the event at all after changing the parameter, and I’m actually letting it run for some time after (all in FMOD Studio only).
What about in the case of a nested event? It seems to happen most when that logic is inside a nested event. I’m changing the parameter from Off to On while viewing the parent event.
Even if you’re not stopping the event, it’s possible that the event is stopping itself when it reaches its natural end, as I mentioned above. Have you tried setting the event to persistent mode, to see if that changes the behavior?
If you select the event instrument and look at the knob for the parameter that appears in the deck, is there a hollow circle icon next to that knob, a filled dot icon, or no icon?
Is the parameter set to “hold value during playback” mode? If so, that would explain why changes to its value are being ignored in event instances that make use of it.
I tried setting the event to persistent mode, and that didn’t change anything.
The parameter that appears in the deck, when selecting the event instrument, has no icon next to it.
The parameter does not have “hold value during playback” selected. Just in case, I toggled this setting on just to see if anything changed, but unfortunately none of these solutions have worked, in the case of a nested event.
I’ve tested a lot of different things now, and I guess one important thing that’s not happening in versions 2.02.07 - 2.02.20 is that Command instruments are being completely ignored in child events, aka an Event Instruments.
I can’t reproduce this. When I test it here using FMOD Studio version 2.02.20, a “start event” command instrument in a nested event successfully spawns an instance of its associated event when the parent event plays an instance of the nested event. It works even when the command instrument has a parameter trigger condition that is not initially met when the nested event is triggered but becomes met shortly afterwards.
Could you send us screenshots of the command instrument’s settings in the deck, and the structure of the parent event and nested event? Or better yet, upload a copy of your project so that we can examine it in detail? There must be some detail of your set-up that differs from our test cases; if we can identify that difference, we should be able to identify the cause of this issue and how to fix it.
Ok. I’ll attempt to send you something soon. Maybe try this in the meantime? Not sure, but I thiiiiiiiiiiink this happened after applying an AHDSR to the Master Track volume of one of the Events, even after that modulation had been removed. Can’t remember if it was Parent or Child. Can you try reproducing it, but then add an AHDSR to the Master volume of each event, then remove them, and test again? Just in case?
I tried adding and removing AHDSR modulators to all three events, and the command instrument still spawned an instance of its target event without problems.
That being said, if the nested event still has an AHDSR modulator on one of its properties right now, that could potentially explain the behaviour you’re seeing.
When an event instrument is triggered, it spawns an instance of the associated nested or referenced event; this instance then continues playing until it reaches a natural end. However, if the event instance has defined stopping behavior, then it will begin that behavior as soon as the event instrument is untriggered - and putting an AHDSR modulator on one of an event’s properties is one of two possible ways to give stopping behavior to an event.
Thus, if the nested event has an AHDSR modulator on one of its properties, and the release period of that AHDSR modulator is shorter than the time that elapses between the event instrument being untriggered in the parent event and the command instrument being triggered in the nested event, the nested event’s instance is actually stopping before it gets a chance to trigger the command instrument.
I can’t be certain that’s the cause, of course. If there is no AHDSR modulator, or if the longest release period of such an AHDSR modulator is longer than the period that elapses between the event instrument being untriggered and the command instrument being triggered, or if the event instrument isn’t being untriggered, it won’t actually apply, and the behavior you’re seeing must have some other cause. It’s probably worth checking, though.