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.

[IndieSeal]

Hello! I looked at this feature, and this would be awesome to add!
I have an idea for executing this, it wouldn't affect the already existing system much, so not much modification would have to be made. I've also made a list of it's pros and cons. So, do let me know what you think, I'd love to develop this!

So, we already got a folder for storing the Settings, which I would rename to GlobalSettings, what we could do is add a subfolder, that we would call "IndividualSettings", this would store all of the Settings Scriptable Objects for every user.

How do we decide the user's name? We just check which assets already exist on the IndividualSettings folder, if there's none we just create a new one called "IndividualSetting" and at the end we just put a number, this number would be stored in one of these two (uncertain which could be best):

• Storing the name of the user in EditorPrefs.
• Creating a file on the user's computer, which would store the name of the user.

So, to know which asset belongs to which user, we just check if the file exists and we check it's contents, or we check in EditorPrefs if the index we want DOES exist. This would all be a function that returns a Settings file, this is how we would get the settings for each user, we would just run this function and the value it returns is the one we use, if you have the option called: useGlobalSettings : active then we just return the GlobalSettings asset.

I'm not sure if I'm being clear enough haha 😅.

Just to recap, a File / EditorPrefs would be in charge of storing our User Name, then a folder will cointain all the Setting SO's, which depending on our user is the one we will choose and use!

To prevent other users from modifying others files we would make the other ones read-only, and you would only be able to modify yours.

The upsides of using this technique are these:

1. Not much change in the actual code, not the hardest implementation.

The downsides of using this technique are these:

1. If someone erases one of the settings scriptables, we cannot rely on just an index / number, because there will be files with the same name, and the asset finder will get confused, there's ways to fix this, but it could get messy.
2. If we modify the name of the folder / move it somewhere else, things would stop working properly.
3. Maybe it gets annoying to have a bunch of files made for each individual user (at some point there could be a lot of files if it's a large project?)
   There's obviously ways to fix all of these, but it will require some more time to adjust till it's perfect.

I just like throwing ideas around, but let me know if something like this is something that would be good working on possibly? Or if you think there's better ideas of implementing this request, I know it's been a while since this was touched on, and maybe you already have something in mind. Alr, thanks :]