Feature Request - Allow option to save settings in team-shared or in individual contexts

[medallyon]

Currently, HD settings are saved as a single ScriptableObject in the Assets folder, which is great for a team-shared approach. Individuals may want different settings on their machine than the team-shared settings, but these changes are always reflected in git and can become annoying.

[medallyon]

I'll look into this myself, too =)

[WooshiiDev]

I think this is a fantastic idea, and it's been talked about in the past. I think a simple wrapper to the settings, moving the setting data into its own class would be a good shout.

Nice, I'll not touch this myself then if you want to look into it yourself 🙂

[WooshiiDev]

Been thinking about this a lot more and I'm glad you mentioned the issue of it being stored as a single ScriptableObject. I could restructure the settings structure for this, but I'm not sure how tedious that would be and with the changing API it might not be the best way to go about it. You can create subobjects/subassets where individual context's could be stored. Or there could even be a global path where all setting instances are stored.

Using separate SO's would be a good way to go as you mentioned, with maybe a selection or creation option for individual settings? There needs to be careful consideration into what has individual context. What if an individual wants to remove a prefix from an instance? That'll cause a ton of git conflict.

There could always be the master settings, but then if an individual context is required, they can use their own with the master settings as default.

Currently - as you're using it as part of a team - what are the main issues that appear using HD? What features get toggled the most? I only ask so I can think of the best ways to go about this. I know you're wanting to look into this so don't worry I'm not going to go ahead and do anything, and I have other parts to work on. It's also good to just generally discuss requirements, changes needed etc.

Cheers,
Wooshii

[medallyon]

~~I was sort of thinking about having two different modes - A 'master' mode, which uses the SO, and an individual mode, which uses the current machine's EditorPrefs.~~ As I typed out that previous sentence, I see what you mean by this causing git conflicts. In my case, the headers/prefixes _should_ be shared, whereas the rest of the settings are of a purely visual nature, and, as such, can be stored locally. I don't think it should be too much trouble getting this implemented. I might be able to look into this tonight.

[medallyon]

I had a go at this for a few hours and I just don't know how to separate the settings from the ScriptableObject into EditorPrefs.

[WooshiiDev]

Hey there,

Yeah I had a feeling this would be the case due to how much there'd be to split up. But that's not a problem, experimentation is half of the work when it comes to Unity and Editor additions!

I do think it would be better using SubObjects- that are scriptable objects like the current settings but store less.

On the main scriptable there would be an option to switch between global and individual/profile mode. If profile mode is selected, they could then select a profile that exists or create one and that would be added to a list.

The selected mode would then be stored in the EditorPrefs.

If a profile is made, a scriptable object with settings specific to that user would be created - and would be named the same as the profile itself. We could then make it a SubObject of the main settings so then searching for profiles is easy - they're all in one location.

As the data in the Settings are all now wrapped into data classes, we can just reuse that structure for profiles. If needed we can discuss this further together and I can help you along the way if you're still interested in giving it a go.