FMODStudioSettings.asset keeps appearing in version control with no changes

FMODStudioSettings.asset has become a meme for some of our team members. Unity checks it out in Plastic SCM without any visible changes and it’s part of some peoples’ workflows to manually discard it when switching branches or when just trying to keep their pending changes clean.

I saw this has been reported by others before. It’s happened fairly consistently with each version of FMOD Unity we’ve used, I think? At least with 2.02.01 and 2.02.04.

In the past we’ve experimented with hiding FMODStudioSettings.asset from Plastic but to no success. I tried looking at the FMOD Unity plugin and I think the checkout happens because the Settings scriptable object is being cleared and re-populated with the same data? So it’s just the timestamp that’s changed.

Thanks!!

FMOD 2.02.04
Unity 2020.3.7f1
Plastic SCM 10.0.16.6621
Windows 10

Hello again, I can see FMODStudioSettings.asset is a point of contention for your team!
The default behaviour of Plastic SCM is to include timestamps as a “Changed” criteria. You can disable this in Plastic SCM by going Preferences>Other options>Check content (hash) when the file timestamp is modified to set it as “Changed”
Please give that shot and let me know if you are still seeing unneccssary changes to FMODStudioSettings.asset

Thanks, we’ve tried a few different things with Plastic, we’ll see if this works.

We’ve had these three options checked for a long time but they don’t seem to affect FMODStudioSettings.asset or a couple others like QualitySettings.asset. We experimented toggling them and found that #2 and #3 are the same underlying option (they turn on/off together):

Pending Changes > What to find:
1) Find changed files in the workspace
2) Check the content to determine files as changed, not just timestamp

Preferences > Other options:
3) Check content (hash) when the file timestamp is modified to set it as "Changed"

I have Pending Changes > What to find > Show checkouts on since I like seeing if I’m blocking anyone. If I uncheck it then FMODStudioSettings.asset goes away but I still get an error about pending changes for it if I try to switch branches.

Maybe there is a third element besides its content and timestamp that is the cause, associated with how Unity sets the file dirty? Unity shouldn’t check it out unless it’s saved (via Ctrl+S) with more changes than just the timestamp?

These two posts are similar to our problem. Given that it’s not just Plastic SCM, is it likely that a Unity upgrade could affect this? If so then this is something we could fix ourselves at some point.

Thanks again.

It looks like the settings asset is being marked dirty every time the editor reopens. I have created a task for the dev team to fix this in a future release. In the meantime, you can workaround this by modifying the StagingSystem.Startup method in “Assets/Plugins/FMOD/src/Editor/EditorUtils.cs”:

// EditorUtils.cs StagingSystem.Startup (~line1495)
public static UpdateStep Startup()
{
    if (!AssetDatabase.IsValidFolder(StagingFolder))
    {
        // START CHANGE
        if (Settings.Instance.SharedLibraryUpdateStage != Settings.SharedLibraryUpdateStages.Start
            || Settings.Instance.SharedLibraryTimeSinceStart != 0)
        {
            ResetUpdateStage();
        }
        // END CHANGE
        return null;
    }
...
}

Thank you for flagging this issue!

1 Like

Initial tests are looking good! We’ll continue keeping an eye on this for a few days and come back if there’s an issue. Thanks!!

2 Likes