Store preferences per project

[AlbertoFdzM]

Change the way that the preferences get stored to allow having different configurations on each project.

Currently all the preferences are being stored with EditorPrefs which saves those values on the system and are shared with all the project.

The settings should be stored in the project folder, maybe the only value that should be stored in the EditorPrefs is the Aseprite path.

Note: Use of PlayerPrefs could solve the problem or this tool could be helpful ProjectPrefs

[edwardrowe]

I am currently working on this fix for my team as well. I'm using a scriptable object, and right now I'm just using it to store the non-looping clips. Will submit a PR when I'm done, probably this week.

[edwardrowe]

Ideally the solution would also allow users on one project to share their settings better. Using PlayerPrefs (PR #8) is an improvement over EditorPrefs, since it won't share the settings across projects, but it doesn't allow multiple users to share settings.

I think the only fix is to put the settings in a file that is stored in source control. I've seen several good assets such as DoTween just use a ScriptableObject in the Resources folder, which is the fix I'm working on atm for my team.

[AlbertoFdzM]

@edwardrowe you're right I think too that it would be better to have this settings stored in the project source and being able to be tracked by the control version system.

Meanwhile that solution get applied this is a good workaround.

[talecrafter]

A custom asset (Scriptable Object) seems to be a good solution so the settings get tracked by the version control system.
Do you see any reason why it should be in the Resources Folder and not somewhere else?

[edwardrowe]

Good question - My main reason for using "Assets/Resources/AnimationImporter/" is to keep the tool from breaking if users want to move AnimationImporter to a different folder (e.g. "Assets/CustomAssets/AnimationImporter"). If you specify the whole path to the settings ("Assets/AnimationImporter/AnimationImporterData.asset"), and they move the tool, it won't know where to find the new settings.

Resources is nice because it's probably a folder that exists already for users, and it seems like a fairly common convention for custom tools. You also specify the path to the Resources file relative to the Resources directory, which means in theory we could store the settings at "Assets/AnimationImporter/Resources/AnimationImporterData.asset", but we'd have to be sure to generate / load it from the correct directory in the first place. I think once it's generated, it might even work to move it (provided you move it somewhere inside a Resources folder).

I would love to hear other ideas for location though, if you have any.

[talecrafter]

Nah, that's a good explanation. Maybe Unity should have designated a typical folder for this, but as it is Resources seems to be the convention and those few bytes included in a build are negligible anyway.
If you have a solution already feel free to post it, otherwise I'll take a look at it in the near future.

[edwardrowe]

Ok. I'll do some more research on it cause I'm actually writing a blog post
on this topic as well. Hopefully I'll be submitting a PR tonight.

I totally agree about wanting a common folder or even API for this type of
thing.

[edwardrowe]

Almost finished this up. I now just need to make sure I use PlayerPrefs instead of EditorPrefs, where it makes sense.

[talecrafter]

Merged with commit f66743b