Handle Editor/Resources?

Currently, a warning is logged when any editor-only asset is located in a `Resources` folder (even if it's inside an `Editor` directory). Also, a warning is logged for `AudioMixerController` (audio mixer) assets, even though they can and are used at runtime just fine.

Any way to permanently disable those warnings?

 

This is actually two separate issues.

1. AudioMixerController - this is a bug in our code. Unfortunately there are a handful of types in Unity that are an editor-only type in-editor, but then are magically transformed to a runtime type when built. We already have special code in place for AnimatorController, but not yet for the audio mixer. Filing a bug in our system now for it.
2. editor types in Resources - The core issue is that your data is telling us at build time that you'd like build information of certain assets to be included. We detect that some of those assets are editor-only, so we warn you that they won't actually be included, even though your data is asking for it. So you have three choices for a fix. One, if you are not using Addressables to load things from Resources you can select the Built In Data group (sometimes called Player Data group) and uncheck "Include Resource Folders". Two, stop having editor only items in Resources (no real idea why they'd be there in the first place). Three edit AddressableAssetEntry.cs to comment out the log.

 

1. Thank you, will wait for the fix!
2. The thing is, `Resources` folders inside an `Editor` folder are treated in a special way (as per the docs): they shouldn't get into the build and can be used to load resources from the editor assembly.



So, I guess the system shouldn't warn us about editor-only assets inside an Editor folder?

 

Ugh, Resources. So much weird magic that was put in long ago. If you are in the editor, and loading something editor-only, you should be using the AssetDatabase. I don't understand why we (Unity) would have made Resources work this way, and put in our docs that it's a fine workflow. Perhaps this pre-dates some of the AssetDatabase mechanisms.

But, apparently it does this. Which means there are probably thousands of asset store packages that take advantage of it. So we'll look into wrapping our warning in an `if(not in resources)`. In the interim, you can still do the first option (uncheck "include Resources" in the settings).

Thanks for the clarification.

Also, of note, the AudioMixer fix won't be in the release coming out in the next couple days. It'll be in the following one (probably two to three weeks after)

 

Yeah, well, I absolutely agree that this kind of legacy magic (especially the overriden equality operator) mess things up nowadays. I'm actually using the AssetDatabase to retrieve assets from that folder, it's just "Editor/Resources" is kinda fitting name for a folder that contains... editor resources

 

We already have the "Editor Default Resources" for that. And don't ask me why "Default".

 

Nah, that one should be in the root of the "Assets" folder, can't use it for an Asset Store package

 

Hm, apparently "Editor/Resources" are used this way even in the official Unity packages: https://github.com/Unity-Technologi...h/Editor/Drawing/Views/GraphEditorView.cs#L97

 

Came here from Google because Unity 2019.3 has introduced new bugs where it blocks use of the Editor/Resources magic folder .

But, in passing, wanted to comment on this:

TL;DR: as an asset author for 5+ years: this is/became extremely popular because the AssetDatabase API is way too over-complicated for something as simple as "draw a textured background in your editorwindow", and should never have been used for that (these are NOT assets! Assets are part of your game/project. EditorResources are part of the editor-extending code!). Rather than condemn something that works great, solves the problem very neatly, I suggest: consider what's wrong (a lot!) with AssetDatabase?

(Plus AD has contained enough of its own bugs over the years (doesn't handle paths normally, needs custom coding for lots of edge cases, causes problems with Editor startup lifecycle if accessed at "wrong" moment during the first frame of Editor application running, etc) ... to be massive overkill and a waste of time when all you wanted to do was "display an image in an EditorWindow", or even "texture your Inspector").

...but maybe this explains why 2019 is rejecting my EditorResources folders (works fine in 2017, 2018)

 

May I ask what those bugs are? I'm currently using Editor/Resources in my asset store package in 2019.3 and everything seems to work fine.

 

So ... another one to add to the "reasons not to use AssetDatabase":

1. There's no (new) bug in 2019.3
2. If assembly-rebuild fails for any reason - e.g. a syntax error in a .cs file - some of the AssetDatabase calls silently return empty values. In my case:
AssetDatabase.GetAssetPath(MonoScript.FromScriptableObject(...
3. A different Unity API (used by a completely different 3rd party plugin) had changed in 2019.3, and so when I went to load the project, recompile had 1 error (only 1!)
4. ...but the nature of EditorResources is that they're being accessed 100 times per second (Editor default refresh rate, or used to be - maybe its lower now?)
5. ... so my console log was being spammed by so many errors from AssetDatabase that I didn't see the one compile-error (until I tried to run debugger, and noticed in my IDE that my IDE had seen there was one compile error).

I think you could argue whether 2 and 5 are bugs in AD? I think not (although I would probably lean towards: AssetDatabase.GetAssetPath is incorrect, and should log an error / throw an exception rather than silently return a path of "", which it currently does!).

TL;DR: AssetDatabase is a gigantic complicated API that shouldn't be used for simple tasks. It especially shoul;dn't be used for basic "not part of the game" stuff like rendering EditorWindows / Custom Inspectors / etc .