search

talecrafter / AnimationImporter

Aseprite Animation Importer for Unity
613 stars 72 forks source link

Store preferences per project #5

Closed AlbertoFdzM closed 8 years ago

AlbertoFdzM commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

talecrafter commented 8 years ago

Merged with commit f66743b2b62d6ffc6002f3a036e8617514497b05