Unity StudioEventEmitter - Set Initial Parameter Values via Inspector is not working

Hi, I’ve got a problem.
Whenever I set initial values for a Studio Event Emitter through the Inspector in Unity, the values just reset to their default values when the game starts playing. What’s more, after exiting Play mode they are still stuck at their default values, ie. it just completely ignores the values I’ve entered and resets the component to its default state.

I have no code which is affecting the volumeOverride-parameter. I’ve also tested disabling the code that was driving the velocity-parameter, yet the issue persisted.

Any idea as to why this would be happening?

Here’s a GIF of it happening:
Fmod StudioEventEmitter Initial Values are not set

Here are my specs:
Unity Version: 2018.4.11f1
Fmod Version: 1.10.15

Ok, this is weird. It seems to be an issue with if the object with the StudioEventEmitter on is a Prefab or not.

  • If it’s a Prefab, then it will reset to whatever value was set in the prefab.
  • If it’s a “normal” game object, it will work as expected.

Maybe it has something to do with the new prefab system which was introduced in like Unity 2018.1 (or something), and that the Editor script for the StudioEventEmitter doesn’t handle the changes to the prefab system correctly?

Here’s a GIF of my test:

When you open the Overides drop-down window, are the changes you’ve made to specific prefab instances listed as overrides?

@joseph yes, they are listed as overrides, but there’s more to the bug.

I think I have found the pattern of the bug:

  1. Activate parameter override (activate the bool) AND apply to prefab (just the bool for simplicity)
  2. Play → override is still active
  3. DeActivate the override WITHOUT applying to prefab
  4. Activate the override again WITHOUT applying to prefab
  5. Play → override becomes DeActivated and thus removes any values you’ve set.
    This is also registered as a change on the instance, which is bad cause the user can accidentally apply completely wrong settings to the prefab.

See the GIF:

So for me to be able to actually add overrides to the instances of a prefab I need to mark that parameter as “overrideable” beforehand IN the prefab. That way it will keep its “overriden”-status, and thus not reset my override-values.

But if I for some reason would turn off the override, and later change my mind and turn it on again “manually” (ie. without reverting to the prefab default values), then it will completely ignore the override I have applied and just reset it back to “not overriden”-status - which also sets the initial parameter value back to 0f, regardless of what it was before. And this just makes it seem like the ParameterOverride variables don’t work.

So in conclusion @joseph, I don’t know what’s causing the bug, but my guess is that it’s something in how the CustomEditor-script for the StudioEventEmitter draws and applies values to those ParameterOverride variables. Those variables seem to be the only ones having this issue, cause neither the OverrideAttenuation nor any of the variables in the Advanced Controls-dropdown have this issue.

Also, the ParameterOverride variables don’t get the blue line at the left nor the bold text that let’s you know that you have made an override of that variable on that prefab instance (see picture below). Neither does the OverrideAttenuation-variable get those, but that doesn’t seem to be a problem for that one - although you can’t right click on it and apply just that one override to the prefab, as opposed to applying ALL the overrides at once (which you may not want to do).

Picture of Prefab Instance variable overrides:

Thanks for the detailed bug report. I’ve added this issue to our bug tracker.

My apologies for not replying to your post earlier. I thought I had, but I was mistaken.

No worries. Keep me posted on this please, I’d like to see what the solution is.


Heyoo, any updates on this?

A fix for this issue was included in a recent release the FMOD Unity integration. If you’re using FMOD Studio version 2.00.xx, you’ll find the fix in version 2.00.12; if you’re using 2.01.xx, you’ll find it in version 2.01.04.

1 Like

Cool, thanks for the reply!