Search Unity

  1. Unity 2018.3 is now released.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. Want more efficiency in your development work? Sign up to receive weekly tech and creative know-how from Unity experts.
    Dismiss Notice
  4. Build games and experiences that can load instantly and without install. Explore the Project Tiny Preview today!
    Dismiss Notice
  5. Nominations have been announced for this years Unity Awards. Celebrate the wonderful projects made by your peers this year and get voting! Vote here!
    Dismiss Notice
  6. Want to provide direct feedback to the Unity team? Join the Unity Advisory Panel.
    Dismiss Notice
  7. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice

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

Discussion in 'Assets and Asset Store' started by SonicBloomEric, Jan 21, 2015.

  1. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    Where Should My Extension Be Installed?

    This is a natural question for developers interested in submitting an Editor Extension/Scripting Package to the Unity Asset Store.

    A detailed writeup about this follows, but for those looking for the quick solution (the TL;DR version), this depends on the version of Unity you're using.

    Unity 5.2.2+
    Unity quietly made a change in Unity 5.2.2 to support Editor folders anywhere in the Plugins directory (read: not directly underneath Plugins). If you plan to support only Unity 5.2.2 and above, Editor Extensions/Scripting Packages should be installed as follows:

    Main Contents: Assets/Plugins/[Package_Name]/...
    Editor Scripts: Assets/Plugins/[Package_Name]/Editor/...
    Editor Resources: Assets/Editor Default Resources/[Package_Name]/...

    Legacy Unity
    If you need to support Unity versions prior to Unity 5.2.2, Editor Extensions/Scripting Packages should be installed as follows:

    Main Contents: Assets/Plugins/[Package_Name]/...
    Editor Scripts: Assets/Plugins/Editor/[Package_Name]/...
    Editor Resources: Assets/Editor Default Resources/[Package_Name]/...

    Onward to details!

    The [Wrong] Default Approach

    Most extensions appear to install directly into a project's Assets folder root, which feels like a natural solution:

    Main Contents: Assets/[Package_Name]/...
    Editor Scripts: Assets/[Package_Name]/Editor/...
    Editor Resources: Assets/[Package_Name]/Resources/...

    It turns out that this actually has two pretty surprising problems:
    1. If the package has scripts and supports an API, only the original language the API was written in can be used to interface with it. This has to do with the Script Compilation Order.
    2. All assets in the Resources folder are actually included with your user's build, even if they're GUISkins or fonts intended solely for use with your EditorWindow!
    Unity provides mechanisms for getting around these issues: the Special Folders. There are three different Special Folder groups that circumvent problem 1 above:
    1. Assets/Standard Assets/...
    2. Assets/Pro Standard Assets/...
    3. Assets/Plugins/...
    The [Pro ]Standard Assets folders appear to be used for the standard assets that Unity provides with every installation. This leaves the Plugins folder which doesn't look like a great location for non-native (or, at the very least, assembly) plugin installation, given the documentation.

    So which is better? Unity engineers have informed me that
    Nice. This means that if you wrote your Editor Extension in C# and wanted someone writing in Unityscript or Boo to be able to interface with your tech out of the box, you will need to organize your package for installation as follows:

    Main Contents: Assets/Plugins/[Package_Name]/...
    Editor Scripts (5.2.2+): Assets/Plugins/[Package_Name]/Editor/...
    Editor Scripts (pre-5.2.2): Assets/Plugins/Editor/[Package_Name]/...

    A Source of Confusion/Common Misconception(?)

    It has become apparent that there is a lot of confusion about Special Folders and how they work, even for Unity employees. It appears as though most people believe that they follow the generic Editor folder rules:
    • Scripts inside a folder called Editor found almost* anywhere will be compiled in a separate pass from game scripts.
      • Scripts in these folders are not included in Assemblies for final builds.
    * this will be addressed below, but Editor works differently when combined with other Special Folder names in versions of Unity prior to 5.2.2.

    By this I mean that most people seem to expect that the following would work:
    • Scripts inside a folder called Plugins are compiled in the firstpass compilation pass, and therefore accessible by any scripting language.
    By this logic, the following folder setup should enable a library written in C# to be accessed by scripts written in Unityscript or Boo:

    Main Contents: Assets/[Package_Name]/Plugins/...
    Editor Scripts: Assets/[Package_Name]/Editor/...

    This is NOT the case! According to current Unity folder rules, this results in all package scripts getting compiled in the normal pass. Further, the Editor scripts end up in the normal Editor compilation pass, not the firstpass one.

    Okay, so Plugins isn't a magic "anywhere folder" like Editor. Fine. Let's try to move our package into Plugins, then, to get that language agnosticism. Results here depend on what version of Unity you're targeting.

    For Unity 5.2.2+

    This works in Unity 5.2.2+:

    Main Contents: Assets/Plugins/[Package_Name]/...
    Editor Scripts: Assets/Plugins/[Package_Name]/Editor/...

    Great. Skip ahead to the What About Resources? section below if you don't care about versions prior to Unity 5.2.2.

    For Pre Unity 5.2.2

    Unlike recent versions of Unity, this doesn't work for versions prior to 5.2.2:

    Main Contents: Assets/Plugins/[Package_Name]/...
    Editor Scripts: Assets/Plugins/[Package_Name]/Editor/...

    The problem is that all scripts now end up in the firstpass assembly for game content - the Editor scripts do not end up in the Editor-firstpass assembly as we'd hoped! In fact, they do not end up in an Editor package at all, resulting in errors (no UnityEditor) during the build process. This is because when placed within Special Folders, the Editor folder name does not follow the standard rules! As outlined in the pre 5.2.2 documentation, you must place your Editor scripts in the Assets/Plugins/Editor folder to gain Editor-firstpass compilation! Therefore:

    Main Contents: Assets/Plugins/[Package_Name]/...
    Editor Scripts: Assets/Plugins/Editor/[Package_Name]/...

    In summation, the Plugins folder does not work like standard Editor folders. And, for that matter, Editor folders under Assets/Plugins do not work like Editor either.

    What About Resources?

    In case you weren't already aware, everything in a Resources folder ends up in a special package called resources.assets that is included with the build package. This means that if your nifty Unity library includes nice Editor UI icons in a folder called Resources, those will end up in the final game! That's just wasted space for your user (or yourself)!

    Luckily Unity provides a special option for assets that are intended for use solely within the Editor. Such assets should be placed in a special folder called Editor Default Resources:

    Editor Resources: Assets/Editor Default Resources/[Package_Name]/...

    Assets (textures, skins, fonts, etc.) in this folder will not end up in the exported resources.assets package at build time. Note that these are accessed using a special API call: EditorGUIUtility.Load.

    So this implies that if you wish to play nicely with the Unity Special Folders and gain access to their advantages, a full Editor extension would need to be installed with the following setup:

    Main Contents: Assets/Plugins/[Package_Name]/...
    Editor Scripts (5.2.2+): Assets/Plugins/[Package_Name]/Editor/...
    Editor Scripts (Pre-5.2.2): Assets/Plugins/Editor/[Package_Name]/...
    Editor Resources: Assets/Editor Default Resources/[Package_Name]/...

    Why This Is Important; Going Forward

    As Editor Extension developers the goal is frequently to create a library that provides some enhanced or added functionality to the user. In an ideal word, the solution provided should enable the end user to integrate your extension with their workflow with minimal effort. This means supporting all Unity-supported scripting languages. At present, this is possible but only using the folder structure outlined above.

    Some of the Unity engineers I've talked to seemed to be under the impression that all of the special folder names acted the same way as the Editor name, implying that the following would work:

    Main Contents: Assets/[Package_Name]/Plugins/...
    Editor Scripts: Assets/[Package_Name]/Plugins/Editor/...
    Editor Resources: Assets/[Package_Name]/Editor Default Resources/...

    The benefit to such a setup is that everything would be contained within a single folder that the end-user could reorganize as they saw fit while maintaining the benefits of firstpass compilation and Resource usage. When they realized that such a setup did not work according to their expectations, they considered it a bug and something that should get fixed. Nice.

    Hopefully, barring a full package system overhaul, something like the above will become viable in the near future, representing a relatively simple solution for both extension developer and user!
     
    Last edited: Apr 22, 2016
    bjarkeck, kupio, r618 and 23 others like this.
  2. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    599
    Sorry to bump such an old topic!

    Until recently I was under the impression that this worked just fine.

    We have a large framework of code that we have developed in house. The framework has lots of different 'modules' that we separate into their own folders. For example, if a module has some plugin data (jar files, etc), it goes here:

    Assets/FrameworkCode/[Module Name]/Plugins


    So, we have lots of different plugin folders:

    Assets/FrameworkCode/NativeLocalNotifications/Plugins
    Assets/FrameworkCode/NativeReviewPromptDialogue/Plugins


    This actually works just fine for android and iOS library files (.jar and .a). When we build for iOS, it finds all the .a files correctly, and for android it finds all the jar's correctly! But this is all that works. Two big issues!

    1. Scripts (.cs) must be in Assets/Plugins to be compiled as part of the 'plugins assembly'.
    2. It seems like any manifest file outside of Assets/Plugins is completely ignored (Permissions are not merged, receivers are not merged, etc), so this means that you are limited to a single 'AndroidManifest.xml' file and the 'xml merging feature' of Unity, (I am pretty sure I read that there was one?) is useless.
    If we could get the Plugins folder to work like the Editor folders, that would make organisation so much easier. Right now, we can place an editor folder anywhere and it just works fine. We should be able to place a Plugins folder anywhere as well, and have its sub folders register correctly( Plugins/iOS, Plugins/Android, etc).
     
  3. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    Old but still relevant! (Unfortunately...)
    The "Editor folder anywhere!" feature came in fairly recently (5.2.2). I suggested something similar to a Unity Developer in the form of "Folder Properties" (with a fallback suggestion of at least adding unique icons for Special Folders). Effectively I was told:
    We can only hope that the timeline for "after 5.4 launch" is on the shorter side...
     
  4. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    A user (@zwcloud) posted the following question to this post on the "new" forums during the brief period they were up:
    This was the response:

    Actually, the Asset Store Tools were written to ignore themselves. It is indeed very confusing, but when you upload your assets you can select the root Assets directory.

    This, however, causes another issue (particularly with older versions of Unity) in that your users will see collisions between the Gizmos, Plugins, Plugins/Editor, Editor Default Resources, etc. Folder Assets (folders have GUIDs, too) when they already exist in the project into which they're importing. In Unity 5.2.x and earlier, this could cause asset reimportation and the spewing of lots of errors. Recent versions of Unity (5.3.3 [at least], and 5.4beta) no longer throw errors or trigger reimportation but will show you the collision and warn about it in the Package Importer window. I have an open bug report with Unity about this (Case 776565). The simple solution to this is to allow us to select multiple root folders for our assets in the Asset Store Tools.
     
  5. IsaiahKelly

    IsaiahKelly

    Joined:
    Nov 11, 2012
    Posts:
    246
    According to the manual, the phases of script compilation are as follows:
    So apparently the following locations are also valid for first-pass editor script compilation:

    Editor Scripts:
    • Assets/Standard Assets/Editor/[Package_Name]/...
    • Assets/Pro Standard Assets/Editor/[Package_Name]/...
    However, I've noticed that when importing the standard assets an editor folder is created in the root of the project. Does this mean editor scripts placed there are also processed first?

    Editor Scripts: Assets/Editor/[Package_Name]/... ???

    The manual does say editor folders "anywhere inside top-level folders" are included in phase 2, but omits the root Asset folder from the listed locations (simple oversight perhaps?). But if Unity is placing scripts there then I would assume this is indeed the case.
     
    Last edited: Jul 13, 2016
  6. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    Hi @Isaiah-Kelly! This is indeed a confusing part of the manual. I will do what I can to straighten things out.
    The short answer is "Yes". The longer answer is "there are multiple firsts".

    The four phases mentioned in the manual actually equate to four separate assemblies. If you place scripts in all four sections within a single project, you will notice the following layout in MonoDevelop/Visual Studio:

    Here's a breakdown of the four assemblies:
    1. Assembly-CSharp-firstpass - [Phase 1] - This is all C# scripts beneath Plugins, Standard Assets, and Pro Standard Assets, not in an Editor folder.
    2. Assembly-CSharp-Editor-firstpass - [Phase 2] - This is all C# scripts beneath the folders mentioned in #1 that happen to also have an Editor folder in the path somewhere (see the note about Unity 5.2.2 for how this differs with earlier versions).
    3. Assembly-CSharp - [Phase 3] - This is where all C# scripts not in Plugins, Standard Assets, and Pro Standard Assets are handled. Note that if scripts are within an Editor folder at some level, then they end up in #4.
    4. Assembly-CSharp-Editor - [Phase 4] - This is where all C# scripts beneath Editor folders that are not in Plugins, Standard Assets, and Pro Standard Assets are handled.
    Note that these assemblies are scripting-language-specific. In the list above, all scripts in the project are C#. If you have Boo or UnityScript files you will see similar assemblies appear in the above list with older versions of MonoDevelop*. E.g. Assembly-Boo and Assembly-UnityScript.

    This is the system that enables cross-language support: when compiled, the scripts are converted into a Common Intermediate Language (IL). As compilation passes are aware of IL, each subsequent pass can reference earlier passes, regardless of the initial language. This is specifically how the firstpass assemblies enable cross-language development.

    *Newer versions of Unity now appear to mainly support C# with the IDE (MonoDevelop/Visual Studio) and have dropped deep support for Boo and UnityScript (JavaScript). These languages still compile, but they do not show up in the Solution browser within MonoDevelop (at least by default).
    What's happening here is that these are ending up in Phase 4 instead of Phase 2. I'm unsure as to why this is necessary - it's possible that it was a simple oversight or perhaps implemented by someone who didn't fully understand the compilation passes (as pointed out in the initial post, even core Unity engineers aren't fully aware of how this all works together).

    I imported the current Standard Assets to run a quick test. As expected, the solution contains projects for phases 1, 3, and 4. I moved the Editor folder into the Standard Assets folder and updated the solution. As expected, the projects were now for phases 1, 2, and 3. No errors occurred in doing so, so it appears that this should work absolutely fine.

    As a heads up, moving scripts into firstpass compilation will help reduce the amount of time your main project scripts take to compile when they change.
     
    IsaiahKelly likes this.
  7. IsaiahKelly

    IsaiahKelly

    Joined:
    Nov 11, 2012
    Posts:
    246
    Thanks for doing such a detailed investigation into this @SonicBloomEric!

    How bizarre. The placement seems deliberate, since it would seem to go against both natural instincts and the official manual. The VR sample assets place the editor folder in the root too. Does Unity know something we don't? In any case, Unity developers do seem to lack a bit of consistency, so maybe this is just an oversight. Take for example the naming convention (or lack thereof) for special folders themselves:
    • "Standard Assets"
    • "Editor default resources"
    • "StreamingAssets"
    Here we have a folder named with full capitalization and spaces, only first word capitalized and spaces, and PascalCase!? And this lack of standard naming isn't limited to just special folders, e.g. "Main Camera", "EventSystem", "char_cyberKid_low" etc. o_O


    Thanks anyway for trying to get to the bottom of this though. Very helpful information.
     
    Last edited: Jul 13, 2016
    SonicBloomEric likes this.
  8. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    No problem. It took me a while to figure this stuff out and I'm more than happy to share with the wider community.
    Yeah. To that end I filed a bug about it (Case 813847). If they respond with a reason for this to be at the root, I'll update here with their explanation.
     
    AlanMattano likes this.
  9. IsaiahKelly

    IsaiahKelly

    Joined:
    Nov 11, 2012
    Posts:
    246
    I decided to examine the standard asset packages to see if I could deduce the reason why the editor folder is placed in the root. First thing I noticed was that multiple standard asset packages for 5.x do this, including: Standard Assets, VR Samples, Tanks!, and the Corridor Lighting Example. I thought this fact might show a consensus, but quickly realized this is probably only happening because each one of these packages share some of the same content and are just replicating the original file locations.

    So I decided to take a look at all the original Unity 4.x standard asset packages and made an interesting discovery; The only packages to contain a root editor folder were Image Effects and Water (Pro Only) . The "Standard Assets for Unity 4.6" package also contains image effects without a root editor folder, but those assets are not installed into the standard assets folder! They're put into a folder called "SampleAssets" instead, so they should still end up in phase 4.

    So it seems like Unity is intentionally excluding image effect related editors from the standard assets folder. However, I've tested moving these files back into the standard assets folder and didn't notice any issues. So I still don't know exactly why they need to do this. I also assume Unity could have put only the image effects in the root editor folder, and the rest inside the standard assets folder for Unity 5.x, but decided there was no harm in keeping them all together.
     
    Last edited: Jul 14, 2016
    SonicBloomEric likes this.
  10. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    Update: The bug report received the following response from Unity QA:
    It seems that not having the Editor folder within the Standard Assets folder was a simple oversight.
     
    IsaiahKelly likes this.
  11. IsaiahKelly

    IsaiahKelly

    Joined:
    Nov 11, 2012
    Posts:
    246
    Thanks for the update.

    So I guess I was over analyzing all this and it was just a simple oversight after all. Weird. Unless, of course, the QA team is also ignorant to the true purpose of the editor folder placement! :eek: !!CONSPIRACY THEORY!! :p
     
  12. jerotas

    jerotas

    Joined:
    Sep 4, 2011
    Posts:
    4,850
    I agree with all of this although I had figured it out piece by piece over a few years. Great to see it all in one place!

    What sucks is that most plugins still install everything in Assets, not Assets/Plugins for some reason. Either they're not aware of the compile time problem or something else.

    Thoughts? I would like ALL editor extensions to be in plugins. I use tons of them and have to move them manually. Some don't work properly in there either (maybe hard-coded paths or something).
     
  13. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    I'm 99% certain that there are a few things going on here (in order of likelihood):
    1. Poor Communication: Unity does not communicate the existence or purpose of the Special Folders well. This applies to both the Manual and the Editor itself. Why don't Special Folders have separate icons in the Project View? Why don't they have Tooltips that describe (or even hint at) their purpose? Why doesn't the Plugins page make mention of non-DLL plugins?
    2. Poor Workflow: Unity does not explain how to use the Asset Store Tools well. The Asset Store Tools only allow the user to specify a single folder. If you use the Special Folders correctly, this must be the root Assets folder. Many people try to upload their extensions from their development folder which likely has other stuff in it. To deal with this they probably find it easier to simply move everything into a single folder and call it a day. It works, right?
    3. Poor User Experience: I'm sure you've experienced this but users sometimes move the folders into a single root directory of their own choosing and things break. With our packages, this is due to icons/skins being moved out of the Editor Default Resources folder. The natural thing to do is to put everything under a single product's folder and code it in such a way that the whole thing is location agnostic (which can be pretty challenging).
    When I first started using Unity, I would move extensions into a folder of my own choosing. Some worked and, as you have described, some failed spectacularly - so much so that I had to simply delete everything and reinstall because I didn't know how to restore things.

    With respect to requiring ALL Editor Extensions to be in plugins, I'm not sure how tenable that is. We put documentation, demo content, and related stuff into a product folder in the root Assets directory. This improves discoverability (as Unity doesn't have notifications on folders for "new" or the like) and also means that users are free to destroy the root folder, removing all the extra "bloat" content and leave everything in Plugins/Editor Default Resources/etc. running smoothly.

    The one thing I might suggest that Unity add to the Submission Guidelines is that any folder placed outside of the Special Folders should be relocatable without breaking the asset.

    Apparently Unity is working on this problem, but the whispers I've heard don't lead me to believe we'll see any big changes soon.
     
  14. compressedFusion

    compressedFusion

    Joined:
    Sep 9, 2015
    Posts:
    2
    I agree with the Resources but this seems like the correct solution for editor scripts that don't need to be accessed as an API. Could you elaborate on the use case in which the editor script needs to be accessible as an API in C# or JS? I would assume a custom inspector or custom SceneGUI doesn't typically fall under this category.
     
  15. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    The use case for Editor Scripts being accessible as an API relates to Editor Extensions and, more generally, anything that has a special component (MonoBehaviour) with public functions you may want to control with script. You can write a MonoBehaviour in Boo, right? Putting it in the firstpass compilation pass makes those functions callable with whatever language the user likes.

    I should also mention that there's another benefit to all of this: your scripts do not add to the amount of time it takes to compile a project when a user makes a change to a script outside the firstpass compilation passes (outside of Assets/Plugins). While this is almost imperceptible on small prototype projects, it can seriously add up for larger projects. This is simply part of being a nice neighbor. Firstpass scripts are only recompiled when other firstpass scripts are changed.

    I would suggest that the only time to not put scripts in the firstpass locations is when you want to provide your users with scripts that they should edit or configure themselves.

    Make sense?
     
  16. compressedFusion

    compressedFusion

    Joined:
    Sep 9, 2015
    Posts:
    2
    I suppose there is no way to know if your editor will eventually need to support extensions by the community such as playmaker. So, you make a good point.

    I agree with the compile time.

    Your logic makes sense in principle, but the situation in practice might be somewhat different. The two fundamental issues are:

    1.) The plugins directory forces an illogical separation of code and fosters controlled chaos (or disorganization). It also separates the asset as a bundle when trying to remove it or track down a dependency.

    2.) I almost always have to tweak something in an asset to meet my needs or deal with a conflict. This problem is compounded by Unity version differences.

    All of this could be mitigated by better tools to display the dependencies of an asset as a logical unit of code/models/fx. I have tried to use assets like RelationsInspector (I used the free trial version) to help manage this but I didn't have much luck on my more complicated dependencies.

    This lack of structure is a real issue that arguably costs more time than constant recompile.

    I'm curious if you have run into similar issues with organization and project asset flux.
     
  17. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    On the contrary, the separation is very logical - it simply isn't communicated well and, currently, requires that users somehow already understand something that I'd argue most Unity employees don't even understand. Unity didn't randomly build their technology this way - there was a purpose. They just didn't follow through on the communication side of things.

    That said, I do agree that it is an unnecessarily complicated, legacy architecture that does not adhere to good UI principals.
    If asset developers follow the structure outlined in this document you should be able to quickly find all root packages by simply typing the package name into the Project view's search box. In terms of script dependencies, wouldn't it be faster to search for symbols within scripts using MonoDevelop/Visual Studio/your-favorite-IDE? Theoretically, non-script asset dependencies would all live in the main root folder which you could move about freely (the exceptions here being assets that need to live in Gizmos or Editor Default Resources).
    I take it you're suggesting that breaking up the package into multiple folders makes locating the specific asset to tweak is a hassle, yes? That is a pain, but I believe the theory behind the initial structure of all of this was that scripts for packages would be under Plugins and everything else would be under a single package location (same exceptions as previously mentioned). If everyone followed this setup then this would be easier to mitigate. They don't, however, which means that it's somewhat of a crapshoot (one good reason to do this is if you are a company that provides multiple packages that can work together. In that case people typically do [Company]/[Package Name] instead of just [Package Name]).
    Oh my, yes. This is also why the Unity Asset Store allows you to upload your asset with multiple versions of Unity. Take one of our packages for example: we upload with Unity 4.5.0, 4.6.0, 5.0.0, 5.1.0, and 5.4.0 to properly support all the variations. We jump through several layers of hoops with our build system in order to make this all work. It is most definitely a pain when asset publishers don't update their package frequently enough to handle Unity changes.
    Yeah, this is certainly annoying. The AssetDatabase does not have provide a mechanism to locate assets that make use of a specific asset. In the past I've found that using the Version Control→Mode→Visible Meta Files and Asset Serialization→Mode→Force Text settings in the Editor Settings allows you to use standard OS tools (e.g. grep in OSX) to search for dependencies outside of Unity. This, of course, is a very manual process but it does work.
    Perhaps in extreme circumstances, but I've not found the organization to be that much of a problem (at least once I understood more about how everything worked!). Generally assets work pretty well and clickable errors in the Console help to bring you directly to offending assets/scripts. But my experiences are my own and I do not claim to speak for the entire industry. In principle I completely agree with you.
    With other assets, yes. The biggest headache I've personally dealt with is trying to get multiple assets that make use of different versions of the Standard Assets to play nicely together. This issue is compounded when Asset Publishers mess up the GUIDs of shared assets (e.g. Standard Assets) when uploading to the Asset Store.
     
  18. IsaiahKelly

    IsaiahKelly

    Joined:
    Nov 11, 2012
    Posts:
    246
    I came across this in the Asset Store guidelines:
    This is a bit confusing. Does this mean we should not place assets inside any of the special folders, and just tell users to move them there manually instead? They don't explicitly say special folders, but do refer to them. However, saying "specific folders to be in the project’s root" is really ambiguous and can't mean just any root folders, right?

    In any case this doesn't make much sense to me because aren't plug-ins required to be placed in the plugins folder? And if they're not talking about special folders then what exactly are they talking about?? Maybe they just mean multiple root folders??? :confused:
     
  19. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    This is a very unfortunate and not-well-thought-out clause in the revised Asset Store Submission Guidelines. It was immediately brought up as a concern in the Asset Store Publisher's list given that this structure has actual utility and @Ian-Dunlap responded with:
    They have yet to make any adjustments to it.

    This effectively stems from internal Unity employees not understanding the purpose and utility of these folders. I have been told that changes are in the works to help fix this situation.
    It's the multiple root folders that they were trying to avoid. I'm pretty sure they just noticed that a bunch of people seemed to be using Assets/Plugins and called it out specifically without realizing the purpose behind those folders (especially for older Unity versions). In short, you are okay to use the folder structure outlined in this thread - the Asset Store team is aware of it and I've been told they are working on fixing both the guidelines and the underlying systems to be more user friendly.
     
  20. IsaiahKelly

    IsaiahKelly

    Joined:
    Nov 11, 2012
    Posts:
    246
    Based on the information in this topic it seems like the Asset Store team is trying to avoid folder GUID conflicts that result from multiple asset packages using the same special folders. Specifically the very common "Plugins" and "Editor" folders in the root. Unfortunately, I think they've completely failed to articulate this and should probably rewrite that section to say something like this:

    Yeah. This issue is directly address in the Asset Store Guidelines now and further confirms my assumption that they're trying their best to avoid these GUID conflicts with submitted packages as much as possible.
     
  21. IsaiahKelly

    IsaiahKelly

    Joined:
    Nov 11, 2012
    Posts:
    246
    However, I have something of a dilemma now: Do I place my editor extension inside the "Plugins" folder and risk throwing import warnings, in exchange for some benefits my extension might not even take advantage of?
     
  22. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    I do not think this is the case. In Unity 5.3 and above, the import process shows a warning during GUID conflicts like this but otherwise doesn't complain. This is not a terribly great way to address the problem, but it is what it is. Essentially, the importer has been updated to minimize the visible impact of GUID conflicts during the import process.

    The Asset Store team [and asset publishers, to be sure!] would prefer that every asset is installed in a single root folder and that the folder be immune to relocation. Many customers have their own specific project layout and like to move third party assets into a particular structure (e.g. Assets/Third Party/...). Every few months we get a bug report about a plugin not working and this is because someone moved things around because they didn't understand that the special folders were indeed special (and functionally so). We never blame the customer for this as the lack of useful, communicative UI in this department is entirely on Unity's hands.

    [I should note that the Editor folder never needed to be in the root folder. The one restriction (until 5.2.2) was the Assets/Plugins/Editor folder. Editor Default Resources, on the other hand...]
    I think this is entirely the wrong way to go. Users should not need to read documentation to help them get something installed correctly. Unity should rather ask that Publishers make proper use of the Special Folders. Unity themselves should then put real effort into:
    1. Communicating the nature of the Special Folders to both publishers and users (but especially publishers).
    2. Fixing the Asset Store Tools to either be properly aware of Special Folders or allow for multi-root selection (Case 776565).
    In that way both publishers and users would benefit from the rules.
    Clause 3.1.e does indeed address this issue. The problem here isn't necessarily GUID-related, however, but Standard Asset version differences. If you import a package that includes Standard Assets from a different version of the Standard Assets package, one of several things can happen:
    • The GUIDs are the same as the version Unity ships - the version in your local project is updated with the older or newer version that may introduce conflicts or otherwise be incompatible with the version of Standard Assets you installed.
      • Note: This can be extra bad in the case that the version of assets you install was actually for a different version of Unity (e.g. older asset uploaded for 4.x imported into a 5.x project).
    • The GUIDS are different from the version Unity ships (the publisher copy-pasted the assets, dragged them in from a different project, etc.) - you end up with assets that have the same name.
      • If they're in the same folder, they may overwrite and you end up with the same issue above (as well as broken prefabs, etc.).
      • If their location is different from the main Standard Assets location, you end up with duplicates. This probably isn't that bad unless scripts are included, at which point you end up with either duplicates (possibly in different compilation passes) or compilation errors because the classes are already defined.
    All of the above scenarios (GUID conflicts or no) are sidestepped by Clause 3.1.e.

    That said, GUIDs are a huge problem for Publishers. I've heard that some publishers find managing them properly too large a hassle and simply instruct their users to delete the asset before reimporting for an update. This route is awful because when the GUIDs do change, external linkages all break during the update process. I don't necessarily blame people for not understanding how GUIDs work within Unity and the greater Asset Database - they do a terrible job explaining them:
    In fact, the best resource I found that actually covers GUIDs is this external blog post. It's somewhat shocking that Unity doesn't cover this core piece of how the engine actually works.
    Use the Plugins folder only if there is a reason to do so (script compilation firstpass, Unity 4.x build requirements). Otherwise, I would suggest sticking with the "Assets/[Package_Name]/..." setup. The import warnings have been all but eradicated by recent Unity versions (5.3+) such that all your users will see is a little warning triangle in the importer window (which they likely won't even notice).
     
  23. garza

    garza

    Joined:
    Dec 18, 2013
    Posts:
    28
    I do not understand what is wrong with the "The [Wrong] Default Approach".
    this is the approach i use and it seems to be working out for me.
     
  24. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    This is explained in the original writeup:
    Your package's scripts will work just fine using "The [Wrong] Default Approach". They will simply get compiled along with your users' scripts. This means that every time a user modifies one of their scripts, they have to wait for your scripts to recompile as well as theirs. Further, if they prefer to use UnityScript and you wrote your API in C#, they'd be out of luck. By using the approach outlined in the post, your scripts will be compiled in an earlier pass than the scripts written by your users' - when they modify their scripts, your scripts do not need to be recompiled. Also, because those scripts were compiled in an earlier pass, they will have been converted into IL (Intermediate Language) and stuffed into an assembly (DLL) behind the scenes. This means that all of your functions will be accessible to your users in whichever language they decide to use.

    Can you do it the [Wrong] way? Yes. Should you? No.

    As for the second point, you don't want your Editor-facing resources showing up in your users' game builds, right? That would just waste disc space (and is why the Editor Default Resources folder exists).
     
    Last edited: Sep 22, 2016
  25. Kumo-Kairo

    Kumo-Kairo

    Joined:
    Sep 2, 2013
    Posts:
    298
    It's kind of a necroposting, but the idea itself deserves some attention. I embraced it as my package distribution solution - it's sitting nicely in plugins and compiling in a FirstPass .dll, everything is good. Except that users usually put all of their external packages in custom folders after downloading. It can be Libs, ThirdParty, Libraries, Packages etc. And as those folder don't compile as FirstPass anymore, any additional scripts that come with updates like editor extensions or breaking up scripts into different files results in breaking a package. Because new scripts go into the Plugins folder and both runtime and editor code gets compiled as FirstPass, while the old stuff now sits nicely in a non-FirstPass dll and thus can't be reached from new code. This leads to compiler errors and people demand support (70% of my support messages are about it).

    So while the Plugins idea seems like a good solution, we have to understand the nature of people - we tend to customize things we own. And this problem won't go anywhere even if there will be a RED CAPS CAPTION about "Leave the package in the plugins folder" because people don't read those anyway (me neither).

    That said, I wouldn't say that the default approach is "wrong", it's actually closer to customers than putting it in Plugins folder (not everyone knows about all this FirstPass / normal dll building process), because people move things around the project anyway.
    I will most likely "revert back" to "The Wrong Default Approach" as it will definitely reduce the support pressure greatly.
     
    Last edited: Feb 27, 2018
  26. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    232
    With last Unity I think all package should be in separate UnityModule and must be placed in different folders.

    For example: In all my projects all thrid party and most of subsystems developed in our company reside inside Assets/Extensions/[PackageName] dir

    and all art packages in Assets/ArtPacks/[PackageName]

    every extension has its own asmdef file so it always compiles in right order.

    There need some support from Unity to update such packages in place of package in project rather in original package path
     
  27. DominoM

    DominoM

    Joined:
    Nov 24, 2016
    Posts:
    432
    You could do something like this:
    Code (csharp):
    1. using UnityEngine;
    2. using System.Reflection;
    3.  
    4. public class TestAssembly : MonoBehaviour {
    5.  
    6.     void Awake () {
    7.         string currentAssem = Assembly.GetExecutingAssembly().FullName;
    8.         if (!currentAssem.StartsWith("Assembly-CSharp-firstpass")){
    9.             Debug.LogError("This script must be in plugins folder", this);
    10.         }
    11.     }
    12.  
    13. }
     
    Last edited: Feb 27, 2018
  28. Kumo-Kairo

    Kumo-Kairo

    Joined:
    Sep 2, 2013
    Posts:
    298
    @DominoM you seem to not know assetstore customers, this solution will result in a hell lot of negative reviews like "I don't want to keep it in Plugins folder, I have a custom special folder for packages!" :) Package should be as streamlined, intuitive and robust as possible. We need to put people's needs (and wants) and nature before technical limitations or requirements.
     
  29. exiguous

    exiguous

    Joined:
    Nov 21, 2010
    Posts:
    1,141
    I may be wrong but AFAIK there is no need for one Plugins Folder. Each package can just have one under the package folder:
    ThirdParty/Asset1/Plugins/Scripts
    ThirdParty/Asset2/Plugins/Scripts
    Then Users can Move around or rename your asset Folder and the scripts still compile in Plugins. It seems this is also the aproach suggested by the op. Or do I miss the point?
     
    Kumo-Kairo likes this.
  30. Kumo-Kairo

    Kumo-Kairo

    Joined:
    Sep 2, 2013
    Posts:
    298
    OP suggested to put packages inside of the root Plugins folder, check the first post.
    So it's not "Assets/Package/Plugins/Scripts" but actually "Assets/Plugins/Package/Scripts"

    Other than that I completely agree with your initial point now.
     
    SonicBloomEric likes this.
  31. DominoM

    DominoM

    Joined:
    Nov 24, 2016
    Posts:
    432
    Doing it that way, the scripts would be compiled in Phase 3 rather than Phase 1. This is less of an issue when C# is the only script language used but does have an affect on compile times. The Plugins folder doesn't work wildcard style like the Editor ones, so only scripts in the root Plugins folder get compiled in Phase 1.

    So workflow wise, keeping scripts that aren't likely to change in Plugins lets the compiler skip Phase 1 & Phase 2 compilation most of the time as the compiler cache will still be current. Though as @Jes28 mentioned, there is now assembly definition files to manage this better.
     
    SonicBloomEric and Kumo-Kairo like this.
  32. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    You should file a bug with Unity on this one. Unity could solve this problem themselves by making the Unity Package Importer favor installing into folder locations that match meta file GUIDs rather than file paths. In this way, an update would detect the fact that a folder had moved from its expected location and Unity could automatically move the files into the updated location (the one specified by the user). This would, of course, break things for scripts that include hard-coded paths... but hard-coding paths in scripts is a practice that should be avoided at all costs anyway.

    I should note that the Unity Package Importer may already work this way. This would mean that your users moved the files/folders around outside of Unity and did not move meta files along with them. This is bad practice and would cause issues for your users regardless. I highly doubt that this is the issue your users are facing.

    Agreed. I have had several conversations with Unity developers over the last three years about this issue. At its core, the problem is one of communication. Unity does nothing to help the user [new or experienced] understand that the Plugins folder (and others) are special. They are indeed magic. One super obvious solution would be to use special icons for the special folders with Inspector Descriptions and Hover Text. Another would be to simply make the compilation pass a selectable/configurable option for the folder [e.g. a dropdown]. I have made these suggestions (amongst others) to Unity developers in those aforementioned conversations but so far Unity has shown no real interest in solving this particular problem.

    This is likely because they are providing other solutions that will eventually supersede the magic folders. Specifically:
    Assembly Definition Files are great if you only need to support the most recent versions of Unity (at time of writing). The Unity Package Manager (UPM) is still under rapid development within Unity and doesn't support more than a handful of internal packages - it's a long ways off from being something that Asset Store developers can/will use (at time of writing). The UPM is also part of the reason why the Asset Store team has stopped all work on the Asset Store Tools - the UPM will eventually replace the Asset Store delivery system. There's no announced timeline for this, though, which means that we're left with unsatisfactory tools for an unknown amount of time (probably another year or two).

    @DominoM's post provides a decent solution. I would consider updating it to be a bit more loud; to make it display an alert message (at least once) that instructs the person who moved it about the dangers involved. I believe there is also an esoteric way to add a message to Folder Assets that would appear in the Inspector when the user selects the folder. The issue with this approach is that it would only appear in the Inspector when selected the right way in the Project panel (and only by itself). This would be something the user could very easily miss.

    That said, several things have changed that somewhat alleviate the issues that the Plugins folder helps you avoid:
    • [If you only need to support the recent versions of Unity,] Assembly Definition Files will help you keep your scripts from impacting your users' compilation times.
    • Unity now requires that all assets submitted to the Asset Store are C#. The cross-language compatibility problem is going away.
    I should also point out that it is entirely possible for you to compile and ship your own DLLs (assembly files). These are not affected by the script compilation passes (because they're already compiled!) and are 100% portable across files. Whether you ship the source code or not would be up to you (one way would be to include it as a separate .unitypackage file that user's could optionally install).

    I will point out that if your Editor Extension is complex enough, it may be making use of other special folders (e.g. Editor Default Resources or Gizmos) and Unity has offered no other solution for these folders. If your users move files installed into those locations then they will experience breakage because some Unity APIs require that Assets be located within those folders in order to function properly.

    Theoretically, the "Plugins" folder is equivalent to your "Extensions" folder. It simply has the "benefit" of using some of Unity's lesser-known features to improve the development experience "automatically" (reduce script compilation time). You work around that by using Assembly Definition Files, but you would potentially have to add those yourself for any third party asset that does not include them. Some users use "Third Party" instead of "Extensions" or "Plugins". If Unity did a better job communicating that third party packages should be installed in "Plugins", then we wouldn't be having this conversation. They don't, so here we are. (Even internally many of Unity's own developers don't fully understand the systems outlined in this post...)

    No. Unfortunately it does not work this way :( Unity only made a similar change in 5.2.2 for the Editor folders (prior to 5.2.2 you had to have a single Editor folder directly underneath Assets/Plugins in order to access the firstpass-editor compilation pass. With 5.2.2 and newer, you can put that Editor folder wherever you want beneath Assets/Plugins. Regardless, if you move the Editor folder outside of the Assets/Plugins folder you will now be compiling in the editor pass, rather than the firstpass-editor pass.

    Access to the firstpass compilation pass is only available for scripts found beneath the Assets/Plugins directory.

    For a deeper dive into the Asset Management side of things (including script compilation passes and Assembly Definition Files), take a look at this Unite 2017 talk that I gave:

     
    AlanMattano, TeagansDad and DominoM like this.
  33. jerotas

    jerotas

    Joined:
    Sep 4, 2011
    Posts:
    4,850
    No, we need to educate people on the correct approach. This does not result in a bunch of bad reviews, instead it results in people asking you "can I move stuff"? Now you can do it the right way (plugins folder) and have a stickied post you can point them to (takes like 1 minute) on why it's correct and let them know that the majority of plugin authors do it wrong (and shame on them if they know better), but they might be uninformed.

    You can also allow them to move it by adding any code necessary for it to work elsewhere, but advise them that it's best for compile time this way. Do it right, no excuses (not just speaking to the post I quoted but every negative post on this thread). The more of us that do, the more that will follow.

    Also, I tried the new assemblydef stuff and it didn't reduce compilation time whatsoever for Master Audio or Core Gamekit. Still 23 seconds on my slowish laptop either way if I make a change to either script. Utterly useless and I won't try it again unless someone tells me it actually works later.
     
    DominoM and SonicBloomEric like this.
  34. LurkingNinjaDev

    LurkingNinjaDev

    Joined:
    Jan 20, 2015
    Posts:
    1,940
    Kumo-Kairo likes this.
  35. jerotas

    jerotas

    Joined:
    Sep 4, 2011
    Posts:
    4,850
    Perhaps that contributes to the confusion. It's still wrong for those that are coders and care about compilation times. Maybe we should email Unity and ask why it says that.
     
  36. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    First, the Asset Store Submission Guidelines do not say that. Specifically, 3.1.a reads:
    Nowhere in that statement is there a requirement for the package root to be directly underneath Assets/.

    The official guidelines have had serious clarity issues since August 11th, 2016 when they were last overhauled. The announcement post to the [old and now defunct] Asset Store Publishers Google Group (posted by @Ian-Dunlap) asked for feedback and feedback was provided. Some very simple issues (e.g. the fact that 3.1.c mistakenly refers to the "Plugin" folder, rather than "Plugins" [reported by @Flipbookee]) still exist in the document today.

    I myself reported (off-list) directly to @Ian-Dunlap the clarity issue surrounding the overall message of 3.1.c (which still confusingly reads):
    This is entirely bogus. Not only does Unity accept packages that are organized in the fashion outlined in this thread, but there are lots of very high-quality examples that follow it (for the benefit of users). @Ian-Dunlap responded to my direct report about this suggesting that he would sit down with the Asset Store Devs and go over the contents of this thread to then reconsider what they should have in the guidelines. As yet there has been no movement (perhaps the meeting didn't happen? @Ian-Dunlap?). He also mentioned perhaps using this thread as the source for a blog post but that also doesn't appear to have happened :/ Either of those things would have gone a long way to help communicate and raise awareness of the features this thread outlines (and the reasoning for it).

    This is also not the first time that someone has pointed out that the Submission Guidelines contradict the content of this thread. Very shortly after the Submission Guidelines update occurred a very similar (or exactly the same?) point was raised. Fear not: Unity does indeed accept packages organized in this fashion (for Editor Extensions, at least!), regardless of how contradictory those guidelines may seem.

    As a bit of a case-in-point, the Submission Guidelines still say that they were "Last updated: Aug 10, 2016". That would be the day before @Ian-Dunlap sent out a message requesting feedback. What's more, Section 4.3 (Scripts) does not mention that assets submissions that include UnityScript or Boo script files will be summarily rejected. They're... a bit stale at this point, unfortunately.
     
    jerotas likes this.
  37. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    As mentioned in my previous post (roughly simul-posted ;p), I did just that the day after the change occurred to no apparent effect (except maybe an internal memo to allow packages that follow the structure outlined here?).

    Perhaps @Ian-Dunlap could speak more to the current status of all of this? Or perhaps more people emailing the Asset Store team would result in some action?
     
    jerotas likes this.
  38. LurkingNinjaDev

    LurkingNinjaDev

    Joined:
    Jan 20, 2015
    Posts:
    1,940
    I didn't say that I think the current guidelines are good and the thread is wrong. I merely stated that the guidelines are still telling otherwise.
    Since this is the case since August of 2016, well... we can safely say that they would fix it if they think it is a good move. I guess they have reasons.

    If you read the 3.1 section carefully and fully including the example picture underneath, I think it clearly states that the preferred way is to put your asset in the Assets root with your name as a root folder. Now, I know UAS accept a lot of things and with very inconsistent enforcement to things. (I tried to submit a free asset once and they refused, because I'm not willing to support it - MIT license and stuff, and after that other assets with similar setup were released, so it just matter of luck).

    I would be happy if they change the guidelines. I like the suggested structure here.
     
    jerotas and SonicBloomEric like this.
  39. jerotas

    jerotas

    Joined:
    Sep 4, 2011
    Posts:
    4,850
    If I haven't said it before, I learned a few things reading this thread and I go by everything that SonicBloomEric outlined in our plugins, because it seems the best way for coders to be productive. Yes, tiny hit in support because of it and most authors don't follow it (so customers think we're doing it wrong lol), but I'd rather have this situation than just follow the less productive approach.
     
    SonicBloomEric likes this.
  40. DominoM

    DominoM

    Joined:
    Nov 24, 2016
    Posts:
    432
    After watching @SonicBloomEric 's interesting video I'm going to hazard a guess that the guidelines were designed to avoid conflicts in the GUID for the root folders. Though considering how many times I've made a DominoDesigns folder in my projects, I'm not sure the guidelines are any better at that.
     
    SonicBloomEric likes this.
  41. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    That's fair. What you quoted was my reaction to the quoted guideline, not to your raising it. I hope you didn't take any direct offense: none was intended! :)

    The reasons could also very well be something like "we forgot about it" or "that document is really hard to update due to how it's generated/hosted". It could be that they have other reasons, but I doubt it (given that even simple misspellings haven't been addressed). :/

    I can see how you would interpret that (especially with respect to 3.1.c, which I already addressed above). It does not however, specifically mention the "Assets" or "root" folder anywhere. Further, the purpose of the image is to show that you shouldn't use multiple root folders, but contain everything underneath one main folder (which is also what this thread suggests, albeit with far more specificity ;D).

    Same here. I'd go a step further and suggest that they specifically call out Editor Extensions (and related Scripting Packages) as being perhaps separate from content assets. Straight-up content assets don't necessarily gain any benefit from the structure outlined here and can easily be moved around and exploded into various folders as seen fit by the users. This could be unified, of course, as some content packages may include certain "custom controller" scripts that could benefit from the organization of this thread.

    If you take a look at the Package Contents of the Koreographer Editor Extension, you'll see the following root folder structure:
    • Assets/Editor Default Resources/Koreographer - Icons and other images loaded in the Editor.
    • Assets/Gizmos - Icons used in the Editor for Koreographer classes. Due to implementation details, icon images must be directly within the Gizmos folder (unfortunately).
    • Assets/Koreographer - Content assets that ship with Koreographer. You can safely delete this entire folder (removes documentation, extra integration packages, and demo content) and the Editor Extension will continue to work without issue.
    • Assets/Plugins/Editor/Koreographer - Scripting content for the Editor. DLLs are included but source code packages do properly install C# scripts into this directory. This version is used (rather than having the Editor folder beneath the Koreographer folder) because Koreographer supports Unity versions back to 4.5.0 (pre-5.2.2).
    • Assets/Plugins/Koreographer - Scripting content for runtime [and editor]. Similar to the Editor-specific content, DLLs are included but source code versions put the main scripts in this location.
    I mention all of this because there's nothing stopping content asset packages from also following this structure. They would simply "opt-in" to using the Plugins/Gizmos/Editor Default Resources folders if they deemed it necessary/beneficial for their specific case :)
     
    TeagansDad likes this.
  42. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    It's a good guess, but probably unlikely. There may have been some "prevailing wisdom" within Unity that stuck around for a while before losing its original source (e.g. that you get GUID conflicts), but there are some incredibly obvious fixes for that issue. The first (and one I've been advocating for years) is for the Asset Store Tools to allow us to select multiple root folders. If you take a look at Koreographer's folder layout as listed in this post, one could theoretically select all of the bold "Koreographer" folders as roots for the asset. The Unity Package system (which the Asset Store Tools use) is smart enough to only begin including GUIDs in the package specification at the specified root folder locations. What this means is that no GUID collisions would occur for Plugins or Editor Extensions in the Koreographer example. (Gizmos is a separate issue, but one that could be addressed by adding a custom rule to handle it. Heck, Unity could also just have built-in rules to detect when any special folder appears and automatically adjust the "root assets" for us!)

    I've tested the approach outlined above and it works - no more GUID collision issues. I've reported this "fix" approach to Unity (multiple times). Unfortunately, I recently heard that the Asset Store Tools are dead and won't receive further updates. :(

    On the other hand, Unity also glossed over this issue by simply hiding it with versions of Unity beginning around 5.3-5.6. Whereas older versions of Unity would output a scary console error explaining that a GUID collision had occurred (but no bad things happened as a result), current versions of Unity simply show a warning icon next to the common "Plugins" (and etc.) folders. They do not spit out the scary warnings anymore. For all intents and purposes, GUID collisions for shared root folders are [currently] a non-issue.
     
    Last edited: Feb 28, 2018
    DominoM likes this.
  43. CrystalConflux

    CrystalConflux

    Joined:
    May 25, 2017
    Posts:
    74
    This setup would be much more convenient for everyone involved and I'm surprised it isn't the way it's done. It would allow any extension to be completely location agnostic regardless of features and at the same time not affect compile times for the main project.

    What if I have all of the extension code within the Plugins folder (No Editor Default Resources)? I can then upload the Plugins folder right?
    I'm just a little hesitant to do this, won't it cause a folder GUID conflict for my users? Will the asset store approve it? When reading the guidelines I was under the impression that they only want a single folder named the company name or the extension name for upload. Have other people who use the recommended folder structure in the OP had any problems with asset store approval?
     
  44. jerotas

    jerotas

    Joined:
    Sep 4, 2011
    Posts:
    4,850
    Sure, if everything was in the Plugins folder, that's all you need to upload.

    We've been using 3 folders for over 3 years: Plugins, Editor Default Resources and Gizmos. Done probably 30 updates to the multiple plugins each. There will be no Asset Store problem. The Asset Store itself has said this organization is a good idea if you read further up the thread. But for some reason, they haven't updated their submission guidelines still. '

    GUID conflict? Never heard of it happening. We have at least 7,000 users of our 2 main plugins.

    Our structure under Plugins is:
    1) DarkTonic/PluginName
    2) Editor/DarkTonic/PluginName

    I also use DarkTonic folders under Editor Default Resources and Gizmos so people would know which stuff is our if they want to remove.
     
    SonicBloomEric likes this.
  45. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    529
    Short answer: No.

    Long answer: Yes, but behind the scenes in current versions and through a harmless console error in legacy versions of Unity. If you select the root Assets folder or specifically Assets/Plugins as your upload folder, then your local GUID for the Plugins folder will be included in the package. This is what causes the collision. Does it matter? No. Unity handles this without any issue (other than a confusing error in legacy Unity versions). Today's Unity will show a "⚠️" icon in the Package Install window for the Plugins folder, but 99.999% of users never notice it (note: you can mouse over it for details). That's it.

    Yes! However, if your asset manages to fit everything within a Plugins sub-folder like this:

    Everything: Assets/Plugins/[Package_Name]/...

    If you do this, you can simply select the [Package_Name] folder in the Asset Store Tools as your asset root folder. If you do this the Asset Store Tools might be smart enough to not include the Plugins folder's GUID in the package it uploads to Unity. This is possible with Unity's APIs but I'm not sure if they used the packaging APIs in that way. I've not tested it (requires being able to test packages you uploaded with Asset Store Tools which we only get once published) but it's your best bet to not have issues.

    While I'm the OP, I figure I'd also mention that we've exclusively used this setup for asset submission and never once had problems with Asset Store approval :)

    Hope this is helpful!
     
    CrystalConflux likes this.
  46. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    876
    FWIW, this is the situation with the Magic Markers asset that I have published as of January. I have tested my import into Unity from 5.4.6 onward and not had any warnings about GUIDs. As you stipulated, what I am doing is selecting [Package Name] and *not* the Plugins folder above it (although that is intrinsically part of the path). YMMV, but what @SonicBloomEric suggested is working for me.
     
  47. DerDicke

    DerDicke

    Joined:
    Jun 30, 2015
    Posts:
    121
    Personally I think this discussion goes the wrong way.
    Moving folders around inside a project is Unity Core DNA. It's one big advantage over UE and just makes live easier.
    I hate it not to be able to move Third Party Stuff to 'Third Party Stuff'.
    I'm a Asset Store publisher myself (making tools) and experience that same problem now too. If you want to let the user create a prefab in scene using a menu you'll either have to use a known path (binds your asset to a fixed location) or place your prefabs in Resources folder, which is bad practice because you don't want your prefabs in final built (by default).

    The solution for this could be Asset Tags. That is, you might want to acquire a string (from Unity) identifying your asset globally.
    This string will be added to a project specific list of compiler symbols on import used for every build target automatically and can be used to find installation folder in project.

    Let's say your tag is "PlayMaker".
    If any package wants to support PM, it could check if it is installed at compile time by: #ifdef PlayMaker
    Package location could be retrieved by: string path= AssetDatabase.GetPath("PlayMaker"); at Editor time.

    The compile time issue should not be resolved by moving your code to a specific folder. This appears like a terrible hack to me. It is a core compiler problem and you want to shift it to the client (the Asset Store developer). That feels plain wrong to me. It is a problem on Unity's end.
     
  48. jerotas

    jerotas

    Joined:
    Sep 4, 2011
    Posts:
    4,850
    A couple things.

    You can move everything to the third-party extensions folder if you like, nobody's stopping you. Of course it will not help your compile time though so what's the point right? I treat the plugins folder as your third-party extensions folder. All code plugins get moved there in our projects.

    The second thing is Unity must have set up the compilation of projects in that order for a reason. That is how it is and we are just taking advantage of the fact to save compilation time. If there were another way we would. If it changes we will take advantage of that change. Bottom line is that we will do anything to get compilation time down, or it's just not productive to work inside Unity on large projects. I'm not saying it's ideal but it's what must be done currently, or I'm wasted as a programmer and so are my users - I'm an author as well. I'm not going to discuss whether it's a hack or not because I don't really think that matters at all. If it makes me more productive, I'm doing it. Time is precious.
     
    SonicBloomEric likes this.
  49. jerotas

    jerotas

    Joined:
    Sep 4, 2011
    Posts:
    4,850
    Yes but if you read the order of compilations page that mentions the plugins folder, it mentions that "code" that compiles in the plugins folder does so before other folders. Some people are under the impression that only dlls go in the plugins folder. Note that dlls are already compiled. So this is very mention of code that compiles in plugins folder means that they support and allow you to put compilable code in the plugins folder. And always have. Also note that this verbiage has been there for many years, prior to them supporting raw. Java files in the plugins folder.
     
    SonicBloomEric likes this.
  50. r618

    r618

    Joined:
    Jan 19, 2009
    Posts:
    684
    Last edited: Sep 28, 2018