Would it be possible to remove string Path from EventReference?
Storing this path seems to add a whole bunch of confusion/overhead using this scanner tool, but really all we need is a GUID to get the path from FMOD build (for display) or play the audio (at runtime).
I see it’s guarded behind UNITY_EDITOR right now. It would be amazing if we could just get rid of this needless functionality entirely and instead rely on the FMOD project to map the GUID to its path in the inspector.
Would it be possible to add something like:
#if UNITY_EDITOR && !FMOD_DISABLE_EVENT_PATHS
public string Path;
And use that same flag to completely remove the scan tool from the project too?
Ideally Path would just be removed entirely, but I’m assuming it’s there for some reason.
Real-world illustration of problem
What we have now:
Audio person renames events in FMOD studio.
Audio person opens Unity and runs the scanner tool.
Pull request is made.
Other team members commit changes that reference existing (but renamed) events – theoretically no problem here.
Pull request is merged (updating master and forcing these new event references to immediately be stale).
Every person on team opens Unity and gets prompted to open the scanner tool resulting in confusion.
Step 2 is unnecessary.
Step 6 causes delays, duplicated work (scan tool × team size), extra communication “why is this thing opening when I start unity?”, extra training re: FMOD to e.g. artists, designer etc.
Just to bang on about it a bit more… This morning I rebased audio guy’s PR to avoid aforementioned problem. I re-ran the scan tool to sync up the redundant Path fields to make sure nobody would would get prompted to scan… Now I’m getting this message from team mate:
The only reason to run the tool is so that it doesn’t prompt you to run it next time, and even that is not working as expected.
You make a compelling argument; artists and designers shouldn’t have to learn about FMOD every time someone changes the name of an event.
I think we should be able to remove the Path property from EventReferences, and instead display a cached value from somewhere else. With that, we can update the cached values when banks reload, and allow Path to be a reflection of the centralized data without the need to manually run the EventReferenceUpdater just to ensure the string value stays up to date.
I have passed on your suggestion to the Dev team, thank you for bringing this to our attention!
Thanks for taking the time to read my suggestion @jeff_fmod. Happy to hear I wasn’t missing something.
With that, we can update the cached values when banks reload, and allow Path to be a reflection of the centralized data without the need to manually run the EventReferenceUpdater just to ensure the string value stays up to date.
I think you basically just need the EventReference drawer to call RuntimeManager.GetEventDescription to get the value to show, and when the value changes it can call RuntimeManager.PathToGUID(string path) to set the actual value (although setting the value is usually done via the dropdown anyway, you probably may not need a text input at all).
In the case the bank isn’t loaded or doesn’t exist (or whatever error) just replace the entire property drawer with a warning message telling the user rebuild/configure FMOD.
It would be a little more complex than that, just because the RuntimeManager as it stands can’t be used inside Editor-only code. We have a separate FMOD.Studio.System for use in-Editor (EditorUtils), so we would need to implement equivalent methods in that I think.
In any case, it should be doable, and would be better than the current situation.
True, well I’m sure you know how to do it. The EventReferenceDrawer is already querying the cache for the event path to print a warning about a mismatched path.
Any news about this fix? I have the same issue with my team… every time I rename events + scan / execute event references, they spam me about the fmod window
