[Cross-posted from the FMOD Ex forum, since I think it fits better here]
I recently upgraded from FMOD Ex 4.07.18 to 4.08.04, and now I’m seeing some confusing behavior while muting the master EventCategory. At the beginning of my app, I read a "mute all" flag from our configuration file and then call setMute(muteAllFlag) on the master EventCategory. Then I have an in-game checkbox to enable/disable the master category mute at runtime.
If the "mute all" flag is false, everything works fine. However, if the "mute all" flag is true, then everything seems to be permanently muted, even if setMute(false) is subsequently called on the master category. Further investigation with getMute() reveals that the master category’s mute state is always correctly toggling, but the individual audio events’ mute states are only toggling correctly if the "mute all" flag is false. If "mute all" is true, then the individual events always return true from getMute().
Looking through the version history, I see that the pause/mute logic for categories was changed in 4.08.00. Could this change have caused unexpected side effects?
- cort asked 11 years ago
We did just change the mute/pause behaviour in the upcoming version again. Look out for it on thursday it will be 4.08.06.
This time nested channelgroups will not be overwritten by their parent, every channelgroup gets its own state, and the low level channels just check every time to see if its parents/grandparents etc are muted or paused to work out what it should be doing.
I just tried linking against the new 4.08.06 version, and I’m afraid it made no difference as far as this setMute() bug is concerned. I didn’t see anything in the release notes about event categories either — did the fix you mentioned really make it in?
- cort answered 11 years ago
Okay, I whipped up a quick example program and .FDP that demonstrates the problem. The archive is available at [url:2xhcqobj]http://www.dangerware.org/fmodbug.zip[/url:2xhcqobj]. Instructions for building and running are in the include README.txt.
Thanks for that. Looks like the channelgroup/mute heirarchy stuff is working fine, but the event itself had its state set to mute (ie you could have called getMute to see that it was set to true). This looks like some old hangover from a previous version, i’ve removed it for future versions so that it works properly.
In the meantime you can call event->setMute(false) after getEvent to overwrite that error.
Please login first to submit.