SettingsManager package: Project Settings vs User Prefs?

I’m exploring usage of the SettingsManager package 2.0.1. Everything works fine and I managed to implement settings as well as user prefs.
The issue is, I see both in both windows! Say I have 2 values I want to show in Project Settings, and 2 that I want to be located in User Preferences, I cannot seem to separate them and I see all 4 in both windows.

I have a manager like this:

static class SettingsManager
{
    internal const string k_PackageName = "com.ciro.my-package";

    private static Settings s_instance;

    internal static Settings instance
    {
        get
        {
            if (s_instance == null)
                s_instance = new Settings(k_PackageName);

            return s_instance;
        }
    }
}

and a provider like this:

static class SettingsProvider
{
    const string PreferencesPath = "Preferences/My preferences";
    const string SettingsPath = "Project/My Project Settings";

    [SettingsProvider]
    static SettingsProvider CreateSettingsProvider()
    {
        var provider = new UserSettingsProvider(SettingsPath,
            SettingsManager.settings,
            new [] { typeof(SettingsProvider).Assembly }, SettingsScope.Project);

        return provider;
    }
       
    [SettingsProvider]
    static SettingsProvider CreatePreferencesProvider()
    {
        var provider = new UserSettingsProvider(PreferencesPath,
            SettingsManager.settings,
            new [] { typeof(SettingsProvider).Assembly }, SettingsScope.User);

        return provider;
    }
}

I created a wrapper (actually two) as suggested in the docs:

class PackageSetting<T> : UserSetting<T>
{
    public PackageSetting(string key, T value)
        : base(SettingsManager.settings, key, value, SettingsScope.Project) { }
}

class UserPref<T> : UserSetting<T>
{
    public UserPref(string key, T value)
        : base(SettingsManager.userPrefs, key, value, SettingsScope.User) { }
}

Finally I declare my settings and user prefs like this:

[UserSetting("Category X", "Auth token", "")]
private static UserPref<string> authToken
    = new UserPref<string>("prefs.authToken", "");

[UserSetting("Category 1", "Org name", "")]
private static PackageSetting<string> orgName
    = new PackageSetting<string>("prefs.orgName", "");

But even though I’m providing different SettingsScope, it seems like they are ignored? I know that one of the parameter of the settings provider is the assembly in which to look for UserSetting attributes and one solution might be to “hide” Settings and Prefs in two different assemblies, but it feels convoluted.

Am I doing something wrong? - Thanks

Still curious to know about this. Does anyone have any idea?

I haven’t used this package but simply from reading the docs:

“The Settings Manager is a framework that lets you convert any serializable field into a setting, including a pre-built settings interface”

…that just makes me think it is combining two (or maybe three?) things that really have no real reason to be combined.

  • serialized authored fields
  • preferences written to persistent storage
  • in-game configuration (a flavor of serialized authored data)

There’s a world of difference between authored pre-made information in your scene and runtime-persisted settings.

Perhaps I am misunderstanding it. I’m open to that because I’m going just off a skim of the docs.

But if you need to persist stuff (settings etc), just do it via any one of the ten million existing ways, would be my suggestion.

It’s really just about giving you a way to show things in your Project Settings window, and have some form of data permanence.

Pretty useful when you have configuration assets such as scriptable object singletons. No need to make an interface for them all when Unity provides it.

I haven’t used the package mind you, though I have used the [SettingsProvider] attribute plenty on its own and haven’t experienced this issue.

Gonna go out on a limb and say probably a bug that needs reporting? I will take a look at this package tonight though; seem useful.

Well, I need to store settings for the developer, not for the player. So I’d rather do it in a “very official way” so that they become more future-proof, and this package seems the way to go!

And for the kind of stuff I need to save, yes it’s Preferences and Project Settings, but… sound like the same kind of things to me? The way I see it the Project Settings are stored in the project’s assets, and thus can be versioned, while the Preferences are on the user level, so they are stored outside of the project and stay unique.

Other than that they sound pretty similar to me, which is why I thought the package would just figure it out - a belief supported by the existence of that parameter of type SettingsScope (SettingsScope.Project and SettingsScope.User).

I am so confused as to why there is a package but also a whole set of API embedded in the editor doing pretty much the same thing? I guess retro-compatibility (as usual with Unity).

But so, did you use that only for Project Settings or also for Preferences?

I can see why this package exists. It seems a lot more invisible to the user and seems more inline with how the rest of Unity’s preferences work, albeit editor only. The SettingsProvider attribute only really lets you insert your own IMGUI/UI Toolkit elements into the project settings window, but you still have to back them with your own form of data permanence (usually scriptable objects).

Both in my case. I mostly use it in tandem with my own scriptable-object single class that I use for game config assets. Well, really I use the [SettingsProviderGroup] attribute alongside my own [SettingsAsset] attribute, so I can just slap it on any scriptable object type and it will show in the projects settings window without any additional work on my part.

1 Like

This seems like correct thinking.

Now… does the package do that? :slight_smile:

There’s one more level: global editor preferences as distinct from project editor preferences, neither of which go into a project’s version control.

Of course then you add on global editor preferences that may be overridden at a per-project basis…

“It’s complicated.”

1 Like

Haha indeed!

And yes, the package is supposed to handle both. Hence my original question.