GraphEditor Expanded Assembly Search

I created a custom NavGraph as well as a GraphEditor for it, but unity was still giving me errors indicating that I did not have a GraphEditor for the graph.

After a while I discovered that because I put the “AStarPathfindingProject” directory inside “Plugins” (where try to put all third party stuff), the search was not finding my GraphEditor due to only searching the assembly that GraphEditorBase is located in.

The solution was to move the package’s directory back out of the “Plugins” directory, but I am curious what I would have done if my GraphEditor was say inside a dll where it wouldn’t matter where the package directory was, it wouldn’t find it with the current implementation. This is a problem seeing as how a GraphEditor is basically required to be found or else cause AstarPathEditor to throw a fit.

Instead of iterating just the assembly the GraphEditorBase is in, it may a good idea to search all assemblies, not just so I can move the package back into “Plugins” (my personal desire), but for the possibility for types of GraphEditor to be located in external assemblies (so I don’t seem selfish in my request).

I know the problem mentioned above isn’t that big of a deal, but I kinda feel ignored here.

Hi

Sorry. I have seen this post and I have noted it, but since it was a feature request I didn’t feel the need for answering right away.
I think I did search all assemblies in some previous version, but there was some issue with it, I can’t remember what it was though. It might have been hard to support on .Net Core (i.e UWP and Windows Phone).

I see.

Perhaps instead of searching all assemblies, perhaps you could parse the one it is in to obtain the other editor assembly unity creates.

For example, if it sees it self in <ProjectName>.Editor, also search <ProjectName.Editor.Plugins and vice versa.

Not necessary for my situation, but if anyone for what ever reason puts a GraphEditor in a dll perhaps have a text file to read from for assemblies to additionally search.