However, if I first declare an eventReference variable and try to reference it in PlayOneShot function as below, it doesn’t play any sound and I get a warning in the unity console.
This is what I wan’t to do (let’s say I want to play the sound on start):
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using FMODUnity;
public class PickupToCargo : MonoBehaviour, ISpawnable
{
public CargoContent cargoContent;
public float amount = 0.2f;
CargoHold targetContainer;
public float timeToPickup = 0.5f;
UICountdown currentCounter;
public delegate void OnPickup();
public OnPickup onPickup;
public bool spawnRandomRotation = true;
public bool shouldDespawn;
// Audio
[SerializeField] private EventReference cheeseCollectedSound;
private void Start()
{
FMODUnity.RuntimeManager.PlayOneShot(cheeseCollectedSound);
}
}
Instead of playing a sound, I get the following errors in console:
“[FMOD] ObjectLookup::get : Lookup failed for EventModel: {00000000-0000-0000-0000-000000000000}”
and
“[FMOD] Event not found: {00000000-0000-0000-0000-000000000000} ()
UnityEngine.Debug:LogWarning (object)”
Do you have any idea what is wrong, or what I am doing wrong?
Hi,
What version of the FMOD integration are you using?
Based on the error messages, the issue could be caused by the event reference settings in the inspector.
Could I please get a screenshot of your Unity project’s Event Reference? The ‘Cheese Collected Sound’ reference can be set either by typing in the event’s path or by using the magnifying glass.
Good news! I loaded another scene, and then it started working. Now it also works in the original scene.
Just to answer your questions however:
I had already chosen the event in the inspector. Even though I could see the event in the inspector, it still gave me the message that the event wasn’t found.
I thought the versions of FMOD Studio and FMOD for Unity were the exact same. Now that I double check, I can see that I am using FMOD Studio version 2.02.22 and FMOD for Unity version 2.02.21. I didn’t notice because it showed 2.02 and 2.02 in the highlights on the download page.
I don’t know if that could be an issue further down the line, or if it isn’t a problem. For the moment it seems to be working as intended. Would you suggest I change one?
Good to hear it is solved, and thank you for sharing the solution!
Different minor versions are fine, e.g. 2.02.XX, as these mainly contain bug fixes and smaller workflow improvements. You can read more about the versioning here: FMOD Studio | Glossary - Version
Changing versions close to release, either minor or major, is not recommended.
Actually, i still get a similar warning when I store the event using FMODUnity.EventReference and try to use it when creating a new instance of an event. The sound does play, but for some reason i get the following errors:
I came across the same issue today, and as DanielClifton suggested, this seems to have something to do with FMODUnity.EventReference and the way it is serialized in the UnityEditor.
in the editor, there was some problem when setting the event’s path :
I could search and select the event to reference (with the magnifying glass icon) but when clicking it, no path got written in the editor field. I worked around this by selecting the event through the “folder” icon and dragging it in the field (manually typing the event path works too), but then got the errors mentioned in the first post when testing in game.
What seemed to fix the issue :
Simply changing the EventReference from private to public seemed to work :
public EventReference mySound; RuntimeManager.PlayOneShot(mySound);
From there, referencing the event with the magnifying glass icon worked properly and everything worked fine in game. Afterwards, I could even change the reference back to private and it still worked.
So yeah, this seems to be a problem with the way FMODUnity serializes EventReference when they are privates. However, I tried to methodically reproduce this bug after writing this post and couldn’t properly do it… maybe other factors are coming into account for the issue, but I don’t know which ones.
Thank you for sharing your workaround and the additional information!
I have not been able to reproduce this on my end either.
In principle, [SerializeField] private EventReference should be valid, so changing it to public should not normally be required. The fact that this caused the picker to start writing the reference correctly makes this look like an editor/serialized-state issue.
If you manage to reproduce it consistently, could you please share your Unity version, FMOD Unity integration version?
So the issue came back today!
This time my EventReference was public, and changing it to [SerializeField] private (or the opposite, private to public) didn’t help.
The precise steps to reproduce are still unclear though… not shure if that is relevant, but I was trying to serialize an event in a ScriptableObject. When trying to reproduce the issue on a classic MonoBehaviour script, the serialization seemed to work just fine.
My Unity version is 6000.3.8f1, and my FMOD integration version is 2.03.13
I have tested this using Unity 6000.3.8f1 and FMOD Unity integration 2.03.13 with an EventReference serialized in a ScriptableObject, but I have not been able to reproduce the issue so far.
Could you please share the ScriptableObject class containing the EventReference field? It would also be useful to know whether you are using Unity’s default Inspector or any custom editor/property drawer.
As a quick check, when the issue occurs, does selecting FMOD > Refresh Banks in Unity make any difference?
The problem persists even after selecting FMOD > Refresh Banks.
To answer your questions, we’re using the plugin Odin Inspector which might be a part of the issue. The variables are contained in a serialized interface instance handled by Odin Inspector. This interface instance is itself stored inside a SerializedScriptableObject (Odin’s extension of Unity’s standard ScriptableObject).
A minimal version of our code looks like this :
public class MiniGameData : SerializedScriptableObject
{
public LocalizedString Name;
public EventReference MusicalTheme; //This field is working properly
public IMiniGameSettings Settings;
}
public class MiniGameASettings : IMiniGameSettings
{
public EventReference correctAnswerSFX;
public EventReference wrongAnswerSFX;
// These two SFX fields cannot be changed in the Inspector.
// The FMOD event selection window opens correctly, but after selecting an event, the field value does not update.
}
Aditionnaly, I got some precious help from a programmer in my team who reported the following :
I did some debugging on my side and found that SetEvent() in EventRefDrawer.cs is being called correctly.
Specifically, the following method is executed when I select an FMOD event:
The SerializedProperty is found correctly, and the selected event’s GUID is properly assigned to it. I verified this in the debugger, and the GUID value is indeed present in the property immediately after the selection.
However, at some point afterward, when the value is read again to draw the field in the Inspector, it has been reset to null/empty. I followed the execution flow as far as I could with Visual Studio and couldn’t find anything suspicious after the event selection. As far as I can tell, the GUID is successfully written to the SerializedProperty, but the value does not persist and is lost before the field is rendered again.
Thank you again for the detailed reproduction information.
I have been able to reproduce the issue and confirmed that it occurs when the EventReference is nested inside an interface value serialized by Odin. The equivalent setup using Unity’s native SerializeReference works correctly.
Since Odin is responsible for serializing the interface value in this setup, could you please also raise this with Odin support? They may be able to clarify why the value written through Unity’s SerializedProperty is not retained when the Odin-managed property is redrawn.
Please feel free to share any findings from their side here, as they may help determine whether any change is required on the FMOD side.
I joined Odin’s discord community and found some people with the same problem. Someone even created a custom editor tool to work around the issue and solve it !
I’m sharing the tool here, so maybe you can check if something can be done to natively prevent the issue? If anything has to be fixed on Odin’s side, I can try to transmit.
We reviewed both implementations. Even the smaller “Basic” workaround relies on Odin-specific APIs to copy the value from Odin’s temporary serialized object back into its own ValueEntry.
FMOD’s EventReference drawer works through Unity’s standard SerializedProperty system, and we would not be able to incorporate this workaround directly without adding and maintaining an Odin-specific integration.
For now, the workaround you found appears to be the most practical option for this Odin serialization setup. It may also be worth reporting this behaviour to Odin support, as the value appears to be lost when it is passed back into Odin’s serialization system.
Thanks again for taking the time to investigate this and for sharing the workaround.
