Where to Install Your Assets (for Scripting Packages/Editor Extensions)

Ahhh I forgot that. Thanks for the hint. Will check it.

 

That's fair. You are entitled to your personal opinions. That said, let's examine your post a little.

That is true: Unity does generally support moving folders around willy-nilly. However, there are some major exceptions: the magical Special Folders. You used the term "Unity Core DNA" but there is little more "Unity Core DNA" than the existence and purpose of these folders. They have existed in Unity for ages now, if not from the beginning (at least from the 4.x days, and very likely from the 3.x if not even earlier).

Sure. It would be nice to be able to move stuff around like that. Doing so, however, ignores Unity Core features. Your content and the efficiency of your project may suffer for the sake of project organization rules. In this manner, you are not working with Unity as it was designed but against it.

As @r618 pointed out, this isn't strictly true. You can use AssetDatabase.FindAssets to locate your prefab and add an instance to the scene as you see fit. While it is prone to issues, it is actually more stable than using a straight-up fixed path or placing it in the Resources folder (e.g. what if your customer renames the prefab?). With the FindAssets approach, you could search for the prefab type (GameObject, I believe) and the name you gave it. You can even specify a list of folders to search in. If your initial, specific search fails to turn up anything, remove a restriction to do a broader search. If that fails, issue a warning to your user that "The Prefab source couldn't be found. Was it deleted, moved, or renamed?" ... which is the same thing you would have to do to be nice to your customers if you use the "Resources" approach. Except that with FindAssets, your users can move the structture of your asset around as they see fit.

It would be nice if Unity added a way for asset publishers to specify Preprocessor Directives as you have described. Unfortunately, they don't. We are left with using other esoteric methods of determining compatibility with other assets. As an example, Koreographer packages up third-party integrations into unitypackages and allows users to unpack them once the supported plugins have been installed.

I would be extremely hesitant to insist that my customers respect the asset tags that I specify. A user could very easily remove the custom tag and that would break the entire installation setup you described. Same with Asset Labels.

You could argue that this is the same as people moving folders around. One of many differences is that Unity immediately recompiles scripts when folders are moved in that manner. When that happens, and scripts that were set up to take advantage of the compilation order fail to compile, you are immediately made aware of the issue by having lots of compiler errors show up.

This also does not touch the utility of the Editor Default Resources folder...

You are correct: this is a problem on Unity's end. It can be broken down into two major issues:

1. Restricting Special Functionality to Specific Folders: Specifying which compilation pass a script fits within should be either a Folder asset option or a Script asset option. You should simply be able to specify in the Inspector where that asset fits in the compilation passes. I recommended this to Unity engineers over a year ago and I suggest that you file a bug about it.
2. Failure to Communicate Special Folders: The Unity UI is 100% silent about the special value that any of the Special Folders has. Each of those folders should absolutely get its own icon in the Project view as well as a description in the Inspector and tooltip text for the Project view. I recommended this to Unity engineers over a year ago, and reiterated it to a different team a week ago. I suggest that you file a bug about it.

This post isn't just about compilation order, but about how to set up your assets to take best advantage of Unity and Unity Editor Core features to provide your customers with the best possible Unity experience.

This thread explains how to work as well as possible with Unity as it exists today. If you have issues with Unity as it functions, I encourage you to file bugs (as I have): the more they hear about these issues you've raised, the more likely they are to fix them.

For Asset Store Publishers such as yourself, you also may not have to worry as much about the issues you mention in the future. The Package Manager looks to partition off third-party packages (including, in the future, assets) into their own "local Assets folder". When this happens following the organization outlined above won't even appear in users' main project Assets directory until they manually move the contents over. Please understand that this is speculation derived from watching the progress of the Package Manager over the last few Unity releases, but I suspect that it will be the "new norm" at some point and make most of these arguments moot.

For now, I would recommend using the setup outlined in the initial post: it takes advantage of Unity's core features and is a pattern recognized and embraced by the Asset Store package review team.

I hope this helps.

 

Your customers don't have to know about Asset Tags at all. Packages that support your package would have to. Your package could use them. If you don't need them, ignore the whole thing. Of course there must be a editable list of all defined Asset Tags for the project.
People will use common reasoning and will not break your Tags. Why should they? Its like deleting a script and complaining that nothing works anymore. What can you do about that?

As I said, this is a terrible idea. There is no uninstall system in Unity. If a user doesn't like your asset anymore, she just deletes your asset folder. Therefore having your stuff cluttering the whole project isn't a spectacular fun experience. People will start throwing things at you. And they are right.

 

Well they might want to also type the name of your plugin in the Project View after doing that so they can find the other remnants inside Gizmos / etc and delete those too. Common sense for me.

If you have files that are supposed to be used by those magic folders and choose to ignore and not use them, don't be surprised when people throw things at you. Not using Editor Default Resources folder means your custom Inspector graphics would be included in a build, which is terrible!

 

You might instead use any Editor folder in your package.

 

I was talking about graphics, not scripts. That special folder is meant for graphics that never get exported and only are of use inside Unity IDE.

 

That is not what I said. What I said was that "if a user edited-or-removed your custom tag or label" then it would break. This is more esoteric and less obvious than using the Special Folders. When things break, they would break in asset-specific ways. These also do not handle compilation today, so they do not act as a 1-for-1 swap.

If you are describing a completely new concept in "Asset Tag", then that is a different conversation and one that would be best spent as a suggestion or bug.

Have you ever worked on a team project? Not everyone is aware of every asset in the system. Lots of people will attempt to control and organize their Tags, just like they do with folders. I speak from experience on this (both as someone who did tag cleanup myself on a team and someone who had stuff break due to another person editing tags on a team project). Tags are no more "solid" a solution than folders.

We have never had a user write to us in confusion or anger or anything else asking for help on uninstalling assets set up in this manner. We have used this setup for three-going-on-four years now and not once have we had a complaint.

As @jerotas pointed out, if you search for the asset name in the project view, you should get all the root folders for the assets (provided you followed the structure recommended in this thread). Deleting them should be enough to clear out most/all of the content.

This is another area that will theoretically be improved once Asset Store assets are delivered as [Package Manager] Packages.

This is only true as of Unity 5.1, which is admittedly quite old by now. However, if you look at the code behind that call, the fact that EditorGUIUtility.Load can load from "any Editor folder in your package" (it can actually load from any folder in your package, period), doesn't mean it's the "correct" or "best" way. If you take a look at the code behind that call (using Assembly Browser or equivalent), this is how the function works:

1. Check for the asset in Editor Default Resources.
2. Check for the asset in the built-in Editor Asset Bundle.
3. Fall back on AssetDatabase.LoadAssetAtPath. (← added in 5.1)

By using Editor Default Resources you get the fastest possible load time. This also happens to be the approach suggested and recommended by Unity engineers on the Editor team.

 

Just released an asset having a custom Inspector using a texture located in my Editor folder. This works.

 

Ok, and why exactly would you want to do it that way when there's a special folder for those things?

 

Yes, it will. It is also leveraging a fallback that Unity added in 5.1. Unless you use the generic AssetDatabase.LoadAssetAtPath directly to load your asset, rather than the EditorGUIUtility.Load function then you are doing a lot of extra work for nothing.

It is also possible that Unity optimizes the Editor Default Resources APIs as you can make certain assumptions about assets that are used by Editor GUI that you can't for generic assets in the project. For instance, I believe I heard somewhere that Unity preloads all assets in the Editor Default Resources directory when the Editor starts, which will make things a bit snappier.