Custom inspector saving project wide settings into the Library folder

Unity Editor Editor Extensions
1

I’m making a system which makes use of a custom Editor. It specifically needs to set up some data that can be used between multiple scenes.

I can think of several ways of achieving this, but the best way to me looks like the way the Project Settings are done - custom inspectors, which save their configuration into serialized version of their settings classes, in the Library folder.

I have built a custom Editor, attached it to the inspector via a menu button, and can of course detect if a settings class instance has been attached to it yet or not.

I also have a settings class which extends ScriptableObject and has the [Serializable] attribute defined.

I have tried using AssetDatabase.CreateAsset and AssetDatabase.LoadAsset<>, but it seems when you point these at the Library folder it fails with the message “Couldn’t create asset file!”

Is this a sensible approach for this problem?
… if so,
Is there a way of using the AssetDatabase Create and Load methods on the Library folder?
At what point do I save the settings files, or is this taken care of once linked?

Thanks.

I’m currently doing this into the Assets folder instead, code follows:

namespace FlowEngine.Editor
{
    using UnityEditor;
    using UnityEngine;
    using UnityEngineEditor = UnityEditor.Editor;

    [CustomEditor(typeof(FlowEngineSettings))]
    public class FlowEngineSettingsEditor : UnityEngineEditor
    {
        private const string settingsPath = "Assets/Settings/FlowEngineSettings.asset";

        [MenuItem("FlowEngine/Edit Settings")]
        public static void Getter()
        {
            if (FlowEngineSettings.Current == null)
            {
                FlowEngineSettings.Current = AssetDatabase.LoadAssetAtPath<FlowEngineSettings>(FlowEngineSettingsEditor.settingsPath);
            }

            if (FlowEngineSettings.Current == null)
            {
                FlowEngineSettings settings = ScriptableObject.CreateInstance<FlowEngineSettings>();
                FlowEngineSettings.Current = settings;
                AssetDatabase.CreateAsset(settings, FlowEngineSettingsEditor.settingsPath);
                AssetDatabase.SaveAssets();
            }

            if (FlowEngineSettings.Current == null)
            {
                Debug.LogError("[FlowEngine] Could not load or create settings file.");
            }

            Selection.activeObject = FlowEngineSettings.Current;
        }

        public override void OnInspectorGUI()
        {
            this.DrawDefaultInspector();
        }
    }
}
1 Like
2

If you are using source control (and why are you not?) then you should be enabling visible meta files, and NOT source-controlling the Library folder at all.

Therefore, you would never put assets in Library because a) they are not source controlled, and b) if you switch platforms, Unity tends to clear out the Library folder.

Rather you should make them some kind of an asset file, such as perhaps a ScriptableObject and source-control them directly in your main Assets folder.

3

Yeah, all under version control, and that’s what the attached code is currently doing, storing a .asset file in Assets/Settings.

I don’t think I’ve understood what Library does/is then - it is currently under version control for one. So if I switch platforms and back, do the project settings reset? It looks like some of the files in there really should be persistent.

4

Sounds like you aren’t quite version controlling properly, so you’re making your repo a LOT larger than it needs to be.

Never to late to fix: Google first for “how to version control unity” and enable visible meta files, put those under source control too, and then when that noise settles down, delete and commit your Library folder.

I have been version-controlling Unity since 3.3 and you absolutely do not version control Library or Temp subfolders if you have visible meta files enabled and source controlled.

While you’re in there (Edit->Project Settings → Editor) you should enable Force Text mode, so you can SEE what changes in your .unity files and not make needless commits with trivial or even incorrect changes. It is a shame that Unity marks files as binary by default rather than as text.

5

Cheers - looks like I was mistaken in the end anyway, I do have Library already blocked! Still kind of confused why the project settings are stored there if the folder is effectively temp though…

I’m using this for my ignore.conf:

/Library
/Build
/Temp
/obj
/*.csproj
/*.unityproj
/*.sln
/*.suo
/*.userprefs
/.vs
output_log.txt

Currently I’m finding team work on the scenes is a bit of a nightmare what with the whole ‘binary blob’ thing - I assume text serialized scene files help with that? Even with text serialization on, can you safely merge files?

6

I would not personally attempt merging YAML (that’s the text format, mostly) changes, however, you can seriously cut down on the number of silly changes in your project simply because you can SEE what the proposed difference is without having to blindly commit it.

This is why Unity should make force text mode the default: Never again will you say “Hm… I didn’t think I changed the scene file… ah well, I better commit it anyway,” and then you made a commit with absolutely NO IDEA what actually changed in that file. At least with trivial scene changes you can eyeball the diffs before committing, which every developer should be doing, or else they are setting themselves up for “Well, we’re not really sure when that button stopped working properly…” conversations.