PlayOneShotAttached gives a "has not had EventInstance.set3DAttributes() called on it yet!" warning and doesn't play the sound


I’ve been having issues with playing a sound using FMODUnity.RuntimeManager.PlayOneShotAttached.
Using this method I often get the following warning, in combination with the sound not playing:

"FMOD Studio: Instance of Event event:/SFX/Destructables/wood_destruction has not had EventInstance.set3DAttributes() called on it yet!
UnityEngine.Debug:LogWarningFormat(String, Object[])
FMODUnity.RuntimeManager:Update() (at Assets/Plugins/FMOD/RuntimeManager.cs:350)
Any idea what might be the cause of this? I have not yet been able to determine the exact cause as this doesn’t seem to be the case in all situations where I use the method.

Additionally I tried changing the function a little bit:
public static void PlayOneShotAttached(Guid guid, GameObject gameObject)
var instance = CreateInstance(guid);
AttachInstanceToGameObject(instance, gameObject.transform, gameObject.GetComponent());
instance.set3DAttributes(FMODUnity.RuntimeUtils.To3DAttributes(gameObject.transform)); //What I added

And that seems to fix the problem but I’m not sure of this is the correct way to work around this or if this would cause any other issues.

Some feedback and help would be greatly appreciated!

Are you sure it is coming from the event created by PlayOneShotAttached?
Could it be coming from somewhere else you are using that event?
I am able to use PlayOneShotAttached without getting that warning.

I am 100% sure as replacing the call with a regular PlayOneShot doesn’t cause the error. And the event that I was using was only being used in 1 location in the project.
I can also use PlayOneShotAttached in most situations but in this case, things break.
I do have to mention though that I’m guessing the problem is being caused by playing an attached one-shot while the object in question gets destroyed later in that same frame due to a chain of events (for example a damage event started the event but also caused the hp to drop far enough to kill the object). (Not confirmed)

It does appear that the object could be destroyed before set3DAttributes is actually being called, which doesn’t actually happen until the next Update.

By adding your change:
To the PlayOneShotAttached function, we can make sure the position is set at the time the event is created, which should solve this problem.

I will get this added for the next public release.

Hi Cameraon,

I went ahead and created 2 GIT pull requests a while back addressing this issue alongside some other performance and usability issues we had encountered. (I also mailed these to you just in case).

For people interested in this or who are running into the same issues for the time being.

There are 2 pull requests:

o Fixed issues with the AttachInstanceToGameObject methods.
This mainly fixes issues when being called via the PlayOneShotAttached
AttachInstanceToGameObject now directly sets the 3dAttribute while attaching
to ensure an initial correct and valid 3d positioning is applied.
Before a 3d position would only by applied to the instance in the next
update after the attach occured.
This can cause unexpected and unwanted results in case the target transform
was destroyed between the attach and the update loop.

Example: A crate that plays a PlayOneShotAttached when it hits a surface but
that also takes damage at the same time that can result in a destroy. The
sound would play at the incorrect location as there was never an initial
position set that matched the desired start position. This small change will
fix this.

Also added a small change to the way the DebugOverlay is being activated and
rendered removing a Garbage Collection overhead in both editor and
standalone builds, even if the overlay was not enabled.
Before, even just having an OnGUI method in your component would trigger the
Unity legacy UI system to be running causing a performance overhead, even if
nothing is being drawn as well as an occasional garbage allocation.
This is now only the case if the debug overlay is enabled, removing all the
overhead that was being created when the debug overlay is disabled.

o Added some safety code to ensure emitters are nicely cleaned up on
destroy. Not sure if this was really needed but we did notice some
inconsistency with the event instance clean-ups. This small addition would
ensure a correct cleanup of the sound event instance when dealing with
Added the ability to SetParameter by index instead of string. (A usability

(Apologies for this commit being somewhat strange with the addition of the changes that where then
reverted out of this branch. This was mainly to allow for these changes to
be available as a standalone pull request. I haven’t used github before so I
was unsure on how to resolve this in a more clean way.)

I hope these will be of help to some people

1 Like